認証済みAIエージェントでも逸脱・データ露出・汚染されたメモリの保持は起こり得る

Google Newsは、VentureBeatによる鋭い警告を含む分析を取り上げた。AIエージェントは認証を通過していても、誤った行動を取る可能性がある。認証情報は有効かもしれない。API呼び出しも許可されているかもしれない。それでも、その行為はタスクに反したり、機微なデータを露出させたり、攻撃者の指示をメモリに残したりするおそれがある。

この区別は、よく知られたセキュリティ上の前提に疑問を投げかける。アイデンティティおよびアクセス管理は、誰が、あるいは何がアクセスを要求したかを検証する。しかし、自律システムが割り当てられた目的をなお追求しているかどうかを、自動的に判定するものではない。

8月30日のレポートは、企業が必要なコンテキストを確立する前に、強制適用ゲートウェイを導入していると論じる。比較の対象は、あるセキュリティベンダーと別のベンダーではない。有効な認証と適切な行動の比較であり、この2つの条件はもはや同じ意味ではない。

Google Newsのレポートが実際に変えた視点

このレポートは、AIエージェントのセキュリティを単なる認証の問題ではなく、導入順序の問題として捉え直している。

VentureBeatの寄稿者Nik Kaleは、企業導入で繰り返されるパターンを説明している。チームはしばしば、エージェントのトラフィックを検査し、アクセスポリシーを適用するランタイムゲートウェイから始める。

しかし、そのゲートウェイには、エージェントに関する上流の情報が欠けていることが多い。エージェントの所有者、割り当てられたタスク、承認済みツール、委任された権限、完全なアクションチェーンを把握していない可能性がある。

結果として生じる盲点は見落としやすい。たとえば、財務照合エージェントが本番レコードの変更を試みる場面を想像してみよう。ゲートウェイは従業員トークンを認証し、そのトークンにAPI操作の権限があることを確認できる。

それでも、エージェントが割り当て範囲を超えていても、両方のチェックは通過し得る。従業員には広範な本番環境へのアクセス権がある一方、エージェントには限定的な照合タスクしか委任されていないかもしれない。

Kaleのセキュリティの順序では、ランタイムでの強制適用は、6部構成の依存関係チェーンの5番目に位置付けられている。先に必要なのは、インベントリ、固有のアイデンティティ、スコープを限定した認証情報、そして帰属を追跡できるテレメトリーだ。

強制適用の後には、行動監視とシステム横断の封じ込め経路が続く。この順序が重要なのは、後続の各制御が、前段で作られるコンテキストに依存するためだ。

この記事は、ゲートウェイが無用だとは主張していない。組織がいくつかの基本的な問いに答えられるようになって初めて、ゲートウェイが有用になると論じている。

どのエージェントがリクエストを開始したのか。誰がタスクを委任したのか。エージェントはどの権限を使っているのか。タスクはどのような結果を生むべきなのか。

従来型のゲートウェイが見るのは、しばしばトークン、宛先、リクエストメソッドだけだ。エージェント対応のコントロールプレーンには、目的、系譜、そして下流への影響も理解することが求められる。

これが、この出来事における中心的な逆転である。認証は依然として必要だが、認証に成功したことだけでは、信頼に足る十分な証拠にならなくなっている。

タイミングも重要だ。AIエージェントはテキスト生成の枠を越え、APIを呼び出し、ファイルを操作し、データベースを変更し、他システムと連携するワークフローへ移行している。

こうした行為は永続的な影響を生む。誤った回答は修正できる。しかし、完了した支払い、エクスポートされたデータセット、取り消された認証情報、変更された本番環境には、封じ込めと復旧が必要になる。

したがって、このGoogle Newsの記事は、より広範な運用上の変化を示している。セキュリティチームは、委任された意図から外部への影響まで、完全な経路を評価しなければならない。

ログイン境界で止まることはできない。重要な問いは、エージェントが受け入れられた後に始まる。

認証が証明するのはアイデンティティであり、意図ではない

有効な認証情報は認可された主体を識別するが、すべてのエージェントの行動がその主体の現在のタスクに資することを証明するわけではない。

従来のアイデンティティシステムは、比較的安定した行為主体を前提に構築されてきた。人はサインインし、権限を受け取り、監査証跡に記録される行動を取る。

