8月28日、Cerbosが「Multi-hop delegation for AI agents, and how the consent chain gets lost」と題した記事を公開した。AIエージェントが複数のホップをまたぐ委任チェーンにおいて、ユーザーのIDと同意情報がどのように失われるか、そしてそれをどう防ぐかについて詳しく解説している。Gartnerは2026年末までにエンタープライズアプリの40%がタスク特化型AIエージェントを含むと予測する一方、アジェンティックAIプロジェクトの40%超が2027年末までにリスク管理の不備を理由にキャンセルされると見込んでいる。その「リスク管理の不備」の中核にある問題が、この委任チェーンの設計だ。
チェーンが壊れる、その具体的な理由
デモでは「1エージェント→1ツール」で完結する。だが本番はそうならない。ユーザーのリクエストを受けたエージェントがサブエージェントに委任し、そのサブエージェントがツールを呼び、ツールがデータベースに触れる。リクエストがデータに到達するころには4つのパーティを通過しており、本来その処理を制約すべき2つの情報——「誰が依頼したか」と「何に同意したか」——がたいていの場合、途中で消えている。
これがマルチホップ委任問題だ。現状のツールがエージェントセキュリティの中で最も対処できていない部分である。
チェーンが崩壊するパターンは大きく3つある。
1. トークンの素通り転送（Blind token forwarding）
最も手軽な方法は、受け取ったアクセストークンをそのまま次のホップに転送することだ。だが、これはセキュリティを破壊する手口でもある。Model Context Protocol（MCP）のセキュリティガイダンスはこの点について明確に警告している。MCPサーバーは、自分向けに明示的に発行されていないトークンを受け入れてはならない。転送するプロキシは「混乱した代理人（confused deputy）」になり得る——1988年に命名された古典的な問題だが、エージェントは個々のユーザーより広い権限を持つため、攻撃面が大幅に拡大する。
2. リクエストにIDが含まれていない
Linux Foundation傘下となったGoogleのAgent2Agentプロトコルは、ペイロードにユーザーやクライアントのIDを直接含まない設計になっている。IDはトランスポート層でエージェント間に確立される。合理的な設計ではあるが、エージェント間でワークを転送するプロトコル自体がユーザーの委任情報を運ばないため、別の仕組みが必要になる。
3. 委任に偽装した「なりすまし」
RFC 8693（OAuth Token Exchange）はここの線引きを明確にしている。なりすまし（impersonation）はダウンストリームの主体がユーザーと区別できなくなること、委任（delegation）はエージェントが自分のIDを保ちつつユーザーを代理することだ。大半のナイーブな実装はなりすましになる。実装が楽だからだ。委任チェーンが"acting party"（代理実行者）を失った瞬間、ホップごとの追跡も監査も不可能になる。
この問題の深刻さを示すデータがある。CyberArkの2026年調査によると、91%の組織で特権アクセスの半数以上が常時オンになっており、Just-in-Timeアクセスに完全移行できているのはわずか**1%**にとどまる。常時オンの特権アクセスが広く残存したまま委任チェーンが適切に制御されなければ、一つのホップの侵害が連鎖的な被害に直結する。
「越境」問題はまだ未解決
Identiverse 2026でGeorge Fletcherが指摘した「crossing-the-trustee問題」がある。組織内のチェーンであれば、インフラと信頼基盤を共有しているため既存の標準と適切なポリシーレイヤーで解決可能だ。しかし異なる信頼ドメインをまたぐ場合——B2B連携、そして特に一般消費者向けのシナリオ——は、既存の答えが通用しなくなる。
B2BはコントラクトベースのSLAと透明性レイヤーで一定程度カバーできる。しかしコンシューマー領域では、ユーザーが関与する信頼ドメインの境界を事前に定義することが難しく、標準的な委任モデルをそのまま適用できない。これは現時点でオープンな研究問題であり、「完全に解決した」と主張するベンダーがいれば、立ち止まって詳細を確認するべきだとFletcherは述べた。組織をまたぐ委任チェーンの設計を検討する際は、この未解決領域がどこに該当するかを明確にしておく必要がある。
正しく設計されたチェーンの4要件
EIC Berlin 2026でKuppingerColeのReiner Mertensが提示したアーキテクチャには4つの特性がある。
ワークロードIDの検証を先に行う。 ユーザーのコンテキストを信頼する前に、受け取るサービス自体のIDを暗号学的に検証する。SPIFFE（CNCFのワークロードID標準）がこれを担う。
ポリシー判断をエッジだけでなく各ホップで行う。 上流が検証済みだと信頼するのではなく、各サービスが「このエージェントがこのユーザーの代理として、この操作をしてよいか」を自身のポリシーで評価する。
委任情報をトークン内に明示的に保持する。 RFC 8693の
actクレームとmay_actクレームが委任の発生と代理者を記録する。IETFのTransaction Tokensドラフトはこの上に構築され、ユーザーのIDと認可コンテキストをコールチェーン全体に保持・伝播させる。各ホップを完全なコンテキスト付きでログに残す。 代理者、代理されるユーザー、判断したポリシー、結果——この4点が各転送で記録される。
標準化の現状：何が使えて、何が待ちか
標準化の進捗は一様ではない。
- Token Exchange（RFC 8693）：2020年にRFC化済み。
act/may_actクレームによる委任の記録と範囲制限が可能。今すぐ使える。 - **OpenID AuthZEN Authorization API**：2026年1月に最終仕様確定。「このサブジェクトがこのリソースにこの操作をしてよいか」を標準的なインターフェースで問い合わせられる。各ホップで必要なのはまさにこの判断であり、これも今すぐ使える。
- IETFのWIMSE WGとTransaction Tokens：マルチシステム環境でのワークロードIDと最小権限アクセスを対象とした仕様。進行中の草稿であり、トラッキングするべきだが、今すぐアーキテクチャ全体を依存させるには早い。
- MCPとAgent2Agent：認証やプロビナンスのクロスホップ伝搬はいまだ未定義。2026年のプレプリントが約2000のパブリックMCPサーバーをスキャンしたところ、すべてで認証が欠如していたと報告している（単著プレプリントのため確定値ではないが、現場の実態と合致している）。
評価のためのチェックリスト
Fletcherが提示した委任設計の評価基準は以下の通りだ。
- 委任者・被委任者・マルチホップチェーンをモデル化できるか
- 外部権限（コントラクト、ポリシー）を検証できるか
- 目的（purpose）が委任と一緒に伝播するか
- ユーザーが設定した制約とミッションが示す制約が各ホップで強制されるか
- 委任者が持つ以上の権限を付与できないか（上限の継承）
- 失効が下流に伝播するか
- 共有インフラなしで組織をまたいで機能するか
- 元のプリンシパルまで完全に監査可能か
- プライバシーが設計に組み込まれているか
Fletcherの観察では、多くの提案は最初のいくつかで高スコアを取り、残りで失敗する。どこに賭けるかを決める前に知っておくべき事実だ。
詳細はMulti-hop delegation for AI agents, and how the consent chain gets lostを参照していただきたい。
