【2026年版】マルチエージェントの「委任チェーン」セキュリティガイド——”誰の権限で動いているか”が3段目で消える手口と、トークン交換（RFC 8693）による権限の絞り込み・委任の深さ制限・来歴つきトークン・終点での再認可による多層防御

これまでのAIセキュリティ記事では、Confused Deputy（混乱した代理人）のような「1段の代理実行」で起きる混乱や、NHI（非人間ID）管理のような「エージェント1体ごとのIDと権限」をどう守るかを扱ってきました。しかし2026年、マルチエージェント構成が本番環境に広がるにつれ、もう一つの攻撃面がはっきり見えてきました。それは、エージェントからエージェントへ仕事が受け渡される「委任の連鎖（委任チェーン）」そのものです。

「ユーザー → オーケストレーター → サブエージェント → MCPサーバー」と仕事が多段で渡されるたびに、元のユーザーの権限がそのまま引き継がれたり、途中で広がったりします。そして3段目のエージェントが「誰の依頼で、どこまでの権限で」動いているのか、誰にも答えられない状態になります。本稿では、この委任チェーンを独立した攻撃面として整理し、トークン交換（RFC 8693）による権限の絞り込み、委任の深さ制限、来歴つきのアクセストークン、終点での再認可を組み合わせた多層防御の設計を解説します。

  1. はじめに——守る対象が「エージェント1体」から「エージェント間の受け渡し」へ
  2. 前提——委任チェーンで何が起きるのかを整理する
    1. 典型的なマルチエージェント構成
    2. 委任で守るべき4つの性質
    3. 標準仕様での位置づけ
  3. 攻撃の見え方——”誰の権限か”が消えていく5つの手口
    1. 手口1：トークンの素通し（パススルー）
    2. 手口2：権限の洗浄（サービスアカウントへのすり替え）
    3. 手口3：来歴の消失
    4. 手口4：無制限の再委任とループ
    5. 手口5：期限と目的の漂流
  4. 第1の防御層：トークン交換（RFC 8693）で、段ごとに権限を絞り込む
    1. 基本原則：「渡す」のではなく「交換する」
    2. 認可サーバー側で強制すべきルール
    3. 「権限の洗浄」を構造的に防ぐ
  5. 第2の防御層：委任の深さ・期限・目的に上限をかける
    1. 委任の深さ制限
    2. 期限の単調減少
    3. 目的（purpose）の固定
  6. 第3の防御層：来歴つきのアクセストークンで「誰の依頼か」を終点まで運ぶ
    1. トークンに載せるべき来歴情報
    2. 注意点：入れ子の act は”記録”であって”認可の根拠”ではない
    3. ログ相関：タスクIDを全段で引き継ぐ
  7. 第4の防御層：終点での再認可——「トークンが有効」だけで通さない
    1. なぜ終点で再確認するのか
    2. 終点で確認すべき項目
    3. 段階的レスポンス
  8. 検知→遮断→監査のインシデント連携
  9. 多層防御チェックリスト
  10. よくある質問（Q&A）
    1. Q1. エージェントがすべて社内ネットワーク内で動いていれば、トークンの素通しでも問題ないのでは？
    2. Q2. 自社の認可サーバーがRFC 8693に対応していません。どこから始めればよいですか？
    3. Q3. 委任の深さは何段まで許すべきですか？
    4. Q4. 終点で毎回再認可すると、レイテンシが増えませんか？
    5. Q5. A2A（Agent2Agent）プロトコルを使っていれば、この問題は解決しますか？
  11. まとめ——「委任するたびに、権限は絞られ、来歴は増える」を設計の原則に
  12. 参考リンク

はじめに——守る対象が「エージェント1体」から「エージェント間の受け渡し」へ

エージェントが1体だけなら、セキュリティの問いはシンプルです。「このエージェントにどのIDを与え、どこまでの権限を持たせるか」を決めれば済みます。

ところがマルチエージェント構成では、問いが変わります。オーケストレーターがリサーチ担当のサブエージェントに仕事を渡し、そのサブエージェントがさらに社内データ担当のエージェントやMCPサーバーを呼び出す。このとき問題になるのは、各段で「誰の権限を」「どこまで」「いつまで」受け渡しているかです。

