本記事は、AIセキュリティとしてのアイデンティティセキュリティをテーマとした7部構成のシリーズの第4回目のブログです。
要約：委任チェーンは、自律型システムにおいて高い影響力を持つ攻撃対象になりつつあります。エージェント間での引き継ぎが発生するたびにアクセス権限が連鎖的に拡大し、非人間アイデンティティのほぼすべて（97%）がすでに過剰な権限を持っている状況では、委任の段階ごとにそのリスクは累積していきます。エージェントセッションスマグリング（2025年11月）として知られる脆弱性では、サブエージェントがルーチン応答にサイレントな株式取引を埋め込みました。親エージェントは、プロンプトもなく、実行内容を把握できないまま、その処理を実行してしまいます。また、クロスエージェント権限昇格（2025年9月）と呼ばれる別の脆弱性では、あるエージェントがタスク実行中に別のエージェントの構成を書き換え、それが自己強化的な制御ループを引き起こす可能性があります。委任そのものが本質的に危険なわけではありませんが、権限のスコープ設定と委任の経路を暗号学的に追跡できる仕組みがなければ、ラテラルムーブメントの直接的な経路となる可能性があります。
エージェントセッションスマグリング：委任が悪用に変わるとき
エージェント間の委任は、設計上、スケールを可能にします。プライマリエージェントが、複雑なタスクを専門化されたサブエージェントに委ね、目的に即した処理を実行するためです。
理論上は、各段階で権限が絞り込まれ、元の意図との整合性が保たれます。しかし実際には、その逆の結果になることが多くあります。
セッションスマグリングのシナリオの一部として使用された概念証明（PoC）では、金融アシスタントエージェントがリサーチエージェントに市場に関する洞察を求めました。サブエージェントは表向きは問題のない要約を返しましたが、その中に株式取引のコマンドが隠されていました。何のアラートも発せられず、その取引は可視化されることなく実行されました。
どのレイヤーも次のレイヤーを信頼し、整合性が検証されることはありませんでした。Unit 42は、この攻撃経路全体がどのように機能するかを次のように概説しています。
- 金融アシスタントが、市場ニュースの取得をリサーチアシスタントに委任
- リサーチアシスタントには悪意があり、応答の中に隠された指示を注入
- 金融アシスタントが10株の無許可取引を実行
- ユーザーに表示されたのはニュースの要約のみで、buy_stockの呼び出しは見えていなかった
「侵害されたエージェントは、より有能な攻撃者となります。AIモデルを基盤としていることにより、適応戦略を自律的に生成し、セッション状態を悪用しながら、接続されているすべてのクライアントエージェントに影響を拡大させることができます」
権限昇格のシナリオがどのように展開されるかを概説する例では、侵害されたあるエージェントが、同列の別エージェントのランタイム環境を変更することができました。不正な設定に改変されたそのエージェントは、攻撃者の到達範囲を拡大し得る方法でタスクを引き渡すことになります。この連鎖が断ち切られない場合、侵害がループバックし、侵入を深刻化させる可能性があります。
エージェントが金融、オペレーション、インフラストラクチャに深く組み込まれるほど、制御されていない委任はより危険なものになります。検証されていないタスクの引き渡しは、それ自体がそのまま侵害につながりかねません。
3つのシステムに共通する欠陥パターン
ServiceNow Now Assist（2025年10月）
AppOmniは、ServiceNowのNow Assistにおいて、低レベルの権限を持つエージェントを使ってエージェント検出機能を悪用することで、より高いレベルの権限を持つエージェントを乗っ取り、データを流出させることが可能であると公表しました。
クロスエージェント権限昇格（2025年9月）
Johann Rehberger氏は、クロスエージェント権限昇格の脆弱性を特定し、侵害されたエージェントが構成を書き換えることによって、他のエージェントを再構成できることを説明しました。Copilot、Claude、Geminiなどの複数のエージェントがコードベースを共有する環境では、プロンプトインジェクション攻撃を受けたCopilotがClaudeの.mcp.jsonを変更できてしまいます。
次の使用では、Claudeは任意のコードを実行し、Copilotを再構成する可能性があります。Rehberger氏は、次のように指摘しています。
「単一の間接的なプロンプトインジェクションとして始まったものが、すぐに複数のエージェントを巻き込んだ侵害にエスカレートする可能性があります」
Microsoft 365 CopilotのEchoLeak（2025年6月）
Aim Securityが発見した「EchoLeak」（CVE-2025-32711、CVSS 9.3）は、メールに隠されたプロンプトによって、SharePoint、Teams、OneDriveのデータが、ユーザーの操作なしに密かに盗み出されてしまうゼロクリック型のエクスプロイトです。
同様の脆弱性パターンは、LLMオーケストレーションフレームワークにも見られます。モデルやツールのチェーンでは通常、スコープ適用が自動で行われないため、開発者は手動で権限縮小を管理しなければなりません。
再帰的な委任：マトリョーシカ問題
マルチエージェントシステムは、タスクの分解を前提に構築されています。プライマリエージェントは、複雑なリクエストをサブタスクに分割し、専門のエージェントに委任します。委任を受けたサブエージェントは、さらに委任を行う場合があります。委任が一段階進むごとに信頼境界を越えるにもかかわらず、元の権限がそのまま引き継がれていきます。
OpenID Foundationのエージェント型AIに関するガイダンスでは、これをエージェントエコシステムの中核的な利点であると同時に、中核的な危険性であもあると位置づけています。「エージェントエコシステムの真の力は、再帰的な委任、つまり、あるエージェントが複雑なタスクを分解し、より専門化された他のエージェントにサブタスクを委任できることから生まれます」。
一方で、その力は見過ごせないリスクもはらんでいます。「再帰的な委任、委任チェーンをまたいだスコープの縮小、説明責任を維持する真のOBO（On-Behalf-Of）ユーザーフロー、さらには異なるエージェントのアイデンティティシステム同士が通信しようとすることで生じる相互運用性の深刻な複雑化により、課題は指数関数的に増大します」。
言い換えれば、エージェント型AIを強力にする要素そのものが、脆弱性にもなり得るということです。アーキテクチャによって、委任の各段階で制御を強制しない限り、この脆弱性は解消されません。
スコープ、出所、コンテキスト = リスクを生み出す3つの構造的ギャップ
1. 委任の各段階でスコープが縮小されない。 委任チェーン内の各エージェントは、前段のエージェントよりも狭い権限を持つべきですが、この最小権限の原則は、実際には守られないことがしばしばあります。エージェントセッションスマグリングのシナリオでは、リサーチエージェントが金融アシスタントのbuy_stockツールへのアクセスを継承し、ニュースの要約に埋め込まれた隠れた取引を実行してしまいました。従来のOAuthトークンは、認証サーバーに再接続しなければ発行後に権限を制限できず、これは分散システムでは成り立ちません。セキュアな委任を実現するには、オフラインでのスコープ縮小をサポートするトークン形式が必要です。これにより、エージェントが自ら個別にアクセスを制限できるようになります。
2. 委任の経路を暗号学的に証明する仕組みがない。 OAuthトークンの構造とステータスは検証できても、履歴を追跡する手段はありません。委任が3段階目に入る頃には、起点となったエージェントやユーザーとの間に、暗号学的な結び付きは失われてしまいます。Aembitは、次のように指摘しています。「暗号学的な証明がなければ、悪意のあるエージェントが委任クレームを偽造し、本来アクセスすべきでないリソースに到達してしまう可能性があります」。
3. セッションをまたいだコンテキストの維持ができない。複数ターンにわたるエージェントのやり取りでは、元のタスクとの整合性を継続的に保つ必要があります。これが欠けると、エージェントがタスクから逸脱し、徐々に意図した範囲を超える行動を取るようになります。Unit 42は「コンテキストグラウンディング」を推奨しており、セッション開始時にタスクのアンカーを作成し、意味的な整合性を継続的に検証することを提唱しています。
スコープの縮小：権限は拡大するのではなく、絞り込むべき
Macaroons、Biscuits、Wafersといった新しいトークン形式は、セキュアな委任チェーンに求められるアーキテクチャを反映しています。各トークンには、アイデンティティ、有効期限、暗号学的ルートといったコア属性があらかじめ組み込まれています。保有者は、権限を減らす方向にのみレイヤーを追加できます。トークンはオフラインでも検証可能であり、特権昇格を防ぎながら、整合性を維持します。
構文は形式によって異なりますが、中核となるパターンは一貫しています。トークンはローカルでスコープを縮小することはできても、拡張することはできません。
各サブエージェントは、トークンのスコープを絞り込む、署名付きの追加専用の制約（caveat）を追加します。これにより、検証可能なチェーンが形成されます。トークンが使用される際、発行者は委任の経路全体を追跡できます。リサーチエージェントがbuy_stockを試みると、リクエストは失敗し、誰が、何を、どの段階で制限したかの証明とともに、追跡可能な形で記録されます。
現在、MacaroonsまたはBiscuitsをネイティブでサポートしている主要なアイデンティティプロバイダーはありませんが、これらの中核となる原則オフラインでのスコープ縮小、暗号学的な委任、追記専用の制約）は、既存のOAuthインフラを用いて、すでに実装可能です。
再帰的な委任を悪用する攻撃からの防御
AIエージェントの委任に関連するこれらの脆弱性から、次の4つの防御要件が導き出されます。
1. 帯域外での確認：機密性の高い操作には、エージェントがアクセスできないチャネル（チャットではなく、プッシュ通知や別のUIなど）を介した人間の承認を要求する。
2. コンテキストグラウンディング：セッションを元のタスクに固定し、実行前に意味的な逸脱をフラグする。
3. 検証可能なアイデンティティと権限：エージェントは署名付きの認証情報（暗号学的なAgentCardsなど）の提示を要求する。
4. ユーザーに対する可視性：不正な指示は、隠れている場合に成功するため、ツールの呼び出しとログを可視化する。
再帰的な委任に対するOktaとAuth0のアプローチ
これらの制御を個別に実装すると、見落としが生じる可能性があります。OktaとAuth0は、統合されたアイデンティティレイヤーを通じて、再帰的な委任への対処を支援します。
Cross App Access（XAA）。OktaおよびAuth0全体で利用可能なXAAは、同意の管理をアイデンティティプロバイダー側に移行します。2025年11月より、「Enterprise-Managed Authorization」の下でMCPの一部として提供されています。ID-JAGに基づき、委任の経路を追跡し、失効できるため、エージェントのアクションがログに記録され、必要に応じて取り消すことができます。
Token Vault。Auth0 Token Vaultは、エージェントの認証情報アクセスにおける混乱した代理人（Confused Deputy）問題を解決します。安易なAPI設計では、開発者がuserIdパラメーターを渡せてしまうため、バグやプロンプトインジェクションによって、別のユーザーの認証情報が取得されるリスクが生じます。Token Vaultは、単なる識別子ではなく、現在のユーザーセッションに対する暗号学的な証明を要求することで、この問題を解消します。エージェントは、OAuth 2.0 Token Exchange（RFC 8693）を使用して、セッショントークンを有効期間が短く、スコープが限定された認証情報に変換し、標準プロトコルを介して厳密なスコープ縮小を実現します。
Asynchronous Authorization。Auth0 Async Authは、プッシュ通知やメールを介した帯域外承認を可能にし、LLMが操作できないチャネルでの人間による確認を必須とすることで、エージェントセッションスマグリングの脆弱性に直接対処します。
Fine Grained Authorization（FGA）。GoogleのZanzibarモデルを基盤とするAuth0 FGAは、すべての呼び出しに対して関係性に基づくアクセス制御を適用します。エージェントは委任チェーンの各段階で委任状態を検証・更新し、権限を段階的に絞り込みます。このステートフルなコンテキストは、トークンではなくFGA側に存在するため、新しいトークン形式を必要とせずに、ケイパビリティベースのスコープ縮小を実現できます。
Identity Governance。Okta Identity Governanceは、ライフサイクル管理をエージェントに拡張し、役割やプロジェクト、セキュリティコンテキストの変化に応じて、委任された権限が見直し・失効されるようにします。デプロイ時には適切だった権限も、短期間で過剰になる可能性があります。ガバナンスにより、エージェント権限の範囲を継続的に適正化できます。
今後の方向性：自己証明型の委任
マルチエージェントシステムは、単一のエージェントでは実現できない能力をもたらす一方で、従来のIAMでは対応できないギャップも露呈させます。ここで取り上げたすべての脆弱性に共通するのは、エージェントが意図された以上の権限を取得し、ユーザーに見えない状態で動作し、監査証跡を残さないというパターンです。
委任をセキュア化するには、4つの基盤が必要です。すべての段階でのスコープ縮小、トークンレベルの経路検証、持続的なコンテキストの整合、そして機密性の高いアクションに対する帯域外での人間による承認です。
これらは、もはやオプションではありません。EU AI 法の下では、ハイリスクなシステムにおけるトレーサビリティと監督は法的義務です。第14条では、人間がAIの動作を完全に理解し、監視することを要求しています。
検証可能な委任チェーンがなければ、そのレベルの監督は成立しません。インフラが監査可能な制御を備えていなければ、それ自体がコンプライアンス上のリスクとなります。
次回（ブログ第5回目）: AIエージェントがデジタルなワークフローから物理システムへと移行し、たった一つのミスが現実世界の被害につながり得る状況で何が起こるのか、そしてアイデンティティが最後の防衛線となる理由について説明します。