AIエージェントは、そのモデルのあらゆる部分を複雑にする。1人の従業員が複数のエージェントを起動でき、各エージェントは複数のツールを呼び出し、追加のタスクを作成できる。

それらすべてのプロセスが1つの従業員トークンを借用すると、ログ上では複数の異なる行為主体が1つのアイデンティティに集約されてしまう。調査担当者は認証情報を確認できても、実際の意思決定者は把握できない。

共有サービスアカウントも同様の問題を生む。所有者を曖昧にし、1つのエージェントだけが危険な状態になった場合の対象を絞った失効を難しくする。

エージェントごとの固有アイデンティティは帰属追跡を改善するが、アイデンティティだけではなお不十分だ。システムは、タスクを割り当てた人またはサービスと、その許可された目的を意味する委任コンテキストを保持しなければならない。

給与、調達、顧客記録、財務報告にアクセスできる従業員を考えてみよう。請求書の照合を依頼されたエージェントが、その従業員のアクセス範囲全体を継承すべきではない。

安全な権限とは、3つの制限の共通部分である。委任者の権限、エージェントに承認された機能、そして現在のタスクに必要なリソースが含まれる。

Kaleはこの原則を単調な委任と呼ぶ。権限の移転はすべて、アクセスを維持または縮小すべきであり、拡大してはならない。

これは単にロールを割り当てるより厳格だ。期限が切れ、無関係なシステムに到達できない、タスクスコープの認証情報が必要になる。

短命な認証情報は、盗まれたシークレットの価値も下げる。攻撃者が1つのトークンを入手しても、従業員が利用できるすべてのリソースへの無期限のアクセスを得るべきではない。

そのうえで、テレメトリーは各ツール呼び出しを発生元に結び付けなければならない。有用な記録は、エージェント、委任者、タスク、親アクション、認証情報、ツール、結果を特定する。

このチェーンがなければ、インシデント対応者は2つの有害な遅延に直面する。まず、どのエージェントが存在するかを突き止め、次に、それがどの下流システムに触れたかを判断しなければならない。

認証済みのエージェントは、外部の攻撃者がいなくても逸脱し得る。行動の逸脱は、その行為が割り当てられた目的や承認済みの運用パターンから徐々に外れていくときに発生する。

引き金となるのは、曖昧な指示、変化するコンテキスト、予期しないツール応答、あるいは個別には許容される一連の判断の蓄積かもしれない。

この振る舞いは、従来の侵害されたアカウントとは異なる。エージェントは、設計どおりに承認済みの認証情報と承認済みのAPIを使用している可能性がある。

失敗は、行為と元のタスクとの関係にある。標準的な認証は、その関係を評価しない。

Oktaのエージェント型企業に関する調査は、ガバナンス上の隔たりを示している。調査対象組織のうち、デジタル労働力と人間の労働力に同じセキュリティ制御を適用していたのは34%にとどまった。

この調査は、確信度の不一致も報告している。経営幹部の95%は、自組織が意図した範囲外で稼働するAIを検知できると確信していた。

これらの調査結果はベンダー支援の調査に基づくため、市場全体を独立して測定した結果として扱うべきではない。それでも、この対比は検証可能な運用上の問いを示している。

組織は、1つのエージェントタスクを開始から下流へのあらゆる影響に至るまで再構築できるのか。できないなら、その確信は証拠を先行している。

認証が答えるのは、認証情報が入場してよいかどうかだ。エージェントのセキュリティは、結果として生じる行為が委任された目的の範囲内にあるかどうかにも答えなければならない。

エージェントのメモリ汚染は、1つの悪意ある入力を永続化する

エージェントのメモリ汚染は、信頼できないコンテンツを一時的なプロンプトから、後続セッションに影響を及ぼし得る再利用可能な指示へと変える。

メモリは、エージェントが設定、プロジェクトのコンテキスト、タスク履歴、過去の判断を維持するのに役立つ。この継続性は繰り返しを減らし、長時間稼働するワークフローをより有用にする。

同時に、永続的な攻撃面も生む。エージェントは、ウェブページ、文書、メッセージ、ツール応答、他のエージェントから収集した情報を保存する可能性がある。