OWASPが2025年12月に公開した「OWASP Top 10 for Agentic Applications 2026」でも、ASI03: Identity & Privilege Abuse（IDと権限の悪用）の中で、委任チェーン、キャッシュされた認証情報、暗黙のIDを悪用して「元の持ち主が意図しなかった操作」を行わせるリスクが明示されています。高権限のエージェントが、低権限のエージェントに認証情報を丸ごと渡してしまう「推移的な権限継承」も、代表例として挙げられています。

本稿の位置づけを、これまでの記事と比べて整理しておきます。

既存記事テーマ本稿との違い
Confused Deputy1段の代理実行で起きる混乱本稿は多段の委任で権限が広がる・失われる問題
NHI管理／権限⑥エージェント1体ごとのIDと権限のライフサイクル本稿はエージェント間で権限を受け渡すときの規律
OAuth同意フィッシング人間が最初に出す同意を狙う攻撃本稿は同意したあとに起きる再委任の問題
AIワーム悪意ある指示がエージェント間を伝播する話本稿は正当な委任でも起きる権限の漂流

ポイントは最後の行です。委任チェーンの問題は、攻撃者がいなくても起きます。正当な業務フローの中で、権限が少しずつ広がり、来歴が少しずつ失われていく。そこへプロンプトインジェクションや乗っ取られたエージェントが加わると、広がった権限がそのまま攻撃者の手に渡ります。

前提——委任チェーンで何が起きるのかを整理する

典型的なマルチエージェント構成

本稿では、次のような4段構成を例にします。

  1. ユーザー（営業部の田中さん）が「A社との過去の取引をまとめて、提案書の下書きを作って」と依頼する
  2. オーケストレーターがタスクを分解し、リサーチ担当エージェントに「A社の取引履歴を集めて」と委任する
  3. リサーチ担当エージェントが、CRMとファイルサーバーのMCPサーバーを呼び出す
  4. MCPサーバーが、CRMやファイルストレージのAPIにアクセスする

田中さんが見ることを許されているのは、自分の担当顧客のデータだけです。ところが4段目のAPIから見ると、届いたリクエストが「田中さんの依頼」なのか「誰かの依頼」なのか、区別できなくなっていることが少なくありません。

委任で守るべき4つの性質

多段の委任を安全にするには、各段で次の4つが保たれている必要があります。

性質意味崩れたときの症状
単調減少（Attenuation）下の段に渡す権限は、上の段の権限の部分集合でなければならない3段目が1段目より広い権限で動く
来歴（Provenance）「誰の依頼で、どの経路を通ってきたか」が終点まで残るログにサービスアカウント名しか残らない
有界性（Boundedness）委任の深さ・期限・目的に上限があるエージェントが無制限に再委任し、元の依頼が終わっても動き続ける
失効の伝播（Revocability）元のユーザーの権限が取り消されたら、チェーン全体が止まる退職者・異動者の依頼で始まった処理が動き続ける

標準仕様での位置づけ

  • RFC 8693（OAuth 2.0 Token Exchange）：受け取ったトークンを、別の相手・別の範囲向けのトークンに交換する仕組み。「誰に代わって（subject）」「誰が（actor）」動いているかを act クレームで表現できます
  • RFC 8707（Resource Indicators）：トークンをどのリソース向けに発行するかを指定し、他のサービスで使い回せないようにする仕組み
  • RFC 9396（Rich Authorization Requests）：「A社の取引データを読み取りのみ」のように、スコープより細かい権限を表現する仕組み
  • Transaction Tokens（IETF OAuth WGのドラフト）：1つのトランザクションの中で、ユーザーID・ワークロードID・認可コンテキストを呼び出しチェーン全体に伝える短命トークン。2026年時点ではまだドラフト段階です
  • MCP仕様（2026-07-28版）：MCPサーバーは自分宛てに発行されたトークンだけを受け入れ、受け取ったトークンを上流APIにそのまま渡す「トークンパススルー」は禁止（MUST NOT）と明記されています

攻撃の見え方——”誰の権限か”が消えていく5つの手口

