委任の連鎖、代理人の権限悪用リスク、そして実際にデプロイされるプロトコル

AIエージェントが単独で完結する仕事は、ほとんどありません。 ユーザーがエージェントに頼み、そのエージェントがツールを呼び出し、さらにそのツールが別のエージェントを呼び出す。仕事が完了する頃には、3つまたは4つのアクターがそのリクエストに関与しており、それぞれが1つ前のアクターの代理として行動しています。

アイデンティティはその呼び出しの連鎖（委任経路）を越えて引き継がれなければなりません。中継（ホップ）ごとに、1つではなく2つの質問に答える必要があります。それは、「元々これをリクエストしたのは誰か？」そして「この特定呼び出しを行っているアクターは誰か？」です。どちらかの回答を失えば、呼び出しを正しく認可することも、あとからそれを説明（監査）することもできなくなります。

経緯全体を支える2つの属性データ

標準規格はすでにこれをモデル化しています。RFC 8693はトークン交換（Token Exchange）を定義しています。アクターは、それまでに誰が存在したかという引き継ぎの経緯を破棄することなく、受け取ったトークンを新しいトークンと交換して次の呼び出しを行います。このトークンは、ここで重要となる2つの属性データを保持します。

sub（サブジェクト）は主体、すなわち元の主体（オリジナル・プリンシパル）を表す属性データです。これはプロセス全体を開始したユーザーであり、リクエストが呼び出し経路を進んでも変更されません。

act はアクター、すなわち現在の呼び出しを行っている当事者を表す属性データです。こちらは変更されます。そして、あるエージェントが別のエージェントを呼び出すと、act は入れ子（ネスト）構造になります。つまり、「ユーザーの代理として行動するエージェントA」の代理として「エージェントB」が行動する、という形です。ネストされた act こそが、複数段階に及ぶ呼び出し経路を誠実に表現する唯一の方法です。なぜなら、各リンクを崩してフラット化することなく、すべての経緯を保持できるからです。

図1. 保存された委任の連鎖。sub はユーザーのまま固定され、act は中継ごとにネストされ、すべての接続履歴を検証・検査できます。下部：再発行されたトークンによって平坦化された呼び出し経路。元の主体は失われ、ダウンストリーム（後続処理）で過剰な権限付与が発生します。

この典型的な失敗パターンには名前があります

近道となるのは、呼び出しの履歴をフラット化することです。トークンを交換して act をネストさせる代わりに、エージェントは実質的に「これは私であり、私自身の代理として呼び出している」と宣言する新しいトークンを再発行（リミント）します。この方がシンプルです。しかし、これは委任の連鎖を破壊することでもあります。

この場合、sub はユーザーではなくエージェントを指すようになります。元の主体は消滅します。それとともに帰属の特定（誰の実行か）も失われます。ダウンストリームのツールにはエージェントしか見えず、誰のリクエストによってこれが始動したのかを知る術がありません。そして、ツールはエージェントのアイデンティティしか認識しないため、この特定のタスクが許可すべき範囲よりも広い「エージェント自身の権限」に基づいて認可を行ってしまいます。結果として、ダウンストリームの呼び出しごとに過剰な権限付与（オーバーグラント）が発生することになります。

これこそが代理人の権限悪用リスク（Confused Deputy：惑わされた代理人問題）です。誰か他の人に与えられた権限をもって動作しているプロセスが、権限の付与者が意図しなかった目的のために悪用されてしまう現象を指します。フラット化されたトークンは、エージェント・システムにおいて Confused Deputy が作り出される原因そのものです。そして、保存された委任経路こそが、それを回避する方法です。その差は、ツールの側で「誰が依頼し、誰が行動しているのか」を最後まで確認できる状態になっているかどうかにあります。

実務において委任経路が存続するか破綻するか

これは単なる標準規格の理論にとどまりません。主要なターゲット層がまさに今デプロイしている2つのプロトコル表面（プロトコル・サーフェス）において、引き継ぎの経緯が保存されるか破壊されるかが決まります。

エージェントからツールへの通信は、MCP（Model Context Protocol）上で行われます。2025年半ばのMCP仕様では、OAuth 2.1およびRFC 9728が採用されました。これが重要なのは、エージェントがハードコーディングに頼るのではなく、ツールがどのような認可を要求しているかを動的に検出できるようになるためです。エージェントはリソースのメタデータを読み取り、トークンをどこで取得すべきか、どのようなスコープが必要かを把握し、まさに必要なものだけを要求します。この動的検出こそが、実行時における「スコープ定義されたツールごとの認可」を実用的なものにしています。

ここで、デプロイされている現実を直視する必要があります。仕様が存在することと、実際に稼働しているものが一致しているとは限らないからです。野良で動いているMCPサーバーの大部分は、脆弱な認可メカニズムで運用されているか、あるいは認可そのものが存在しない状態（欠落した状態）で出荷されています。プロトコル自体はこれを正しく行うことをサポートしています。しかし、多くのデプロイ環境ではそうなっていません。このギャップこそが本シリーズ全体のテーマです。標準規格は存在しているのに、その上に構築されたシステムは委任の連鎖を保護するための重要な部分をスキップしてしまっているのです。

エージェントからエージェントへの通信は、A2Aおよびその「Agent Cards」上で行われます。Agent Card とは、エージェントが何であるか、何ができるか、そしてどの認証スキームを受け入れかを検出可能な形で宣言したものです。人間が事前に対象の2つを配線接続することなく、あるエージェントが別のエージェントの呼び出し方を学習するための仕組みです。また、このカードは「エージェントが委任トークンを要求しているか」あるいは「送られてくるものであれば何でも快く受け取ってしまうか」を表明する場所でもあります。ご自身の好みのエコシステム内にある Agent Cards を読み解いてみてください。それらは、どこで引き継ぎの経路が尊重され、どこでフラット化されようとしているのかを明確に教えてくれます。

これら2つの表面（MCPとA2A）は、委任の連鎖がエンドツーエンドで検査可能に保たれるか、あるいは誰が行動しているかについて嘘をつくトークンへとひそかに崩壊させられるかの「具体的な境目」なのです。

図2. MCPはエージェントからツールへの呼び出しを担い、A2Aはエージェントからエージェントへの呼び出しを担います。これらは、委任の連鎖が実務において保存されるか破壊されるかを分ける2つの表面です。

まとめ

委任とは、ラインの下流へそのまま手渡される単一のトークンではありません。それは「委任の連鎖（一連の引き継ぎ経路）」であり、健全な経路とは、すべての段階において検査可能なものです。すなわち、sub が元の主体に固定され、act がリクエストに関与したすべての各アクターを経てネストされている状態を指します。これをフラット化してしまえば、過剰な権限を付与し、監査も不可能な Confused Deputy を自ら構築することになります。

自社のシステムにおいて、引き継ぎの経緯が維持されているか失われているかは、MCPとA2Aの地点で決まります。
以下の2点を確認してください。