> ## Documentation Index > Fetch the complete documentation index at: https://ai.brokenguardrail.com/llms.txt > Use this file to discover all available pages before exploring further. # Confused Deputy Problem > 権限を持たない要求者が、権限を持つ代理人を経由して権限を行使してしまう問題 Confused Deputy Problemは、**権限を持たない要求者がより強い権限を持つ主体を経由して自分の代わりにその権限を行使させてしまう**問題です。AIエージェントに固有ではない古典的な問題ですが、エージェントの普及によって再び現実的な脅威となっています。 ## 定義 [AWS IAMユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)はこの問題を次のように定義しています。 > The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. > > （権限のない主体がより強い権限を持つ主体にその操作を実行させることができてしまうセキュリティ上の問題） 代理人は自分に与えられた権限の範囲内で指示されたとおりに動いているだけです。しかし「いま誰のために動いているのか」というコンテキストを欠くため、意図しない権限が間接的に付与されます。 ## AIエージェントでのConfused Deputy Problem AIエージェントは次の性質を持つために、権限管理が不適切になりやすいです。 * サービスアカウント、APIキー、接続済みのMCPサーバー、RAGなど、エージェントが利用可能な権限は多岐にわたる * 誰がエージェントに指示したかというコンテキストを用いず、同じ権限が使われることが多い これが深刻化した背景には、Context Engineeringの浸透があります。より多くの文脈をエージェントに与えることが推奨された結果、エージェントは多様なデータソースへの権限を持つようになりました。一方でデータには元々の権限体系があります。その境界はAIエージェントの導入によって自動的に引き継がれるわけではなく、その点を意識しない実装によりConfused Deputy Problemが発生しやすくなりました。 ## 具体例 ### 共通のMachine Userで構成された社内MCPサーバー 社内ナレッジベースに接続するMCPサーバーを構築する際、最も手軽な方法はMachine UserやService Accountで統一された権限を付与することです。しかしナレッジベースには、HRやFinanceなど限られた部門のみが閲覧できる機密文書が含まれています。 全体読み取り権限を持つMachine UserでMCPサーバーを構成し、全従業員に公開すると、別部門の従業員が自身のアカウント権限では本来アクセスできない文書へそのサーバー経由で到達できてしまいます。 ### 部門をまたぐRAG RAGはConfused Deputy Problemが特に発生しやすい構成です。インデックスを構築する時点で元の権限情報が失われると、検索の時点ではアクセス境界が存在しなくなります。検索クエリを投げた人物が本来その文書を読めるかどうかをシステムは判断できません。 ### マルチユーザー環境での認証情報の共有 複数ユーザーが利用するエージェント基盤では、サードパーティサービスへのアクセストークンを共有のクレデンシャルストアに保管することがあります。どのユーザーがどの認証情報を使えるかの制御を欠くと、あるユーザーが他ユーザーの認証情報を指定してセッションを開始できてしまいます。 その結果、エージェントは要求者ではなく認証情報の持ち主の権限で外部サービスへアクセスします。エンジニアがHRチームの人事情報を閲覧してはならず、営業チームが開発チームの社内リポジトリにアクセスする必要もありません。こうした境界はNotion・Slack・GitHubなどのアクセス制御によってすでに実現されています。他人の権限を使えてしまう状態は、その既存の制御を完全に迂回することを意味します。 ## 混同されやすい概念 ### 最小権限の原則 **最小権限を守ってもConfused Deputy Problemは解決しません。**最小権限の原則は「代理人に与える権限を必要最小限にする」という指針であり、代理人の権限の**総量**を扱います。Confused Deputy Problemが問うのは総量ではなく**帰属**、すなわち「その権限は、いま要求している人物のものか」です。 ### 権限昇格 Confused Deputy Problemは権限昇格の一種に分類されますが、通常の権限昇格とは異なり、**攻撃者も代理人も権限を昇格させていません**。攻撃者の権限は最初から最後まで変わらず、代理人も元から持っていた権限しか使っていません。この性質のため権限監査やログ上では正常な操作にしか見えず、検知が難しくなります。 ### Prompt Injection 両者は独立した問題であり、同時に成立すると被害が拡大します。Prompt Injectionはエージェントに**意図しない指示を実行させる**攻撃、Confused Deputy Problemはエージェントが**要求者に帰属しない権限を行使する**構造です。 Prompt Injectionがなくても、正当なユーザーが正当な質問をするだけで機密情報が漏れるのがConfused Deputy Problemです。逆に権限が正しく要求者に紐づいていれば、Prompt Injectionが成立してもエージェントは要求者の権限の範囲外へは踏み出せません。**権限の帰属を正すことは、Prompt Injectionの被害範囲を限定する対策にもなります。** ## 対策 基本的に守るべき原則は以下の2点です。 * 利用者と出力の閲覧者全員がすでに権限を持つデータのみを扱う。あるいは、元々の権限を尊重するOAuthのような認可の仕組みでアクセスを許可する * エージェントが扱うデータと権限に基づいて、利用者の範囲と出力先のアクセス権限を管理する ### 要求者の権限へ委譲する 最も本質的な対策です。エージェント自身の固定的な権限で動かすのではなく、ユーザーごとにOAuthフローを経て**そのユーザーの既存の権限のサブセットであることが保証されたアクセストークン**を取得します。それだけを使ってバックエンドへアクセスすれば、既存のアクセス境界がそのまま保たれます。 ### 認証情報を要求者に束縛する ユーザーごとの認証情報を保管するシステムは一般に**Token Vault**と呼ばれます。保管するだけでは不十分で、「どのユーザーがどの認証情報を使えるか」の対応づけを強制することがToken Vaultの役割です。エンドユーザーには自身のクレデンシャルのみを登録・利用できるインターフェースを提供し、他ユーザーの認証情報を指定する経路を塞ぎます。 ### すべての要求で要求者を検証する エージェントやツールサーバーはリクエストごとに要求者のidentityを検証し、そのidentityに紐づく権限で処理する必要があります。 ### 出力先まで含めて権限を設計する 権限の帰属は入力側だけの問題ではありません。エージェントの出力が誰に見えるかも実質的なアクセス権限を決定します。人事情報を要約するエージェントを社内チャットの全ユーザーへ公開すれば、その時点で全ユーザーが人事情報への読み取り権限を得たことになります。 ## 参考文献 * [The confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) * [Confused deputy problem](https://en.wikipedia.org/wiki/Confused_deputy_problem) * [ConfusedPilot: Confused Deputy Risks in RAG-based LLMs](https://arxiv.org/abs/2408.04870) * [Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) * [MCPの認証と認可の現在と未来](https://hi120ki.github.io/ja/blog/posts/20250728/) * [2026年のAI Securityの挑戦](https://hi120ki.github.io/ja/blog/posts/20260103/) * [Claude Managed Agentsはどこまで安全か？](https://hi120ki.github.io/ja/blog/posts/20260413/)