手口1：トークンの素通し（パススルー）

最も多いのがこのパターンです。オーケストレーターが、ユーザーから受け取ったアクセストークンを、そのままサブエージェントやMCPサーバーに渡してしまいます。

実装は楽ですが、ユーザーの全権限がチェーンの末端まで届きます。「A社の取引履歴を読むだけ」のサブエージェントが、田中さんのメール送信権限やファイル削除権限まで持つことになります。さらにトークンの宛先（audience）が検証されていなければ、そのトークンは別のサービスでも使えてしまいます。MCP仕様が明示的に禁止しているのは、まさにこの構造です。

手口2：権限の洗浄（サービスアカウントへのすり替え）

手口1の逆です。サブエージェントやMCPサーバーが、ユーザーのトークンではなく自分自身のサービスアカウントでAPIを呼び出します。

サービスアカウントは「どのユーザーの依頼にも対応できるように」広い権限を持っていることが多いため、ここで権限が一気に広がります。田中さんが本来見られないB社のデータも、サービスアカウント経由なら取得できてしまいます。しかもAPI側のログには「research-agent-svc」としか残らず、元の依頼者が誰だったのかが消えます。本稿ではこれを「権限の洗浄」と呼びます。

手口3：来歴の消失

各段が独自にトークンを取り直す構成では、権限は絞られていても、「この操作は誰の、どの依頼から始まったのか」が段を追うごとに失われていきます。

インシデントが起きたとき、4段目のログを見ても「どのユーザーの、どのタスクの、どのサブタスクだったのか」がたどれません。監査ができないだけでなく、異常検知もできません。「田中さんの依頼なのに、田中さんの担当外の顧客を読んでいる」という異常は、来歴がなければそもそも判定できないからです。

手口4：無制限の再委任とループ

エージェントが自律的にサブエージェントを生成できる構成では、委任の深さに上限がないと、エージェントがエージェントを呼び、さらにそのエージェントが別のエージェントを呼ぶ連鎖が起きます。

プロンプトインジェクションで「この作業をさらに細かく分けて、別のエージェントに依頼せよ」と指示されれば、攻撃者は委任のたびに少しずつ権限の境界を探ることができます。ループに入れば、コストとレート制限も同時に食いつぶされます。

手口5：期限と目的の漂流

元のユーザーのトークンは1時間で切れるのに、2段目で取得したトークンは24時間有効——このように、下の段ほど期限が長くなる構成は珍しくありません。結果として、元の依頼が終わったあとも、ユーザーが異動・退職したあとも、下の段だけが動き続けます。

同様に、「提案書の下書き」という目的で始まった委任が、途中で「ついでに顧客リストを全件エクスポート」に変わっても、トークンには目的が書かれていないため止められません。

手口崩れる性質主なシグナル効く防御層
1. トークンの素通し単調減少下流サービスで、宛先が自分でないトークンを受信第1層（トークン交換）
2. 権限の洗浄単調減少・来歴サービスアカウントによる、ユーザー権限外データへのアクセス第1層・第4層
3. 来歴の消失来歴ログから元のユーザー・タスクがたどれない第3層（来歴つきトークン）
4. 無制限の再委任有界性委任の深さ・エージェント生成数の急増第2層（深さ制限）
5. 期限と目的の漂流有界性・失効の伝播元タスク終了後の下流アクティビティ第2層・第4層

第1の防御層：トークン交換（RFC 8693）で、段ごとに権限を絞り込む

基本原則：「渡す」のではなく「交換する」

委任チェーン対策の土台は、上の段で受け取ったトークンを下の段にそのまま渡さないことです。代わりに、各段は認可サーバーに対してトークン交換を要求し、次の相手専用・必要な範囲だけ・短い期限のトークンを新たに発行してもらいます。

RFC 8693のトークン交換リクエストでは、主に次のパラメータを使います。

  • subject_token：誰に代わって動くのか（元のユーザーのトークン、または上の段から受け取ったトークン）
  • actor_token：実際に動くのは誰か（このエージェント自身のワークロードID）
  • resource / audience：新しいトークンを使う相手（次の段のエージェントやMCPサーバー）
  • scope：必要な権限（元の権限より狭くする）

