はじめに
AI技術の発展に伴い、人間に変わって特定のタスクを自律的に行うAIエージェントを用いたシステム(AIエージェントシステム)の利活用が期待されています。大規模言語モデル(Large Language Model, LLM)を中核に、Chain-of-Thought、メモリ(短期・長期記憶)、LLM単体では実現できない機能を提供するツールといった要素技術を組み合わせたAIエージェントシステムは、その自律性と能力の高さから、様々なタスクの遂行が可能です。一方で、AIエージェントシステムは、従来型のアプリケーションとは異なる、新たな攻撃対象領域が形成されるため、新たなセキュリティリスクをもたらす可能性があります。
本記事では、OWASP Foundationが提唱する「OWASP Top 10 for Agentic Applications 2026[1]」に記載されている脅威を最新の研究動向を交えながら、体系的に分析・解説します。図1にOWASPにより特定された10個の脅威の概要を示しています。特に、本記事ではAIエージェント間の連携に関連する脅威である、「ASI03: Identity & Privilege Abuse」、「ASI07: Insecure Inter-Agent Communication」、および「ASI10: Rogue Agents」の3つの脅威について解説します。
なお、前回の記事「人間とAIエージェントの意思決定に関する脅威」では、人間とAIエージェントのインタラクション/意思決定に関連する脅威である「ASI01: Agent Goal Hijack」および「ASI09: Human-Agent Trust Exploitation」について解説しています。まだご覧になっていない方は、ぜひご一読ください。

