“How to Defend Against the Confused Deputy Problem in the Age of Agentic AI” Dec 3, 2025 by Morey J. Haber より
Confused Deputy問題（信頼されたプログラムが、その権限を誤って悪用してしまう問題）は、コンピュータサイエンスにおける最も古い脆弱性の一つです。しかし、現代においては、AIの普及とマシンIDのスプロール化によって、この問題は劇的に増幅しています。
本ブログでは、攻撃者がどのように信頼されたツールを悪用するのか、なぜエージェント型AI（Agentic AI）がこのリスクを拡大させるのか、そして現代的な特権アクセス管理（PAM）と最小権限のアプローチが、プログラム間で発生する権限昇格をどのように阻止するのかを解説します。
Confused Deputy 問題とは何か
サイバーセキュリティにおける最大の脅威は、必ずしも外部のハッカーや悪意ある内部関係者とは限りません。実際には、私たちが日常的に信頼して利用しているツールこそが、最大のリスクになり得ます。
管理ツール、自動化スクリプト、あるいは特権を持つサービスアカウントが、本来意図されていない悪意あるコマンドを実行するよう操作されるケースがあります。これは典型的な Confused Deputy 問題であり、信頼関係を悪用することで、アプリケーション間の権限昇格を引き起こす脆弱性です。
現在、エージェント型AIと複雑化したマシンID が普及する中で、この問題は、AI導入において厳格な最小権限戦略とゼロトラスト・アーキテクチャを採用すべき最も緊急性の高い課題の一つとなっています。
Confused Deputy 問題の詳細
まずは、この概念と攻撃ベクトルそのものを詳しく見ていきましょう。
「Deputy（代理人）」とは、正当な高レベル権限を持つアプリケーションやプロセスを指します。
この問題は、権限の低いエンティティ（プログラム、アプリケーション、またはユーザー）が、その代理人を欺き、本来の設計パラメータの範囲を超えた操作を実行させたときに発生します。代理人は、正当なリクエストと悪意あるリクエストを区別するための十分なコンテキストや安全策を持たないため、「混乱」した状態に陥ります。その結果、リクエスト元を信頼し、権限昇格につながるコマンドを実行してしまいます。
公平を期して言えば、この問題自体は新しいものではありません。Confused Deputyという用語は、1988 年にノーム・ハーディが発表した論文に由来します。この論文では、コンパイラ（代理人）がエンドユーザーアプリケーションから渡されたファイルパスを無条件に信頼した結果、請求書ファイルを上書きできてしまう事例が示されました。
エンドユーザー側のプログラムにはファイルを直接操作する権限はありませんでしたが、コンパイラには十分な権限があり、最終的にユーザーに代わってファイルを上書きしてしまったのです。つまり、代理人はエンドユーザーよりも高い権限を持ち、不適切なリクエストに基づいて操作を実行するよう誘導されていました。
現在では、これは一般に「権限昇格の脆弱性」と呼ばれますが、昇格が人からアプリケーションへではなく、プログラム間で発生する場合、それはまさに Confused Deputy 問題と定義されます。
エージェントAIの時代を迎えた今、このConfused Deputy問題と権限昇格の脆弱性が蔓延する温床となる新しいテクノロジーが次々と登場しています。実際、Confused Deputyのメカニズムは、多くのクラウドIAMの設定ミス、APIの誤用、OAuthスコープの不適切な設計、さらにはsudoコマンドの悪用における根本原因となっています。
この事実は、最小権限の原則を採用し、組織全体にわたって特権アクセス管理（PAM）を導入することで、マシンID を保護することが不可欠である理由を明確に示しています。では、プログラム、アプリケーション、マシンID間で発生する権限昇格を、どのように防げばよいのでしょうか。
AI 環境における過度に信頼された代理人（Deputy）のリスク
特権アカウントは、アプリケーションやマシンに関連付けられることで、組織内において代理人（deputy）として機能することが少なくありません。これらのアカウントは、機密システム、シークレット、そして重要なデータへのアクセス権を有しています。しかし、最小権限の厳格な適用や、コンテキストを考慮した意思決定が十分に実装されていない場合、意図せず悪意あるコマンドを盲目的に実行する存在になってしまう可能性があります。
例えば、特権サービスアカウントで実行されるCI/CDの自動化スクリプトを考えてみましょう。このスクリプトがユーザーから受け取ったパラメータを検証せず、そのまま昇格されたアクセス権限を持つコマンドに渡してしまうと、権限の低いユーザーであっても、そのスクリプトを悪用して権限昇格を引き起こすことが可能になります。
実際、このような悪用パターンは日常的に発生しています。たとえば、サービスアカウントがConfused Deputy（混乱した代理人）となり、自らの判断ではなく、より低い権限を持つ別のアプリケーションによる巧妙な操作を受けて、有害な処理を実行してしまうケースです。組織がエージェント型 AI ツールを導入するにつれて、私たちは日々のビジネスワークフローで頼りにしている AI エージェントの中に、このような特権アクセスの脆弱性を組み込んでしまっている可能性があります。
その典型例として、Microsoft が最近発表したCopilotの悪用に関する警告が挙げられます。クロスプロンプトインジェクションを利用することで、Copilotが操作され、権限を悪用し、幻覚（hallucination）を引き起こしたり、マルウェアのインストールにつながりかねないコマンドを実行したりする可能性が示されています。このような悪用パターンは、最小権限、ゼロトラスト、あるいはセキュリティ・バイ・デザインの原則を十分に統合しないまま AI 自動化を導入している業界全体で顕在化しています。
エージェント型AIの開発において、組織はAI接続に対する常時アクセスの管理にとどまらず、特権ワークフロー全体のセキュリティ確保へと重点を移す必要があります。すなわち、確立した権限がAIを介して他のアプリケーションやデータソースを操作するために悪用・改ざんされることがないよう、徹底して防御しなければなりません。
最も一般的な Confused Deputy 攻撃シナリオ
Confused Deputy攻撃の多くは、特権アクセス管理（PAM）のユースケースと密接に関連しており、自動化やエージェントAIによって、一般的なIT環境でも発生し得ます。
1. sudo スクリプトによる権限昇格
管理者がユーザーに対して、sudo経由で特定のスクリプトの実行権限を付与するケースを考えます。このスクリプトが他のコマンドを呼び出したり、入力パラメータをサニタイズせずに解釈したりする場合、攻撃者は悪意あるパラメータを渡すことで、スクリプトを昇格した権限で実行させることができます。このスクリプトは Confused Deputy となり、OS の直接的な脆弱性を突くことなく攻撃が成立します。自動化にAIが加わるとすれば、この種の攻撃は飛躍的に拡大する可能性があります。
この問題への一般的な対策は、エンドポイント権限管理（EPM）を重視したPAMソリューションを導入することです。スクリプトがバックグラウンドで実行され、ユーザーの明示的な同意がない場合であっても、エージェントAIの動作に必要な権限を含めて制御・保護することが可能になります。
2. 動作分析を伴わないパスワード保管
PAM ソリューションは、資格情報を保管し、アクセスをブローカーする機能を提供します。しかし、保管された資格情報を使って、監査も検証もされていない任意のコマンド実行を許可してしまう場合（ジャンプホストや自動化エンジン経由など）、セッション全体が侵害され、ラテラルムーブメントやデータ窃取につながる可能性があります。
それ故に、特にマシンIDがエージェントAIを用いて役割を担う場合、Confused Deputyを防ぐためには、堅牢なセッション監視とリアルタイムのコマンド分析が不可欠です。
3. 共有サービスアカウント
CI/CDパイプラインは、シークレット、レジストリ、あるいは本番 APIへの高レベルかつ永続的なアクセス権を持つ共有サービスアカウントに依存しています。開発者がこれらの認証情報に間接的にアクセスできる場合、パイプラインプロセス（Deputy）を操作し、悪意あるコードを展開したり、機密情報を漏洩させたりする可能性があります。この攻撃ベクトルは、近年の多くのサプライチェーン攻撃の中心にあり、エンタープライズ向けシークレット管理ツールによって、これらのマシン ID を保護することが極めて重要です。
4. Cloud IAM トークンの不正使用
クラウドマイクロサービスは、セキュリティトークンサービス（STS）などを利用して役割を引き受けることが一般的です。設定ミスにより、あるサービスが、より高い権限を持つ別のサービスを欺き、代わりにAPIを呼び出させてしまうことがあります。この場合、後者のサービスがConfused Deputyとなります。この問題は、AWS Lambda や Azure Functions の統合設定ミスで頻繁に見られ、SPIFFE や SPIRE といった標準仕様による、強力なマシン ID と認証の仕組みが求められます。
最新のPAMがConfused Deputy問題をどのように解決するか
Confused Deputy 問題を効果的に軽減するためには、PAM は単なるシークレット管理やセッションブローカーの役割を超えて進化する必要があります。具体的には、意図を能動的に検証し、コンテキストを適用し、人・マシン・AIを含むあらゆるIDに対して、きめ細かなジャストインタイム（JIT）権限付与を可能にしなければなりません。統合された最新の PAM ソリューションは、次のような方法でこれらの課題に対応します。
・コマンドのフィルタリングと検証：PAMソリューションは、厳格なコマンド許可リスト（allowlisting）を適用し、パラメータインジェクションを制限するとともに、ユーザー入力を検証して、間接的な手段による権限昇格を防ぐ必要があります。
・コンテキストに対応したアクセス制御：アクセスポリシーには、開始者のID、時刻、ソースデバイス、意図された目的といった詳細なコンテキストを組み込む必要があります。こうした行動およびリスクに基づくコンテキストが、セッションの途中であっても、許可される操作を継続的に規定しなければなりません。
・職務分掌の適用：IDやアカウントは、企業全体で一律に使用すべきではありません。自動化、デバッグ、デプロイメントなど、特定の機能ごとにサービスアカウントとアプリケーションアカウントを分離することで、Deputyが侵害された場合の影響範囲を抑制できます。
・役割分離の実装：最小権限の原則では、どのアカウントも必要以上の権限（entitlements）を持つべきではありません。すべての権限を集約した1つのアカウントを持つよりも、最小権限をそれぞれ尊重した複数のアカウントを用意する方が効果的です。
・リアルタイムの監査と監視：特権アカウントが不正に使用された場合には、フォレンジックと可視化が必要になります。包括的なセッション記録、コマンド監査証跡、キーストロークログは、フォレンジック調査とリアルタイムの脅威検知に不可欠です。意図的な侵害であれ、Confused Deputyによる偶発的な誤用であれ、不正を捕捉するためには、強固なアイデンティティセキュリティ体制を維持することが重要です。
・動的な資格情報インジェクション：シークレットをローテーションし、ジャストインタイム（JIT）認証やエフェメラル認証を通じて実行時にのみ資格情報をインジェクションすることで、常時アクセスを回避します。ユーザーやプロセスが資格情報を「知っていない」状態になるため、すべてのアクセス要求が検証・記録され、Deputy を悪用することがより困難になります。
次のステップ：Confused DeputyとAI増幅型脅威へのレジリエンス向上
エージェントAIの普及により、Confused Deputy問題はもはや技術的な脚注ではなく、企業全体に関わる戦略的課題となっています。この問題は「コンテキストを伴わない権限」が本質的な脆弱性であることを改めて浮き彫りにします。
エージェントAIは、高度に信頼されながらも潜在的に混乱した代理人となり得る存在を、数百万単位で生み出し、このリスクをさらに増幅させます。PAMアプローチを近代化することで、人、プロセス、マシン、そして特にアプリケーションやプログラムといったすべてのレイヤーにおいて、Confused Deputyから積極的に防御できるようになります。
最小権限の実装とは、単に常時アクセスを削減することではありません。それは、あらゆるレイヤーで「意図の検証」を強制するセキュリティファブリックを構築することです。
AIがあらゆる場所に浸透し、あらゆる会話の一部となる時代において、信頼されているツールこそが、最も危険な敵になり得ます。十分な混乱があれば、優れたプログラムであっても、不正な動作を引き起こす可能性があるのです。
FAQs
Q. Confused Deputy問題とは何ですか？
A. Confused Deputy問題（混乱した代理人問題）とは、より高い権限を持つ信頼されたプログラムやサービスが、低い権限の主体の意図に誘導され、代わりに操作を実行してしまうことで発生します。OS自体の脆弱性を直接突くエクスプロイトを必要とせずに、結果として意図しない権限昇格が起き得る点が特徴です。
Q. なぜAI環境ではConfused Deputy問題がより危険なのですか？
A. エージェント型AI（Agentic AI）システムや自動化ツールは、昇格された権限を用いて日常的に操作を実行します。AIエージェントが「意図」や「コンテキスト」を検証できない場合、操作されて有害なコマンドを実行させられる可能性があり、極めて強力なConfused Deputy（混乱した代理人）となり得ます。
Q. 最小権限は、どのようにConfused Deputy攻撃の防止に役立ちますか？
A. 最小権限は、各ID（人間またはマシン）が業務に必要な最小限の権限だけを持つようにすることで、被害の波及範囲（blast radius）を抑えます。仮に代理人（deputy）が操作されたとしても、悪用可能な権限自体が小さくなり、影響を限定できます。
Q. 特権サービスアカウントはConfused Deputyになり得ますか？
A. はい。サービスアカウントは広範かつ継続的なアクセス権を保持していることが多く、パイプライン、スクリプト、自動化エンジンなどが入力を検証せず、あるいは実行可能な操作を制限していない場合、容易にConfused Deputyとして悪用され得ます。
Q. クラウドにおけるConfused Deputy脆弱性の例にはどのようなものがありますか？
A. 代表例として、AWS STSの設定ミス、OAuthスコープの誤用、Azure Functionsが他サービスの代わりにAPIを呼び出してしまうケース、昇格権限で実行される処理に対しマイクロサービスが信頼できないパラメータを受け入れてしまうケースなどが挙げられます。
Q. 最新のPAMは、どのようにConfused Deputy攻撃を阻止しますか？
A. 最新のPAMは、コマンドフィルタリング、リアルタイムの振る舞い分析、資格情報インジェクション、セッション監視、ジャストインタイム（JIT）権限付与などを組み合わせ、特権操作が「検証された意図」に基づく場合にのみ実行されるようにします。
Q. AIエージェントはマシンID（Machine Identity）と見なされますか？
A. はい。AIエージェントは認証を行い、コマンドを実行し、APIへアクセスし、システムと相互作用します。そのためマシンIDとして機能し、同様のアイデンティティリスクにさらされます。しかも、その規模はより大きくなりやすい点が特徴です。
Morey J. Haber は、Chief Security Advisor（最高セキュリティアドバイザー）として、BeyondTrust社におけるアイデンティティセキュリティおよび技術分野のリードエバンジェリストを務めています。IT 業界で 25 年以上の経験を有し、これまでに以下の 5 冊の著書を執筆しています。
- Attack Vectors: The History of Cybersecurity
- Privileged Attack Vectors
- Asset Attack Vectors
- Identity Attack Vectors
- Cloud Attack Vectors
BeyondTrustには約13年間在籍しており、その間、Chief Security Officer（CSO）、Chief Technology Officer（CTO）、Vice President of Product Management（製品管理担当副社長）など、複数の要職を歴任してきました。2020 年には、企業コミュニティにおけるアイデンティティセキュリティのベストプラクティス確立を支援する目的で、Identity Defined Security Alliance（IDSA）のエグゼクティブ・アドバイザリーボードのメンバーに選出されています。
Moreyは2012年、eEye Digital Securityの買収に伴いBeyondTrustに参画しました。eEyeでは 2004年以降、プロダクトオーナーおよびソリューションエンジニアとして従事していました。それ以前は、Computer Associates, Inc. にてベータ開発マネージャーを務めています。キャリアの初期には、政府系請負企業において、フライトシミュレーターおよび訓練用シミュレーターを構築するための信頼性・保全性エンジニアとして業務に携わりました。
学歴としては、ニューヨーク州立大学ストーニーブルック校（State University of New York at Stony Brook）にて、電気工学の理学士号（Bachelor of Science）を取得しています。