認可サーバー側で強制すべきルール

トークン交換は、仕組みを入れただけでは安全になりません。認可サーバー（またはその前段のポリシーエンジン）で、次のルールを強制することが重要です。

  1. スコープは部分集合のみ：交換後のスコープが、subject_token のスコープを1つでも超えたら拒否する
  2. 宛先は必須：resource または audience の指定がないリクエストは拒否する
  3. 期限は短くなる方向のみ：交換後の有効期限は、元トークンの残り時間を超えない
  4. 委任を許す相手を限定：may_act クレームや事前登録したポリシーで、「このオーケストレーターは、このサブエージェントにのみ委任できる」と決めておく
  5. なりすまし（impersonation）ではなく委任（delegation）を使う：RFC 8693は両方を区別しています。なりすましでは発行されたトークンから「代理で動いている」ことが見えなくなるため、エージェント間の受け渡しでは act クレームを残す委任型を原則にします

「権限の洗浄」を構造的に防ぐ

手口2（サービスアカウントへのすり替え）を防ぐには、ユーザー起点のタスクでは、下流のAPI呼び出しにユーザーのコンテキストを必ず載せることをルール化します。サービスアカウント単独でのデータアクセスは、バッチ処理などユーザーが存在しない処理に限定し、エージェント経由の呼び出しでは使わせない。API側でも「エージェントのワークロードIDから、ユーザーコンテキストなしで来たリクエスト」を拒否するか、少なくとも高リスクとして扱います。

第2の防御層：委任の深さ・期限・目的に上限をかける

委任の深さ制限

RFC 8693の act クレームは入れ子にでき、チェーンの各段を表現できます。認可サーバーはトークン交換のたびにこの入れ子の深さを数え、上限を超える交換を拒否します。

実務的には、次のような上限から始めるのがおすすめです。

  • 通常の業務フロー：ユーザー → オーケストレーター → サブエージェント → ツール（MCPサーバー）の3段まで
  • 書き込み・送信・削除を伴うフロー：2段まで。それより深い委任が必要な設計は、そもそも見直す
  • エージェントの動的生成：1タスクあたりのサブエージェント生成数にも上限を設ける

期限の単調減少

交換後のトークンの期限は、「元トークンの残り時間」と「そのタスク種別に許される最大時間」の短い方にします。長時間かかる処理でも、下の段だけが長生きするトークンは発行しません。必要なら、上の段が生きていることを確認してから再交換させます。

目的（purpose）の固定

トークンに「何のための委任か」を載せ、下の段で変更できないようにします。RFC 9396（Rich Authorization Requests）の authorization_details を使えば、「顧客A社の取引データを読み取りのみ」のような細かい範囲を表現できます。Transaction Tokensのドラフトでも、チェーン全体で変わらない認可コンテキストを持たせる設計になっています。

第3の防御層：来歴つきのアクセストークンで「誰の依頼か」を終点まで運ぶ

トークンに載せるべき来歴情報

委任型のトークン交換を使うと、トークンの中に「誰に代わって、誰が動いているか」が残ります。たとえば3段目のMCPサーバーが受け取るトークンは、概念的には次のような形になります。

{
  "sub": "tanaka@example.co.jp",        // 元のユーザー
  "aud": "https://mcp-crm.example.co.jp", // このMCPサーバー専用
  "scope": "crm.deals.read",
  "exp": 1790000000,
  "txn": "task-7f3a...",                // 元タスクのID
  "act": {                               // 現在の実行者
    "sub": "agent:research",
    "act": {                             // 1つ前の実行者
      "sub": "agent:orchestrator"
    }
  }
}

このトークンを見れば、4段目は「田中さんの依頼で、オーケストレーター → リサーチ担当の順に委任され、CRMの取引データを読み取りのみ」と判断できます。

注意点：入れ子の act は”記録”であって”認可の根拠”ではない

