複数システムをまたいでタスクを代行するAIエージェントに、ユーザーの権限をそのまま渡していないでしょうか。低権限のエージェントが高権限のエージェントやサービスを騙して処理を実行させる「Confused Deputy」は、エージェントガバナンスにおける権限設計の中でも見落とされやすいリスクです。
Confused Deputyとは何か
Confused Deputyとは、高権限の代理が依頼元の意図を検証せず不正操作を実行してしまう脆弱性です。
Confused Deputy問題自体は1980年代から知られる古典的な脆弱性ですが、AIエージェントの文脈では新しい深刻さを持ちます。OWASPのGen AI Security Projectが公開する「Top 10 for Agentic Applications 2026」は、この問題をASI03「Identity & Privilege Abuse」に分類しています。エージェントは自分固有のIDを持たず、呼び出し元やシステムの認証情報を継承して動くことが多いため、権限の境界があいまいになりやすいのが根本原因です。
なぜAIエージェントでConfused Deputyが起きやすいのか
エージェントは呼び出し元の認証情報を継承しやすく、タスク完了後も権限が失効しないため被害範囲が広がります。
典型的なパターンは3つあります。第一に、サブエージェントへのタスク委譲時にスコープを絞らず、親エージェントの全権限をそのまま渡してしまうケース。第二に、一度発行したトークンがタスク完了後も長期間有効なままキャッシュされるケース。第三に、複数のツールやMCPサーバーを横断する際に、どのエージェントが「本人の代理」としてどこまでの権限を持つかを検証する仕組みがないケースです。いずれも、権限の出どころ（誰が誰に何を委任したか)を追跡できない設計に起因します。
RFC 8693のトークン交換はどう防御するか
RFC 8693のトークン交換は、委任と成りすましを区別し、委任チェーンをトークンに記録して検証可能にします。
OAuth 2.0のToken Exchange仕様であるRFC 8693は、この問題への標準的な解を提供します。ポイントは「委任（delegation）」と「成りすまし（impersonation）」を明確に分離している点です。actor_tokenパラメータを付けてトークン交換を要求すると、発行されるトークンには元の主体（subject）と実行者（actor）の両方の情報を含むactクレームが付与されます。これにより、A社のエージェントがB社ユーザーの代理として動く場合も、「AがBを代理している」という関係自体が検証可能な形で残ります。さらにmay_actクレームを使えば、トークン発行時点で「誰が代理になり得るか」を事前に制約でき、任意のエージェントが勝手に委任を要求することも防げます。
委譲チェーンをどう設計すべきか
委譲のたびにスコープを狭め、
actクレームで経路を記録し、タスク単位で失効させる設計が基本です。
実装上は次の3原則を押さえます。1つ目は、委譲のたびに権限を広げるのではなく狭める「権限逓減」の徹底です。親エージェントの全スコープを渡すのではなく、サブタスクに必要な最小スコープだけを新しいトークンに乗せます。2つ目は、actクレームによる委譲チェーンの記録を監査ログと連携させ、どのエージェントが誰の代理として何を実行したかを後から追跡できるようにすることです。3つ目は、トークンの有効期限をタスクの生存期間に合わせて短縁化し、完了後は速やかに失効させることです。マルチエージェント構成やA2Aプロトコル経由での連携が広がるほど、この委譲チェーンの検証はエージェント基盤全体の統制の要になります。大規模な組織でこの設計を横断的に統制する場合は、Kuuのエージェント実装支援（RDE）のようにIAM設計から監査基盤まで一貫して伴走できる体制が有効です。
参考
まとめ
AIエージェントへの権限委任は、スコープを絞らず丸ごと渡した瞬間にConfused Deputyのリスクを抱え込みます。RFC 8693のトークン交換による委任と成りすましの区別、act/may_actクレームによる委譲チェーンの可視化、タスク単位での権限逓減とトークン失効——この3点を基盤設計に組み込むことが、エンタープライズでマルチエージェント構成を安全に拡張する前提条件です。自社のエージェント基盤における委譲設計の見直しは、Kuuまでお気軽にご相談ください。