図1 OWASPにより特定されたAIエージェントに対する10個の脅威の概要と着目する脅威(出典:OWASP Top 10 For Agentic Applications 20261, CC BY-SA 4.0、一部改変。この改変した図も CC BY-SA 4.0 により提供。)
ASI03:ID・権限の不正利用(Identity & Privilege Abuse)
概要
ID・権限の不正利用は、AIエージェントに紐づくアイデンティティ(人格・役割)や認証・認可の仕組みの不備を突く脅威です。これは既存のユーザー中心のID管理と、AIエージェントが自律的に行動・委任する設計とのギャップが原因で、どのAIエージェントが「誰として」、「どの範囲で」、「何を」しているのかが曖昧になり、本来意図していない動作や操作を引き起こします。これは、正規の権限を持つ主体(ユーザーや上位AIエージェント)からの「過剰な委任」、AIエージェント内部にキャッシュされた認証情報や会話履歴の再利用、他AIエージェントからのリクエストを無条件に信用する設計などを悪用されることで起こります。
攻撃シナリオ
文書で示されている代表的なシナリオは次の通りです。
- 委任権限の悪用
財務AIエージェントがデータベースの問い合わせを行うAIエージェントにタスクを委任する際、便宜的に自身の持つ全ての権限を引き渡してしまう場合を考えます。この時、クエリに不正な操作に誘導する内容が含まれていると、もともと想定していない人事・法務データまで一括で引き出すことができてしまいます。
- メモリを介した権限昇格
例えば、IT管理AIエージェントがパッチ作業中にSSH鍵をメモリに保持しているとします。その後、権限の低いユーザーがプロンプトを工夫してその会話セッション内で使われた資格情報をAIエージェントに再利用させることで、新しい管理者アカウントを不正作成できます。 - AIエージェント間の信頼の悪用
攻撃者が「IT部門からの連絡」を装ったメールで、メール仕分けAIエージェントに「財務AIエージェントへ送金指示を伝える」よう依頼します。送金の権限を持った財務AIエージェントは内部AIエージェントからの指示を無条件に信頼し、検証なしで不正送金を実行するリスクがあります。 - AIエージェントのなりすましによる権限悪用
研究論文[2]では、マルチエージェントやツール連鎖の中で、悪性エージェントがプロンプトフローを悪用して「本来持たない高権限の操作」を他エージェントに実行させる攻撃(権限エスカレーション)が定式化されています。攻撃者が偽のツール管理用AIエージェントを登録し、AIエージェントシステムで利用する内部ツールの管理役を装います。ほかのAIエージェントがこの悪意あるAIエージェントを正規AIエージェントと信じて高権限タスクを委任し、システムレベルの操作を許してしまうというリスクがあります。
想定リスク
- AIエージェントの最小権限の不成立による大規模な損害
人間に対する権限のモデルをそのままAIエージェントに継承すると、「便利さ」のために広範な権限を渡しがちになり、単一AIエージェントの侵害が、企業内の多数システムやデータ領域に波及しうる可能性があります。 - セッション/メモリを介した隠れた権限
一度使われた認証情報や、権限のあるセッション状態がメモリに残り続けると、後続の低権限ユーザーの対話において再利用され、論理上の権限境界が崩壊する可能性があります。 - 複数AIエージェントの連携における信頼過多による損害
必ずしも「内部AIエージェントからのリクエストは安全」という前提は成り立たちません。一つの低権限AIエージェントの侵害から、高権限AIエージェントを騙すことで、権限チェーンを遡って広い権限を行使でき、予想外の損害につながります。研究論文[3]では、あるAIエージェントが連携しているAIエージェントを信頼する場合、間接的にそのAIエージェントが利用するツールも信頼することになるため、対策が必要であると言及されています。 - 監査・追跡の困難性による被害の拡大
多くのAIエージェントが連携するシステムでは、「誰の意図で」、「どのトークン/セッションを使って」、「どのAIエージェントが行動したか」が分離されていないと、事後のインシデント調査でも原因や責任範囲が曖昧になり、被害が拡大することにつながります。ある研究論文[4]では、AIエージェントが仕様に従わない場合や勝手な操作を実行する危険性について言及されており、監査の重要性が強調されています。
これらのリスクは、システムのセキュリティ境界を内部から崩壊させる危険性をはらみます。最小権限の原則の遵守がAIエージェントの文脈でも極めて重要であり、これが遵守されていない場合、単一のAIエージェントの侵害がシステム全体の侵害へと容易に拡大し得ます。攻撃者は、権限の悪用を通じてシステム内を水平移動し、より高価値な情報資産やシステム制御権の奪取を試みるでしょう。結果として、大規模な情報漏洩や、システム全体の永続的な侵害につながるリスクがあります。
対策
主な対策は以下の通りです。
- タスク単位・時間限定の権限付与
- 各AIエージェントに「固有のID」を持たせ、タスクごとにスコープを絞った短命トークン(mTLS証明書やスコープ付きトークン)を発行。
- タスク終了・タイムアウト・異常検知で権限を自動失効させ、放置された権限や無制限継承を防止。
- アイデンティティとコンテキストの分離・隔離
- セッションごとにサンドボックスを用意し、メモリ/コンテキスト/権限を分離。
- タスク完了時にメモリをクリアし、他ユーザーや他タスクへの“権限・情報の持ち越し”の防止。
- ステップごとの許可
- ワークフロー開始時だけでなく、各高リスクアクションの直前でポリシーエンジンにより再検証。
- 他AIエージェント経由のリクエストであっても、「元のユーザー意図」と「付与されたスコープ」が適合するかを都度確認。
- 権限エスカレーションには人間の承認を必須に
- 高権限操作(送金、アカウント作成、権限追加など)には、人間承認を要求。
- これにより、メモリ経由の権限昇格やクロスAIエージェントの権限悪用を最終段階で防止。
- トークンと意図の管理
- OAuth等のトークンに対し、「誰のために・どの目的で・どのセッションで使用されるか」といった“サイン済みの意図情報”を付与。
- 現在のリクエストと意図情報が食い違う場合は拒否。
- 委任チェーンと権限の監視
- どのAIエージェントが、どのタイミングで、どのルートから新しい権限を得たかを継続的にモニタリング。
- 低権限AIエージェントが、ワークフロー中に突然高権限スコープを得た場合にアラートを発報。
対策の根幹は、厳格なID管理とアクセス制御にあります。まず、AIエージェントを操作するユーザーに対しては、多要素認証(MFA)を必須とし、その役割に応じたRBAC(Role-Based Access Control)を徹底します。AIエージェント自身に対しても、短期的な有効期間を持つ資格情報(例: OAuth2.0アクセストークン)を発行し、その権限スコープをタスク遂行に必要な最小限に限定することが不可欠です。さらに、AIエージェントによる全てのツール利用やAPIアクセスは、詳細なログとして記録し、異常な振る舞いをリアルタイムで検知・警告する監視システムを構築することが求められます。
ASI07:AIエージェント間通信の安全性の不備(Insecure Inter-Agent Communication)
概要
ASI07「Insecure Inter-Agent Communication」は、複数のAIエージェントがAPI・メッセージバス・共有メモリ等を介して連携する際、その通信経路が認証・暗号化・整合性チェック・意味的検証などの観点で不十分な場合に生じる脅威です。主要なポイントは以下の通りです。
- AIエージェント間の通信が盗聴・改ざん・なりすましに脆弱。
- メッセージの整合性や意味が検証されず、攻撃者が途中で指示を改変。
- 再送・リプレイ・プロトコルダウングレードなどにより、古い・偽の指示が受理される危険性。
これらにより、リアルタイムのAIエージェント間メッセージが汚染され、誤った決定や権限行使がシステム全体に波及します。
攻撃シナリオ
文書内の代表的な例は次の通りです。
- 暗号化されていない通信における改ざん
- HTTPなど暗号化・認証なしのチャネル上で、攻撃者がMITM(中間者攻撃)を行い、メッセージ内に隠し指示を注入。見かけは通常のメッセージでも、実際にはAIエージェントの目標やパラメータが改ざんされ、偏った・悪意ある結果を生成。
- メッセージ改ざんによる信頼度の不正操作
- AIエージェント同士が互いの評判やスコアを交換して信頼度を決めるトレーディングネットワークにおいて、攻撃者が「評価メッセージ」を改ざんし、特定のAIエージェントの信頼度を不当に高く(または低く)見せ、意思決定を歪める攻撃。
- 再送によるリソースの負荷の誘発
- 過去の「緊急指示メッセージ」を再送し、既に状況が変わっているにもかかわらず、AIエージェントに古い対応(リソース割り当て・優先付け)を再度行わせた結果として、誤ったリソース配分やサービス品質の劣化が発生。
- プロトコルのダウングレードや能力情報の偽造
- 攻撃者がプロトコルを古い・安全でないモードへダウングレードさせたり、AIエージェントの「ディスクリプタ(能力情報)」を偽造し、本来権限のないAIエージェントの指示を「有効なコマンド」と誤って受け入れる攻撃。
- なりすましによる中間者攻撃
- MCPやAgent2Agentディレクトリで、偽のAIエージェント・偽のエンドポイントを登録し、「高信頼・高能力」を装う攻撃や、他AIエージェントからのセンシティブなタスクやデータが、攻撃者支配の偽AIエージェントへルーティングされ、データ漏洩や改ざんを実施。研究論文[5]では、LLM 搭載ロボットへの中間者攻撃について言及されており、今後より現実的な攻撃になる可能性が言及。
想定リスク
- 全体アーキテクチャの“境界崩壊”
ゼロトラストに反し、「内部メッセージは安全」という前提で構築していると、1箇所のチャネル侵害から全体に不正メッセージが拡散。 - リアルタイム性ゆえの被害拡大
AIエージェント間通信はリアルタイムで継続的に行われるため、短時間で大量の誤指示・誤処理が伝播し、監視・介入が困難。 - 他のリスクとの連鎖
通信レイヤが攻撃された場合、結果として他の脅威(下記)を同時に引き起こす可能性。- ASI03(権限の乱用:偽の高権限を悪用したAIエージェントの活動)
- ASI06(メモリ・コンテキスト汚染:偽メッセージを保存)
- ASI08(カスケード障害:誤メッセージがネットワーク全体に波及)
対策
文書に基づく主な対策は以下です。
- チャネルの暗号化と相互認証
- すべてのAIエージェント間通信をTLS/mTLSで暗号化し、各AIエージェントに固有の証明書を割り当て。
- PKIに基づき証明書ピンニング・前方秘匿性を確保し、中間者攻撃やなりすましを防止。
- メッセージ完全性と“意味”の保護
- メッセージペイロードと関連コンテキストをハッシュ+電子署名で保護し、改ざん検知を実施。
- 自然言語を含む場合は、「隠し指示」や目標・パラメータ改ざんを検出するためのフィルタを適用。
- アンチリプレイ・コンテキスト境界
- 各メッセージにnonce(一度きりしか使わない値)、セッションID、タイムスタンプを付与し、タスクウィンドウ外の再利用を拒否。
- 短期的なメッセージフィンガープリントを保持し、異なる文脈からのリプレイを検知。
- プロトコルと能力の強制ポリシー
- 使用を許可するプロトコルバージョン(MCP、A2A等)を明示的に制限し、ダウングレード要求や未承認スキーマを拒否。
- ゲートウェイで、両AIエージェントが広告する機能・バージョンの整合性をチェック。
- ディスカバリ/ルーティングの防御
- ディレクトリサービスやレジストリに対しても認証・アクセス制御を実施し、誰でも自由にAIエージェントを登録できないように制限。
- AIエージェントカードやディスクリプタに対し、デジタル署名と由来の検証。
- 型付きコントラクトとスキーマ検証
- メッセージ形式を型付き・バージョン付きのスキーマとして定義し、バリデーションに失敗したメッセージを拒否。
- 構造上は正しくても「意味的におかしい」内容を検知するため、追加的なセマンティック検査やポリシーチェックを併用。
- メタデータ露出の最小化
- 必要に応じて固定サイズメッセージやパディングを利用し、トラフィックプロファイリングを阻止。
- 一定のランダム性を持った通信スケジュールにより、決定的なパターンを秘匿。
ASI10:悪性AIエージェント(Rogue Agents)
概要
悪性AIエージェントは、本来の設計意図や許可されたスコープから逸脱し、悪意ある、有害な振る舞いを行うAIエージェントによる脅威を示します。ここで重要なのは、単発のインジェクションやバグではなく、「継続的な行動パターンとしておかしい」状態に焦点を当てている点です。つまり、外部からのプロンプトインジェクションやサプライチェーン攻撃などが引き金になるわけではなく、AIエージェントが自律的に逸脱行動を続けることが特徴です。個々の操作は一見正当なAPI呼び出しやツール利用に見えるため、従来のシグネチャ型・ルール型防御では検知が難しく、内部者の脅威の機械版とも言える性質を持ち、影響のスピードとスケールの両面で被害が拡大しやすい脅威です。
攻撃シナリオ
文書で挙げられている代表例は次の通りです。
- 間接プロンプトインジェクション後の自律的なデータ流出
Web経由の間接プロンプトインジェクションによる指示・挙動の学習行動として残存し、攻撃元コンテンツ削除後も、機密ファイルの自律スキャンと外部送信を継続。
- 偽レビューAIエージェントの挿入
攻撃者によるレビュー・承認AIエージェントの偽装挿入と誤承認結果の供給や、内部承認結果を信用した決済AIエージェントによる不正送金・不正トランザクションの実行。
- プロビジョニングAPI経由の自己増殖
- プロビジョニングAPIにアクセス可能な自動化AIエージェント侵害による多数コピーの自己増殖やリソース枯渇と広域な横展開、および一部停止後も継続する残存AIエージェントが活動。
想定リスク
- ステルス性による悪影響の拡大
APIコールやツール利用自体は正規の手順であり、権限チェックにも形式的には合致しているため、悪性AIエージェントであることの検知が困難です。研究論文[6]では、悪性エージェントが混入したマルチエージェントシステムの頑健性について議論されています。研究結果によると、階層型システムが最も高い堅牢性を示すされていますが、コード生成、数学の問題の解答生成、翻訳のタスクにおいて最低でも性能が約12%低下することが実証されています。また、研究論文[7]では、なりすましによる特定操作への誘導やタスクの実施に関して言及されています。
- 持続性・自己増殖性
一度発生した振る舞いの逸脱が、メモリ・構成・自動デプロイ機構などを通じて持続・拡散する可能性があり、単純な再起動や一時停止では解決が困難です。また、他のAIエージェントへ悪影響を及ぼす可能性があります。研究論文[8]では、エージェント間のプロンプトを媒介した感染により、他のAIエージェントを悪性に変えることが可能と言及されています。 - コンプライアンス・責任追跡の困難さ
行動がAIエージェントの自律的決定に見える場合、「どの設計判断」「どの更新」「どの人間の承認」が根本原因か特定するのが難しく、法的・規制的な説明責任を果たすことが困難となり、明確にAIエージェントとマルウェアの区別ができなくなる可能性があります。
対策
文書にある主な対策は以下です。
- 完全な監査ログとガバナンス
- すべてのAIエージェントの行動(ツールコール、インターフェース呼び出し、AIエージェント間通信)を、改ざん検知機能つきのログとして記録。
- ログには、呼び出し元AIエージェントID・用いた認証情報・入力/出力コンテキスト・時刻などを含め、後から行動履歴をトレース。
- トラストゾーンと境界設定
- AIエージェントを信頼ゾーン別に区分し、ゾーン間通信・ツールアクセスを厳格に制限。
- サンドボックス化された実行環境(コンテナ等)を用い、各AIエージェントに与えるAPIスコープ・ネットワークアクセス・ファイルシステムアクセスを最小限に設定。
- 監視・異常検知
- 他AIエージェントの出力と行動パターンを監視する「ウォッチドッグ」AIエージェントを配置し、異常なツール利用頻度、予期しないデータ外送パターン、ポリシー外のツールチェーンなどを検知したらアラート・自動隔離。
- アイデンティティ証明と行動マニフェスト
- 各AIエージェントに対し、暗号的に保護された「行動・能力マニフェスト(どのツール・どの目的・どの種類の操作が許可されるか)」を紐づけ。
- オーケストレーションレイヤは、AIエージェントが行おうとする各アクションを、このマニフェストと照合し、逸脱があればブロック。
- 鍵管理と署名の管理
- 署名鍵・認証鍵はHSM/KMS等で集中管理し、AIエージェント自身が秘密鍵を直接扱えないように制限。
- 署名操作はオーケストレーターが仲介し、侵害されたAIエージェントによる署名の偽造を防止。
おわりに
本稿で分析したASI03, ASI07, ASI10の3つの脅威は、「AIエージェント間の連携」という境界領域における脆弱性を基盤としている点で共通しています。AIエージェントのセキュリティを確保するためには、従来の技術的なセキュリティコントロールを実装するだけでは不十分であり、より安全なプロトコル等の設計が必要であることを示唆しています。特に、AIエージェントの連携プロセスをブラックボックス化させず、その振る舞いに対する透明性と説明可能性を確保することが、これらの脅威を防ぐために不可欠です。今後も研究動向に注目しながらこれらの脅威や対策について情報収集することが、安心安全なAIエージェント活用の実現のために重要となるでしょう。
参考文献
[1] OWASP Gen AI Security Project – Agentic Security Initiative, “OWASP Top 10 For Agentic Applications 2026.” 2025年12月.
[2] Kim, Juhee, Woohyuk Choi, and Byoungyoung Lee. “Prompt flow integrity to prevent privilege escalation in llm agents.” arXiv preprint arXiv:2503.15547 (2025).
[3] Li, Qiaomu, and Ying Xie. “From glue-code to protocols: A critical analysis of a2a and mcp integration for scalable agent systems.” arXiv preprint arXiv:2505.03864 (2025).
[4] Pan, Melissa Z., et al. “Why do multiagent systems fail?.” ICLR 2025 Workshop on Building Trust in Language Models and Applications. 2025.
[5] Shaikh, Asif, Aygun Varol, and Johanna Virkki. “From Prompts to Motors: Man-in-the-Middle Attacks on LLM-Enabled Vacuum Robots.” IEEE Access (2025).
[6] Huang, Jen-tse, et al. “On the resilience of llm-based multi-agent collaboration with faulty agents.” arXiv preprint arXiv:2408.00989 (2024).
[7] Zheng, Can, et al. “Demonstrations of integrity attacks in multi-agent systems.” arXiv preprint arXiv:2506.04572 (2025).
[8] Lee, Donghyun, and Mo Tiwari. “Prompt infection: Llm-to-llm prompt injection within multi-agent systems.” arXiv preprint arXiv:2410.07283 (2024).