RFC 8693では、アクセス制御の判断に使うのはトップレベルのクレームと、現在の実行者（最も外側の act）だけで、入れ子になった過去の実行者は情報提供のためのもの、と定めています。つまり、入れ子の act は監査や異常検知には使えますが、「途中にオーケストレーターが入っているから許可」といった認可判断の根拠にはしないのが原則です。チェーンの経路そのものを認可条件にしたい場合は、認可サーバーがトークン交換の時点で経路を検証し、その結果をトップレベルのクレームに反映させる設計にします。

ログ相関：タスクIDを全段で引き継ぐ

トークンとは別に、元タスクのID（上の例の txn）を、全段のログ・トレースに必ず記録します。OpenTelemetryなどの分散トレーシングと組み合わせれば、「田中さんの依頼から始まった処理が、どのエージェントを通り、どのAPIを何回叩いたか」を1本の線として再構成できます。これが、第4層の再認可と、インシデント対応の両方の前提になります。

第4の防御層：終点での再認可——「トークンが有効」だけで通さない

なぜ終点で再確認するのか

第1〜3層がすべて機能していても、トークンはあくまで「発行時点の判断」です。チェーンの途中でユーザーの権限が変わったかもしれませんし、上の段のエージェントがプロンプトインジェクションで乗っ取られているかもしれません。そこで、実際にデータを返したり、操作を実行したりする終点（リソースサーバー・MCPサーバー）で、もう一度認可判断を行います。

終点で確認すべき項目

  1. 宛先の検証：トークンの aud が自分自身か（違えば拒否。MCP仕様でもMUST）
  2. 元ユーザーの現在の権限：sub のユーザーが、今この時点でそのデータにアクセスできるか（異動・退職・権限変更を反映）
  3. 目的との整合：要求された操作が、トークンに載った目的・範囲に収まっているか
  4. 深さと経路：委任の深さが上限内か、想定外のエージェントを経由していないか（監査ログへの記録と異常検知）
  5. リスクに応じた追加確認：大量取得・外部送信・削除などの高リスク操作では、元のユーザーへのステップアップ認証や、人間による承認を求める

段階的レスポンス

段階条件の例レスポンス
通常宛先・範囲・深さすべて想定内許可し、来歴つきでログ記録
注意深さが上限に近い、取得件数がいつもより多い許可しつつアラート、レスポンス件数を制限
確認書き込み・外部送信・削除、または担当外データへのアクセス元のユーザーに承認を求める（ステップアップ）
遮断宛先不一致、範囲外、深さ超過、元ユーザーの権限失効拒否し、同じタスクIDのチェーン全体を停止

検知→遮断→監査のインシデント連携

委任チェーンのインシデント対応で重要なのは、1つの段で異常を見つけたら、同じタスクIDに連なるチェーン全体を止められることです。

  1. 検知：終点での拒否、深さ超過、サービスアカウント単独アクセス、元タスク終了後のアクティビティなどをシグナルとして集約する
  2. 遮断：該当タスクIDから派生したトークンをまとめて失効させる。短い期限のトークンを使っていれば、失効が間に合わなくても被害時間を限定できる
  3. 監査：タスクIDでトレースをたどり、「元のユーザーは誰か」「どの段で権限が広がったか」「何のデータが読まれたか」を確定する
  4. 是正：権限が広がった段のトークン交換ポリシー、または委任を許可する相手の設定を見直す

ユーザーの退職・異動時には、ID管理システムからの通知で、そのユーザーを sub に持つ進行中のタスクを洗い出して停止する運用も組み込んでおきます。

多層防御チェックリスト

層対策主に効く手口
第1層：権限の絞り込み受け取ったトークンを下流に素通ししない（トークン交換を必須化）1
第1層交換後のスコープは元の部分集合のみ。超えたら拒否1・2
第1層全トークンに宛先（resource / audience）を必須化1
第1層ユーザー起点のタスクで、サービスアカウント単独のデータアクセスを禁止2
第2層：上限委任の深さ上限（通常3段、書き込み系は2段）4
第2層交換後のトークン期限は元の残り時間以下5
第2層目的・範囲をトークンに固定（RAR等）5
第3層：来歴委任型（act クレーム）を使い、なりすまし型を使わない3
第3層タスクIDを全段のログ・トレースに記録3
第4層：終点終点で宛先・現在の権限・目的・深さを再確認1〜5
第4層高リスク操作は元のユーザーに承認を求める2・5
運用タスクID単位でチェーン全体を停止できる仕組み全般
運用退職・異動時に、該当ユーザー起点の進行中タスクを停止5