悪意あるコンテンツがそのストアに到達すると、エージェントは後にそれを信頼できるコンテキストとして取得し得る。有害な行為が発生する時点で、元の攻撃者はすでに存在しないかもしれない。

OWASPは、メモリ汚染を、後続のセッションまたはユーザーに影響を与えるために永続化された悪意ある情報と定義している。エージェントセキュリティのガイダンスでは、この脅威を目標の乗っ取り、ツールの悪用、データ露出、過剰な自律性とともに挙げている。

この永続性は、インシデント対応を変える。元のメッセージを削除したり、ソースを遮断したりしても、保存済みの指示が必ずしも除去されるとは限らない。

汚染されたメモリは会話をまたいで残り得る。また、数日後に生成される要約、取得済み記録、計画、判断にも影響し得る。

実務的なシナリオでは、エージェントが外部文書を読むことから始まる。隠しテキストは、攻撃者が管理する連絡先を、緊急依頼の承認済みベンダーだと偽って記載する。

エージェントはその主張を組織の知識として保存する。後に、正当なユーザーが業務上の障害発生時に支援を求める。

エージェントは汚染されたエントリを取得し、攻撃者が管理する連絡先を推奨する。すでにメモリに受け入れられた情報に従っているため、その出力は内部的に一貫して見える。

このシナリオで、認証がもたらす保護は限られている。ユーザーは正当であり、エージェントも正当であり、後のリクエストも通常のものかもしれない。

破損しているのは、エージェントが保持するコンテキストだ。そのコンテキストが、本来は許可されたタスクの完了方法を形作る。

メモリ汚染は、データ露出の経路も作り得る。保存された指示が、隠しファイルを含めること、未承認のエンドポイントへ結果を送信すること、将来のセキュリティチェックを弱めることをエージェントに指示するかもしれない。

複数のエージェントがベクトルストアやナレッジレイヤーを共有している場合、影響は広がり得る。1つの汚染されたエントリが、各エージェントを個別に侵害せずとも、複数のワークフローに影響を与える可能性がある。

エージェントのメモリ汚染は、責任の所在も複雑にする。有害な出力は、実際の原因が破損した永続状態であるにもかかわらず、ハルシネーションやモデルの失敗に見える場合がある。

この区別は修復対応に影響する。モデルを変更したり、直近のプロンプトを書き換えたりしても、汚染されたメモリストアは修復されない。

セキュリティチームには、保存済みコンテキストの来歴が必要だ。来歴は、項目の発生元、メモリに入った時点、承認したプロセス、後続タスクでの利用方法を記録する。

メモリには信頼ラベルも必要である。ユーザー提供コンテンツ、外部から取得したテキスト、システム承認済みポリシー、検証済みの組織記録を、区別のない1つのプールに入れるべきではない。

同じ原則は、個人向けのAIナレッジベースでも重要になる。永続的なコンテキストは蓄積されるほど価値を増すが、その発生元とスコープも同じくらい重要になる。

OWASPによる永続的メモリの解説では、MemoryTrapと呼ばれるClaude Code関連の事例を紹介している。Ciscoの研究者は、通常の開発フローが悪意あるコンテンツを永続的で信頼度の高い領域に配置し得ることを発見した。

OWASPによれば、Anthropicは後に、信頼度の高いシステムプロンプト経路からユーザーメモリを取り除くようClaude Codeを変更した。この修正は特定された経路に対処したものであり、リスクのクラス全体を解決したわけではない。

教訓は1つのコーディングエージェントにとどまらない。変更可能な状態を書き込み、後にそれをガイダンスとして扱うあらゆるシステムには、メモリ固有の制御が必要だ。

こうした制御には、保存前の検証、完全性チェック、スコープを限定した取得、変更監視、既知の正常な状態へのロールバックが含まれる。

チームは、事実としての記憶と行動上の指示も区別しなければならない。保存されたプロジェクトの日付が、セキュリティポリシーと同じ権限を持つべきではない。

この分離は、エージェントが自らの記憶を書き込める場合に特に重要になる。侵害された計画プロセスが、将来の運用ルールを密かに再定義してはならない。

エージェントのメモリ汚染は、セキュリティがモデルに入ってくるリクエストだけに焦点を当てられない理由を示している。防御側は、リクエスト間を移動する状態を保護しなければならない。