よくある質問（Q&A）

Q1. エージェントがすべて社内ネットワーク内で動いていれば、トークンの素通しでも問題ないのでは？

問題があります。委任チェーンのリスクは、外部からの侵入だけではありません。社内のサブエージェントがプロンプトインジェクションで乗っ取られた場合、素通しされたユーザーの全権限がそのまま悪用されます。また、来歴が残らないため、問題が起きても原因の段を特定できません。ネットワークの内側かどうかにかかわらず、「段ごとに交換し、絞る」を原則にしてください。

Q2. 自社の認可サーバーがRFC 8693に対応していません。どこから始めればよいですか？

まず「トークンを下流に素通ししない」「下流のAPI呼び出しにユーザーIDとタスクIDを必ず載せる」の2点から始めてください。RFC 8693に対応したIDaaSや認可サーバーへの移行は中期的な課題として、短期的にはエージェント基盤側のゲートウェイで、宛先ごとに権限を絞ったトークンを発行し直す仕組みを用意する方法もあります。重要なのは、仕様名よりも「単調減少」「来歴」「有界性」「失効の伝播」の4つの性質を保つことです。

Q3. 委任の深さは何段まで許すべきですか？

業務によりますが、目安は「通常の読み取り系は3段、書き込み・送信・削除を伴うものは2段」です。それ以上深い委任が必要になる設計は、責任の所在があいまいになりやすく、テストもしにくくなります。深さが必要に見える場合は、タスクの分解の仕方そのものを見直すことをおすすめします。

Q4. 終点で毎回再認可すると、レイテンシが増えませんか？

増えますが、すべてを重くする必要はありません。宛先や期限の検証はトークンの検証だけで済み、ほぼコストはかかりません。「元のユーザーの現在の権限」の確認はキャッシュを短時間使うことで負荷を抑えられます。人間の承認を求めるのは高リスク操作に限定し、段階的レスポンスで重さを使い分けるのが現実的です。

Q5. A2A（Agent2Agent）プロトコルを使っていれば、この問題は解決しますか？

A2Aのようなエージェント間通信プロトコルは、エージェント同士がやり取りする方法を標準化しますが、「どの権限を、どこまで受け渡すか」の規律は、各組織の認可設計に委ねられています。プロトコルを採用しても、トークン交換による絞り込み、深さ制限、来歴の伝達、終点での再認可は、別途設計する必要があります。

まとめ——「委任するたびに、権限は絞られ、来歴は増える」を設計の原則に

マルチエージェントの議論は、これまで「どのエージェントに何を任せるか」という機能面が中心でした。しかし本番運用で問われるのは、仕事が受け渡されるたびに、誰の権限がどこまで届いているかです。要点は3つです。

  1. トークンは渡さず、交換する。各段で、次の相手専用・必要な範囲だけ・短い期限のトークンを発行し、権限が下の段ほど狭くなる構造にする
  2. 委任には上限と来歴をつける。深さ・期限・目的に上限をかけ、元のユーザーとタスクIDを終点まで運ぶ
  3. 終点で、もう一度確かめる。トークンが有効かどうかだけでなく、元のユーザーの現在の権限と目的に照らして再認可し、異常があればチェーン全体を止める

「3段目のエージェントは、誰の依頼で、どこまでの権限で動いているのか」——この問いに、ログを見ればすぐ答えられる状態を作ることが、マルチエージェント時代の権限管理のゴールです。

参考リンク

関連記事：

免責事項：本記事は2026年10月時点の公開情報および標準仕様・フレームワークに基づく一般的な情報提供であり、特定の製品や環境での安全性を保証するものではありません。IETFのドラフトやMCP仕様、OWASPのガイドラインは更新されるため、最新情報は各公式ソースでご確認ください。実際の設計・導入にあたっては、自社の環境に合わせて専門家にご相談ください。

コメント

タイトルとURLをコピーしました