ゲートウェイだけではセキュリティモデル全体を担えない理由

ゲートウェイはポリシーを適用できるが、不足しているアイデンティティ、委任、帰属情報を生み出すことはできない。

ランタイムゲートウェイは魅力的な位置にある。ツール呼び出しを監視し、リクエストを検査し、ルールを適用し、危険な宛先をブロックできる。

この可視性により、AIエージェントのセキュリティを懸念する組織にとって、ゲートウェイは合理的な導入対象となる。しかし、ゲートウェイ自体も特権的なインフラになる。

2026年6月のLiteLLMインシデントは、こうした集中を精査すべき理由を示した。CISAは、積極的な悪用の証拠を受け、CVE-2026-42271を既知の悪用済み脆弱性カタログに追加した。

この脆弱性は、Model Context Protocolサーバーの設定をテストするために使われるエンドポイントに影響した。Model Context Protocol、すなわちMCPは、AIアプリケーションをツールや外部データソースに接続する仕組みだ。

LiteLLMの開示によると、認証済みユーザーは、脆弱なプロキシがホスト上で実行するコマンド詳細を入力できた。

研究者らはこの脆弱性を、別のホスト検証の脆弱性とも連鎖させた。この組み合わせにより、影響を受ける構成では認証情報なしでリモートコード実行が可能になったと報告されている。

LiteLLMは、バージョン1.83.7でコマンドインジェクションの問題を修正した。この事例は、すべてのゲートウェイが安全でないことを意味するものではない。

示しているのは、ゲートウェイがセキュリティアーキテクチャの代替ではなく、攻撃対象領域の一部だということだ。単一の制御により多くの権限を集約するほど、それが侵害された際の影響は大きくなる。

侵害されていないゲートウェイであっても、入力による制約を受ける。ポリシーエンジンは、タスクコンテキストを含まないベアラートークンから目的を推測できない。

また、1つのサービスアカウントを共有する20のエージェントを区別することもできない。基盤となるアイデンティティモデルが、適用開始前にその違いを消してしまっているため、トラフィックは認可済みに見える。

これが主なトレードオフだ。中央集権的な適用は一貫性を向上させうるが、中央集権化は上流にある曖昧さを修復しない。

組織がエージェントのインベントリを確立して初めて、ゲートウェイは価値を発揮する。すべての本番エージェントには、所有者、定義された目的、承認済みツール、認証情報のソース、ライフサイクル状態が必要だ。

次の依存関係は、委任に結び付いた明確なアイデンティティである。ツールは、どのエージェントが呼び出したのか、そしてそのエージェントが誰の権限を代表しているのかの両方を把握すべきだ。

認証情報には、狭いスコープと短い有効期限も必要になる。照合エージェントがアクセスすべきなのは必要な台帳であり、人間のスポンサーが利用できるすべてのデータベースではない。

次に必要なのは、帰属可能なテレメトリーだ。セキュリティチームは、完了したタスクをすべてのツール呼び出しと下流の結果まで追跡できなければならない。

そうして初めて、ランタイムポリシーはコンテキストを認識した判断を下せる。その判断は、トークンがデータベース書き込みを許可しているかを問うだけよりも具体的になる。

このエージェントが、このプリンシパルのために、このタスク中に、このレコードに対して、この書き込みを実行してよいかを問えるようになる。

この追加コンテキストは、追加認証のようなステップアップ制御も支える。影響の大きい操作では、エージェントが有効な認証情報を持っていても、独立した承認を要求できる。

支払い、削除、本番環境の変更、データエクスポート、アクセスポリシーの変更は、このカテゴリに属する。その結果の重大性が、外部の認可境界を正当化する。

エージェントは自らの行動を承認すべきではない。そうでなければ、注入された指示が提案と保護策の両方に影響を与えうる。

企業には、システムを横断する停止経路も必要だ。アクティブなトークン、実行中のタスク、接続済みツールが利用可能なままであれば、1つのアイデンティティを無効化するだけでは不十分である。

封じ込めでは、主認証情報と派生認証情報を失効させ、現在のタスクを停止し、ツールアクセスを無効化し、エージェントをホストするワークロードを隔離すべきだ。

この機能をインシデント発生時に即興で用意することはできない。チームは、エージェントに本番権限を与える前にテストしなければならない。

したがって、ゲートウェイには依然として価値があるが、その位置付けは変わる。より大きな依存関係チェーンの内部にある適用レイヤーとなる。

これは「すべてのエージェントリクエストを保護する」よりも狭い約束だ。しかし、より防御可能な約束でもある。

最小権限は有効だが、ドリフトを止めることはできない

アクセスを削減すればエージェントが引き起こしうる損害を制限できる一方、行動制御は、その縮小された境界内でエージェントが何を行うかに対処する。

最小権限は、利用可能な保護策の中でも最も明確なものの1つであり続ける。エージェントは、その認証情報でアクセスできないデータベースを公開することはできない。

Teleportは、セキュリティおよびインフラストラクチャのリーダー205人を対象とする調査を委託した。過剰な権限を持つAIシステムを報告した組織のインシデント率は76%で、最小権限のシステムでは17%だった。

これは、調査で報告された比率において4.5倍の差に当たる。同社のアイデンティティ調査は、2025年12月にEleven Market Researchによって実施された。

ベンダーが後援する調査には限界がある。AIシステム、インシデント、権限レベルの定義は、他組織の内部測定とは異なる可能性がある。

それでも結果は、実務的な命題を支持している。より小さな権限範囲は一般に、誤作動または侵害されたエージェントが利用できるシステムの数を減らす。

しかし、最小権限は正しい行動を保証しない。エージェントは、正当に保持している限定的な権限を悪用する可能性がある。

カスタマーサポートエージェントには、1つのアカウントを読む権限があるかもしれない。それでも、そのアカウントのデータを誤ったチャネルで公開する可能性がある。

スケジューリングエージェントにはカレンダーへの書き込みアクセスがあるかもしれない。それでも、招待状内の悪意あるコンテンツを誤読し、承認済みの会議をキャンセルする可能性がある。

財務エージェントは1つの台帳にアクセスできるかもしれない。それでも、技術的な権限範囲内に完全にとどまりながら、誤ったレコードを変更する可能性がある。

ここで行動ベースラインが有用になる。ベースラインは、エージェントの通常のツール、宛先、アクション頻度、データドメイン、タスクパターンを記述する。

セキュリティチームはその後、逸脱を検知できる。例としては、予期しないドメイン横断アクセス、繰り返される承認失敗、異常なエクスポート、ツール呼び出し頻度の変化などがある。

ベースラインは、信頼できるアイデンティティとテレメトリーに基づかなければならない。そうでなければ、異なるエージェントのデータが混ざり合い、誤解を招く1つのプロファイルになる。

監視にはタスク認識も必要だ。まれなデータベース書き込みが、あるタスクでは正当であっても、別のタスクでは危険な場合がある。

この要件により、静的なルールでは不十分となる。ランタイムの判断には、目的、開始者、承認済みリソース、期待される結果についての構造化されたコンテキストが必要だ。

難しい問いは、適用システムがどれほどのコンテキストを信頼できるかである。エージェントが自らのタスク説明を生成するなら、侵害されたエージェントは目的を偽って表現できる。

そのため、信頼できるタスクコンテキストは外部のオーケストレーター、ワークフロー定義、または承認システムから得るべきだ。エージェントはそのコンテキストを利用できても、密かに書き換えるべきではない。

メモリにも同様の扱いが必要である。モデルは、独立した検証なしに、取得した未検証テキストを永続的なポリシーへ昇格させるべきではない。

これらの境界は、意思決定者と意思決定の認可を分離する。1つの操作されたモデルがすべての段階を制御する可能性を減らす。

人間による承認は、不可逆的な境界で役立つ可能性があるが、完全な答えではない。大量のリクエストと反復的なプロンプトは、承認疲れを生む。

承認インターフェースは、関連する事実を示さなければならない。レビュー担当者には、開始タスク、影響を受けるリソース、提案された変更、予想される結果が必要だ。

一般的な「許可」ボタンは、十分な情報を提供せずに責任を移す。それは意図を見逃す、別の認証儀式になりかねない。

したがって、効果的なAIエージェントセキュリティは、制限と観測を組み合わせる。最小権限は影響範囲を抑え、テレメトリーと独立した認可は行動ドリフトを明らかにする。

メモリ整合性の制御は、持続的な操作に対処する。システム横断の停止経路は、予防的制御が見逃すケースに対応する。

単一のレイヤーで、エージェントが正しく行動することを証明できるわけではない。目標は、安全でない行動を可視化し、限定し、元に戻せ、帰属可能にすることだ。

企業が今すぐ検証できる6つの制御

すべての制御がポリシー文ではなく運用テストを持つとき、AIエージェントセキュリティは測定可能になる。

最初のテストはインベントリである。組織は、すべての本番エージェントを特定し、説明責任を負う所有者を識別できるべきだ。

インベントリには、目的、承認済みツール、データドメイン、認証情報のソース、モデルプロバイダー、デプロイ場所、ライフサイクル状態を含めるべきである。

シャドーエージェントも同じ扱いを受けるべきだ。部門が中央承認なしに導入したからといって、システムのリスクが低くなるわけではない。

2つ目のテストは、アイデンティティと委任である。ログは、エージェントと、そのタスクを割り当てた人物、サービス、またはワークフローを区別すべきだ。

このリンクは、ツール呼び出しやエージェント間の引き継ぎを通じて維持されなければならない。そうでなければ、ワークフローが最初のアプリケーションを離れた時点で帰属情報が失われる。

3つ目のテストは認証情報のスコープである。セキュリティチームはエージェントを1つ選び、そのアクティブなトークンが無関係なリソースに到達できないことを確認すべきだ。

認証情報はタスクとともに期限切れになるべきでもある。長期存続するシークレットは、一時的なエージェントアクセスを持続的な露出に変えてしまう。

4つ目のテストは再構築である。調査担当者は、完了した1つのタスクを選び、開始からすべての下流への影響まで追跡できるべきだ。

完全なトレースには、プロンプト、取得したコンテキスト、メモリ読み取り、メモリ書き込み、ツール呼び出し、承認、認証情報、出力、外部での変更が含まれる。

この記録は、エージェント自身が報告する推論だけに完全に依存すべきではない。最も信頼できる証拠は、モデルの外部にあるシステムから得られる。

5つ目のテストは、コンテキスト認識型の適用である。組織は、人間のスポンサーには実行可能だが、委任されたエージェントには実行できないアクションを試すべきだ。

ゲートウェイは、そのアクションがタスクの範囲外であるためにブロックすべきだ。トークンにアクセス権がないからブロックするだけでは、通常の権限をテストしているにすぎず、エージェント認識型の制御をテストしてはいない。

6つ目のテストは封じ込めである。シミュレーションしたインシデントにより、組織が接続されているすべてのシステムでエージェントを停止できることを検証すべきだ。

チームは、認証情報を失効させ、アクティブな実行を停止し、ツールをブロックし、ワークロードを隔離し、キューに入ったアクションが自動的に再開しないようにすべきである。

メモリには、この一連の全体にわたる追加テストが必要だ。セキュリティチームは、誰が永続的なコンテキストを書き込めるのか、また後続のどのワークフローがそれを取得できるのかを特定すべきである。

信頼できないソースから、無害なテストレコードを挿入すべきだ。システムはその出所をラベル付けし、スコープを制限し、ポリシーになることを防がなければならない。

ロールバック演習も同様に重要だ。汚染されたエントリを1つ削除しても、有効なメモリを破壊したり、派生サマリーを変更されないまま残したりしてはならない。

派生コンテキストは、微妙な復旧問題を生む。悪意あるレコードが、すでにサマリー、計画、または共有ナレッジオブジェクトに影響を与えている可能性がある。

元のレコードだけを削除しても、それらの派生物はそのまま残る。したがって、メモリシステムには、ソースレコードと生成された成果物の間の来歴情報が必要だ。

企業の購買担当者は、メモリの変更が監査可能かどうかをベンダーに尋ねるべきである。また、信頼ラベルが要約と取得を経ても維持されるかどうかも確認すべきだ。

開発者には、ツール境界に関する明確な制御が必要である。モデルには、現在のタスクに必要なツールだけを提供すべきであり、統合カタログ全体を与えるべきではない。

ナレッジワーカーは、エージェントが自信を持って記憶を想起しても、その出所が証明されるわけではないことを理解すべきです。永続的なコンテキストは、古くなっていたり、誤っていたり、意図的に操作されていたりする可能性があります。

これらのチェックにより、抽象的なセキュリティ上の懸念を観測可能な証拠へと変えられます。また、デプロイメントの依存関係チェーンがどこで途切れているかも明らかになります。

企業は、始める前にアイデンティティ基盤全体を置き換える必要はありません。既存のワークロードIDに対してエージェントを登録し、信頼できるタスク識別子を追加できます。

その後、より短命な認証情報、より充実したログ、影響の大きい操作に対する独立した承認へと移行できます。

重要なのは、各コントロールのブランドではなく、その導入順序です。下流のすべてのレイヤーは、上流で生成された証拠を利用すべきです。

その証拠が欠けている場合、組織はエージェントの権限を縮小すべきです。ゲートウェイへの信頼を強めて補うべきではありません。

セキュリティチームが次に注視すべきこと

AIエージェントセキュリティの次の段階は、製品コントロール、インシデントの証拠、メモリに特化した標準によって測られることになります。

最初のシグナルは、エージェントプラットフォーム全体でネイティブに提供されるタスクスコープ付きIDです。ベンダーは、標準的なインターフェースを通じて、個別のエージェント識別子、委任チェーン、短命な認証情報を公開する必要があります。

これらの機能が標準となれば、ゲートウェイはトークンの有効性以上の情報を用いてポリシーを適用できるようになります。それにより、Google Newsの報道で説明された依存関係ベースのモデルが強化されるでしょう。

プラットフォームが共有サービスアカウントや開発者トークンに依存し続けるなら、このモデルは実運用で弱まります。企業はデプロイ後に責任の所在を明確にすることが難しくなるでしょう。

2つ目のシグナルは、メモリ防御に対する独立したテストです。現在のガイダンスではエージェントのメモリポイズニングが明確に指摘されていますが、実装には大きなばらつきがあります。

有用なテストでは、汚染されたコンテンツが持続するか、ユーザー間をまたぐか、ツールに影響を与えるか、要約後も残るか、削除を試みた後も存続するかを測定すべきです。

修復についても評価すべきです。チームが派生したすべてのアーティファクトを特定して削除できないなら、不正なメモリを検知する価値は限定的です。

標準化された結果があれば、購入者は基本的な入力フィルタリングと真のライフサイクル保護を見分けやすくなります。また、防御策が管理されたデモ環境の外でも機能するかを明らかにできます。

3つ目のシグナルは、エージェントのアクションチェーンに紐づいた公開インシデント報告です。セキュリティチームには、ID、委任、メモリ、または封じ込めのどこで失敗したかを示す証拠が必要です。

「AIがミスをした」とする報告だけでは不十分です。調査担当者には、タスクの発生元、取得したコンテキスト、ツールの経路、認証情報のスコープ、外部への影響が必要です。

より詳細な報告は、現在の論旨を補強するか、あるいは覆すことになります。有効な認証後にも失敗が繰り返されるなら、IDだけでは不十分であることが確認されます。

反対に、スコープを限定した認証情報と帰属可能なテレメトリーを使用するデプロイメントでインシデントが持続的に減少すれば、提案されたコントロールの順序を裏付けることになります。

セキュリティリーダーは、今すぐこれらの測定値を収集し始めるべきです。成熟したベンダーカテゴリーを待てば、今日のエージェントは昨日の前提のもとで稼働し続けることになります。

開発者は、1つの完全なタスクを追跡することから始められます。エンタープライズの購入者は、ID、メモリの出所、システム横断的な封じ込めに関する証拠を要求できます。

ナレッジワーカーは、機密性の高い推奨に基づいて行動する前に、エージェントが記憶している事実がどこから来たのかを問い直すことができます。

このGoogle Newsの報道から得られる重要な教訓は、認証が失敗したということではありません。認証は、自律的なワークフローが現在必要とする範囲よりも狭い役割を果たしているのです。

より困難な作業は、アクセスが許可された後に始まります。組織は、エージェントがなぜ行動したのかを証明し、アクセス可能な範囲を制限し、記憶している内容を検査し、あらゆる場所で停止させることができるでしょうか。

今週、1つの本番エージェントを選び、その最後に完了したタスクを再構築してください。いずれかのリンクが欠けていれば、そのギャップが次に構築すべきコントロールを示しています。