AIエージェント脅威モデル：Prompt Injection・データ漏洩・権限暴走の落とし穴と対策

AIエージェントの導入が加速する一方で、「エージェントが社内データベースを勝手に操作しないか」「顧客情報が社外に流出しないか」という懸念は、導入審査における最大のハードルとなっています。本記事では、2025年末にリリースされたOWASP Agentic Top 10（2026版）を中心に、AIエージェント特有の脅威モデルを整理し、企業が導入審査を突破するために必要な「脅威 → 対策 → 残余リスク」の論理構造を提示します。

エージェント特有の脅威ランドスケープ — なぜ従来のセキュリティでは足りないのか

受動的LLMから自律型エージェントへのパラダイムシフト

生成AIの進化は、ユーザーの入力に受動的にテキストを返すチャットボットの段階を脱し、自ら目標を設定し、計画を立て、外部ツールを実行する「自律型AIエージェント（Agentic AI）」へと急速に移行しています。ユーザー認証の代行、資金移動のトリガー、コンプライアンスワークフローの実行など、エージェントが最小限の人間監視で自律的に機能する場面が拡大しています。

しかし、従来のサイバーセキュリティモデルは、ソフトウェアが「受動的」かつ「予測可能」であることを前提としています。エージェントは継続的かつ自律的に推論・記憶・行動を行い、委任された権限を行使するため、もはや単なるツールではなく、内部システムへアクセス可能な「インサイダー（内部関係者）」として振る舞います。悪意のある入力や設計上の欠陥によって、エージェントは容易に「混乱した代理人（Confused Deputy）」へと転落し、意図せぬデータ漏洩や権限の暴走を引き起こす危険性を孕んでいます。

Verizonの2025年データ漏洩レポートが示すように、システム侵入の多くは技術的な欠陥の悪用ではなく、正当な資格情報（アイデンティティ）の悪用に起因しています。エージェントに与えられた権限が奪取された場合の影響は計り知れません。

OWASP LLM Top 10（2025）からAgentic Top 10（2026）への進化

2025年版の「OWASP Top 10 for Large Language Model Applications（バージョン1.1）」では、LLM単体やシンプルなRAGシステムを対象とした脆弱性が定義されていました。代表的なものとして、プロンプトインジェクション（LLM01）、機密情報の意図しない開示（LLM06）、過剰なエージェンシー（LLM08）が挙げられます。

しかし、エージェントが複数のツールを連結し、長期記憶を持ち、他のエージェントと対話するようになると、単一モデルの脆弱性だけではリスクを説明しきれなくなりました。OWASP GenAI Security Projectは、NIST、Alan Turing Institute、Microsoft AI Red Teamなどの100名以上の専門家の査読を経て、2025年12月に「OWASP Top 10 for Agentic Applications（2026版）」をリリースしました。このフレームワークは、静的なアプリケーションの保護から、適応型で自己主導的なシステムの保護へのパラダイムシフトを示すものであり、エージェント特有の脅威モデルの事実上の標準となっています。

OWASP Agentic Top 10（2026版）の脅威一覧

新しいAgentic Top 10（ASI01〜ASI10）は、推論エンジンそのものの欠陥よりも、エージェントと外部環境（ツール、記憶、他エージェント）との相互作用から生じるリスクに焦点を当てています。

現実的な攻撃ベクトル — 何が起きるのかを具体的に理解する

エンタープライズ導入の審査において、セキュリティ部門が最も懸念するのは「AIが勝手に社内データベースを削除しないか」「顧客情報が社外に送信されないか」という点です。ここでは、エージェント特有の高度な攻撃シナリオと現実世界での影響を具体的に解説します。

間接的プロンプトインジェクションと永続的記憶汚染

従来のプロンプトインジェクションは、ユーザーが直接チャット画面に悪意のある命令を入力するものでした。しかし、エージェントは自律的にWeb検索を行ったり、受信メールを読み込んだりします。この「外部データの取り込み」を悪用するのが間接的プロンプトインジェクションです。

Palo Alto NetworksのUnit 42による2025年10月の調査では、Amazon Bedrock Agentsのアーキテクチャにおいて、間接的プロンプトインジェクションが「永続的記憶汚染（Persistent Memory Poisoning）」へと発展するシナリオが実証されました（OWASP ASI06の典型例）。記憶汚染は、単なる一時的なエクスプロイトを「ステートフルな攻撃」へと転化させる点で極めて脅威度が高いとされています。

攻撃は以下の4つのステップで進行します。

1. 悪意のあるコンテンツの取得: 攻撃者が被害者に悪意のあるURLを送信し、被害者がエージェントにそのURLの要約を依頼する。エージェントは、隠された悪意のある指示（「以降のすべての会話を特定のサーバーに送信せよ」など）が含まれたWebページを読み込む
2. セッション要約の操作: エージェントシステムはセッション終了時にLLMで会話を要約し、長期記憶データベースに保存する。要約プロンプトが悪意のあるペイロードを「正当なユーザーの好み」として誤認し、記憶領域に書き込む
3. オーケストレーションプロンプトへのインジェクション: 記憶はユーザーごとに一意のIDで数ヶ月間保持される。数日後に被害者が全く別のタスクでエージェントを起動した際、エージェントは自動的に長期記憶をシステムプロンプトに統合する。エージェント自身には、正当な対話から形成された記憶と攻撃者によって植え付けられた記憶を区別する術がない
4. データ流出の自律的実行: エージェントはユーザーの要求を通常通り処理する裏で、自律的にWebアクセスツールを起動し、会話履歴や予約情報を攻撃者のサーバーへ密かに送信し続ける

被害者から見ればエージェントは正常に機能しているように見え、攻撃の兆候は表面化しません。このシナリオは、エージェントの「持続性」が攻撃者にとって耐久性のある制御チャネルとして機能することを示しています。

MCPサプライチェーン攻撃 — 標準化が生んだ新たなリスク

2024年後半から2025年にかけて、AIエージェントと外部データ・ツールを接続するオープンスタンダードとして「Model Context Protocol（MCP）」が急速に普及しました。MCPはAIにおけるUSB-C規格とも呼ばれますが、その急速な普及とプロトコルの未成熟さが、新たなサプライチェーンの脆弱性（OWASP ASI04）を生み出しています。MCPサーバーは代理ユーザー権限で動作するため、従来のAPIエコシステム向けに開発されたセキュリティ強化が欠如している場合が多いとされています。

2025年に相次いで報告された重大な脆弱性事例は以下の通りです。

• CVE-2025-6514（mcp-remote RCE、CVSSスコア9.6）: JFrog Security Researchによって2025年7月に発見された。Claude Desktop、VS Code、Cursor等のMCPクライアントが使用するOAuthプロキシ（mcp-remote）に欠陥があり、攻撃者が罠を仕掛けたURLを送信することでリモートコード実行が達成された。APIキー、クラウド認証情報、SSHキー、Gitリポジトリのコンテンツが窃取可能であった
• CVE-2025-59536（Claude Code APIトークン流出）: Check Point Researchが報告した脆弱性。共有リポジトリ内の設定ファイルを改ざんすることで、開発者がリポジトリを開いた瞬間にMCP接続の承認プロンプトをバイパスして任意のシェルコマンドが実行され、APIキーが流出する
• SQLite MCPサーバーのSQLインジェクション: Anthropicの参照実装において古典的なSQLインジェクションが発見された。このリポジトリは5,000回以上フォークされており、無数のダウンストリームのエージェントに脆弱性が組み込まれた。AIエージェントは内部データベースから取得したデータを「安全」と見なす傾向があるため、データベース内に攻撃用プロンプトを埋め込むことで権限昇格や水平展開が可能になった

これらの事例が示す教訓は明確です。エージェントの能力を拡張するためのツールの標準化が、皮肉にも「一度の脆弱性で数千のAIエージェントを同時に乗っ取れる」巨大なアタックサーフェスを形成してしまったという事実です。MCPの実装においては、認証の欠如、権限モデルの不整合、出力サイズの無制限な許容など、設計レベルでの防御が急務となっています。

Confused Deputy（混乱した代理人）問題と過剰なエージェンシー

エージェントアーキテクチャの根本的な脆弱性は、「Confused Deputy」問題に帰着します。AIエージェントはユーザーの代理として行動し、ユーザー自身が直接持たないバックエンドの特権（APIキー、DBアクセス権など）を保持しています。

攻撃者が自然言語を介してエージェントのコンテキストを操作した場合、エージェントはその特権を使って攻撃者の代わりに悪意のあるアクション（全顧客データの抽出、テーブルの削除など）を実行してしまいます。LLMは確率論的な推論エンジンであるため、自己生成した悪意のある出力を客観的に評価する「自己検証」は構造的に不可能に近いとされています。チャットボットの場合は不適切なテキストが生成されるだけで済みますが、ツール実行能力を持つエージェントの場合、これが重大なインシデントに直結します。

守りの定石 — 最小エージェンシーと権限境界の再定義

前述の脅威モデルに対抗するためには、「静的な権限」から「動的な境界」へのパラダイムシフトが不可欠です。単にアクセス権を制限するだけでは不十分であり、エージェントの自律的な意思決定の範囲そのものを制御する必要があります。

「最小権限」から「最小エージェンシー」への転換

従来のリソースに対する「最小権限（Least Privilege）」アプローチは、予測不可能な行動をとるエージェントに対しては不完全です。現代のセキュリティ設計では、権限（何にアクセスできるか）だけでなく、エージェンシー（どのような自律的な決定や行動を許可するか）を制限する「最小エージェンシー（Least Agency）」のアプローチが求められます。

この転換を実現する具体的な施策は以下の3つです。

• タスクバウンド・トークンの発行: エージェントにデータベースへのフルアクセス権限や無期限のAPIキーを決して渡さない。タスクの実行ごとに、その特定のステップに必要なツールのみを呼び出せる短命のアクセストークン（Ephemeral session credentials）を動的に発行する。例えば、サポートチケットを処理するエージェントには課金APIへのアクセス権は付与しない
• OAuthによるスコープ制御と同意: OAuth 2.0を活用しきめ細かいアクセススコープを定義する。特定の操作（メールのドラフト作成など）には「読み取り専用」のスコープのみを与え、送信や削除といった破壊的な操作にはユーザーの明示的な同意（Human-in-the-loop）を要求する
• 即時無効化（Kill Switch）と動的RBAC: エージェントの挙動がベースラインから逸脱し始めた場合（ASI01の兆候が見られた場合など）、人間のユーザーのアクセスに影響を与えることなく、エージェントのID（Client ID）のみを即座に無効化できるメカニズムを実装する。また、必要に応じて一時的な権限昇格を承認プロセス経由で許可し、タスク終了後に元の権限に戻す動的RBACが有効

モジュラー型アーキテクチャ — セキュリティ境界をLLMの外側に置く

エージェントの構築モデルには、LLMの推論ループの中にツールやメモリをすべて注入する「LLM中心（モノリシック）構成」と、状態管理やツール実行を外部の制御レイヤー（MCPサーバーやゲートウェイプロキシ）で管理する「アプリケーションバウンド（モジュラー）構成」の2つが存在します。

本番環境のエンタープライズ導入においては、後者のモジュラー構成が必須条件となります。推論エンジン（LLM）は決定論的なセキュリティチェックを行うことができないため、すべてのセキュリティ境界は、LLMの推論ループの「外側」にある実行基盤レベルで適用されなければなりません。

具体的な防御設計として、以下のプラクティスが求められます。

• 入出力スキーマの厳格な定義: ツールの入力（モデルから）と出力（モデルへ）のすべてのスキーマを定義し、非準拠のリクエストをビジネスロジック実行前に拒否する
• 全ホップでの無害化（Sanitization）: クロスサイトスクリプティング、SQLインジェクション、リモートコード実行を可能にするシーケンスを排除する
• 出力サイズとレートの制限: エージェントが大量のデータを要求し外部へ流出させる（Exfiltration）シナリオを防ぐため、ツール呼び出し回数やデータ取得量にセッションごとの厳格なクォータを課す

サンドボックス隔離 — エージェント実行環境のベストプラクティス

AIエージェントが自律的にコードを生成・実行できるようになると、ホスト環境の環境変数、APIキー、内部サービスが直接脅威に晒されます。NVIDIAのAI Red TeamやLangChainのベストプラクティスに基づくサンドボックスアーキテクチャを整理します。

2つのアーキテクチャパターンの比較

エージェントをサンドボックス化するアーキテクチャには、業界標準として2つのパターンが存在します。

高度なセキュリティとスケーラビリティが求められるエンタープライズ本番環境では、エージェント側からシークレットを完全に排除するPattern 2（エージェントの完全隔離）が推奨されています。Pattern 2では、ソースコードをバイトコードにコンパイルして元のソースファイルを削除し、ルート権限を即座に放棄するといった環境のハードニングが事前に行われます。

マイクロVMによるカーネルレベルの分離

サンドボックスの実装技術として、標準的なDockerコンテナは悪意のあるAI生成コードを実行する環境としては不十分です（コンテナ・エスケープのリスク）。NVIDIAのAI Red Teamおよび最新のクラウドインフラの実践では、カーネルレベルの脆弱性がホスト全体の完全な侵害につながるのを防ぐため、Firecracker、Kata ContainersなどのマイクロVM（MicroVM）を利用したハードウェアレベルの分離が必須要件とされています。gVisorはある程度の制御されたワークロードには許容されますが、信頼できないAI生成コードに対しては専用の仮想化技術が求められます。

OSレベルで強制すべきセキュリティコントロールとして、以下が挙げられます。

• ネットワークのエグレス制御: HTTPプロキシやIPベースの厳格なホワイトリストを適用し、未承認のアウトバウンド通信を遮断する。DNS解決を指定されたリゾルバに制限することで、エージェントが環境変数やSSHキーを読み取りDNS経由で外部サーバーへ流出させる経路を絶つ。ネットワーク接続はデフォルトで「拒否」とし、手動承認を求める
• ワークスペース外のファイル書き込みブロック: 永続性の確立やサンドボックスのエスケープを防ぐため、指定されたワークスペース外への書き込みをOSレベルでブロックする（設定ファイルの改ざん防止を含む）
• エージェント設定ファイルへの書き込み禁止: エージェントの設定ファイルやローカルMCP構成への書き込みをブロックする。これらはサンドボックス外でシェルコマンドを実行する「フック」を定義できるため、エスケープの踏み台として利用されやすい
• シークレットの動的インジェクション: コンテナ起動時に環境変数としてクレデンシャルを渡すのではなく、資格情報ブローカーを介して特定のタスクに必要な短命のトークンのみをオンデマンドで注入し、使用後に破棄する

安全な評価とテスト手法 — レッドチームとベンチマーク

エージェントシステムは動的かつ確率的であるため、静的なコードスキャンや単発の脆弱性診断だけでは安全性を担保できません。開発および運用ライフサイクル全体を通じて、敵対的なプロンプティングをシミュレートする「AIレッドチーム」の継続的な実行と、ベンチマークによる客観的な評価が不可欠です。

攻撃成功率（ASR）の現実 — 防護なしでは壊滅的

AIエージェントのセキュリティ能力を定量化するために、近年「RAS-Eval」「Agent Red Teaming（ART）Benchmark」「AgentBench」などの新たな評価フレームワークが登場しています。

• RAS-Eval: MCPやLangGraph形式のツールを実装した実世界環境でLLMエージェントのセキュリティを評価するベンチマーク。11のCWE（共通脆弱性列挙）カテゴリにマッピングされた3,802の攻撃タスクを含む。6つの最先端LLMを対象とした評価で、攻撃成功率（ASR）は85.65%を記録し、エージェントの本来のタスク完了率（TCR）を平均36.78%低下させた
• ART Benchmark: マルチステップやツール拡張環境での実用的な脅威モデルを反映し、直接的および間接的なインジェクション攻撃をシミュレートする。防護策を講じていない多くのエージェントが、わずか10〜100回の攻撃クエリ以内に100%に近いASRを記録
• Dreadnode AIレッドチームベンチマーク: 70のサイバーセキュリティCTF（Capture The Flag）課題でモデルを評価。Claude 3.7 Sonnetが61%、Gemini 2.5 Proが55.7%の課題をクリアした一方、オープンソースモデル（Llama 3.3 70b等）はごく少数のインジェクション課題しか解けなかった

継続的レッドチーム運用とポリシーベースのガードレール

これらのベンチマーク結果を踏まえ、エンタープライズの導入環境では、Microsoft AI Red Teamingなどが提唱する「継続的な自動スキャン」と、システム稼働中の動的なガードレールの統合が推奨されています。

• アドバーサリアル・プロービングの自動化: 合成された良性クエリと攻撃プレースホルダーを含むモックツール出力を使用して、エージェントが間接的プロンプトインジェクションによって禁止されたアクションを実行しないか、機密データを漏洩させないかを継続的にテストする
• 評価軸の多次元化: 目標の達成度（Goal Achievement）、ルールの遵守（Rule Compliance：ポリシーガードレールへの適合）、手続きの規律（Procedural Discipline：正しいツールの使用とワークフロー）の3次元でスコアカードを作成し、導入判定の客観的指標として活用する。ASRと合わせて、このスコアが許容可能な閾値を下回るまでシステムを本番稼働させるべきではない

ガバナンスと導入審査 — グローバル標準と日本市場の要件

エージェントを企業導入する際、技術的な防御機構の構築だけでなく、法務・コンプライアンス部門の審査を通過するためのガバナンスフレームワークが要求されます。

NIST Agentic AI Risk-Management Standards Profile（2026年）

2026年2月、カリフォルニア大学バークレー校のCLTC（Center for Long-Term Cybersecurity）は、NISTのAIリスクマネジメントフレームワーク（AI RMF 1.0）を拡張する形で「Agentic AI Risk-Management Standards Profile」を公開しました。このプロファイルは、自律型エージェント特有のリスク（意図しない目標の追求、権限の昇格、自己複製、シャットダウンへの抵抗など）を管理するための包括的なガイドです。

審査資料に組み込むべき、NISTの4つのコア機能（Govern、Map、Measure、Manage）に基づく重要な管理プラクティスは以下の通りです。

• 人間の制御と説明責任: システムに完全な自律性を与えるのではなく、定義された制限内での「境界付き自律（Bounded Autonomy）」を確保する。介入ポイントの設計、エスカレーション経路の確立、エージェントが制御不能に陥った際の確実な停止メカニズムをアーキテクチャレベルで組み込む
• システムレベルのリスク評価: 汎用モデル単体の評価ではなく、マルチエージェント間の相互作用（ハルシネーションや誤情報の連鎖的増幅など）、外部ツールの使用、アクセス可能な環境全体に対する包括的なリスク評価を実施する
• 多層防御と封じ込め: 現在の評価技術（ベンチマーク等）には限界があるため、高度な能力を持つエージェントは常に「信頼できないエンティティ」として扱い、不正なリソース獲得を防ぐ技術的な障壁（Containment）を構築する

グローバル動向として、EU AI Act（AI法）の段階的施行（2025年〜2027年）により、高リスクAIシステムにはアクセス制御、権限管理、監査ロギングといった「技術的および組織的措置」が法的に義務付けられつつあります。

監査証跡 — 「なぜその行動をしたか」の記録義務

従来のSaaSアプリケーションの監査ログでは「誰が・いつ・何をしたか」の記録で足りていました。しかし、AIエージェント環境（ISO/IEC 42001対応やEU AI Act準拠）では「なぜその行動を選択したか」という推論プロセスの追跡可能性（Traceability of Reasoning）が厳しく求められます。

• 意思決定境界の完全な記録: 単なる最終出力結果だけでなく、プロンプトの入力、LLMが生成した中間推論（思考の連鎖・推論ツリー）、各ツール呼び出しの引数と結果を、99%以上のカバレッジで改ざん不可能な（暗号学的に署名された）ログとしてキャプチャし、通常3〜7年間保持する
• PIIの非同期マスキング: エージェントとのフルカンバセーション履歴をそのままロギングすると、GDPRやCCPAなどのプライバシー規制違反を直接引き起こす。PIIのマスキングをデータ取り込み時にリアルタイムで実施し、パフォーマンスオーバーヘッドを5%以下に抑えるために非同期のバッチ処理でログを書き込むアーキテクチャが不可欠

日本市場における導入要件

日本国内においては、総務省・経済産業省が発行する「AI事業者ガイドライン（第1.01版）」が実質的なエンタープライズ導入の拠り所となっています。同ガイドラインでも「トレーサビリティの向上」「意思決定に影響を与えるデータの収集」「第三者が検証できる形での文書化」が明記されており、グローバルなロギング要件と完全に方向性を一にしています。

日本企業の厳格な導入審査プロセスにおいては、抽象的なリスク論ではなく、設計段階での具体的な「脅威の洗い出し」が重視されます。NRIセキュアテクノロジーズが提供する「AI Yellow Team（脅威モデリングサービス）」のようなアプローチが参考になります。これは、システムの開発初期段階においてシステム構成図や仕様書を分析し、STRIDEなどの脅威フレームワークを用いて攻撃シナリオを一覧化するものです。特定された脅威に対してリスクレベルを分析し、対策を講じた後の「セキュリティ要件一覧（残余リスクの定義）」として文書化します。

エンタープライズの稟議を通過させるためには、この「特定された脅威（Threat）→ 実装する技術的対策（Mitigation）→ 受容する残余リスク（Residual Risk）」の論理構造を、経営層やリスク管理委員会に対して明確に提示する説明資料が不可欠です。

あわせて読みたい

• ガバナンス設計テンプレート：ログ・個人情報・著作権・社内利用ルールの作り方
• Human-in-the-loop設計：人に戻す
• 信頼性と品質維持

まとめ：導入審査を突破するための4つの原則

AIエージェントのエンタープライズ導入は、業務効率化に劇的な革新をもたらす一方で、「インフラの信頼性」と「自律性の境界」に関する未曾有のセキュリティ課題を突きつけています。導入審査を突破し安全に運用を開始するためには、本記事の分析から導き出された以下の4つの重要原則をシステム設計の根幹に据える必要があります。

1. 「最小権限」から「最小エージェンシー」への転換: エージェントに対して永続的な特権を決して与えず、タスクごとの短命トークンと厳密なスコープを動的に割り当てる。認可の判断を確率論的なLLMの推論に委ねることは、決定的なアーキテクチャの失敗である
2. ゼロトラストに基づく環境の隔離: コード実行や外部システム操作を伴うエージェントには、マイクロVMを用いた「Pattern 2（エージェントの完全隔離）」アーキテクチャを採用する。サンドボックス内にはシークレットを一切配置せず、コントロールプレーン経由で外部通信をプロキシすることでアイソレーションを物理的レベルで担保する
3. MCPサプライチェーンの検証と厳格なネットワーク制御: MCPサーバーなどの外部ツールの定義やWebからの取得データは、常に「汚染されている」前提で設計する。OSレベルでの厳格なネットワークエグレス制御（デフォルト拒否と手動承認）により、万が一プロンプトインジェクションによって記憶が汚染されてもデータ流出をネットワークレイヤーで物理的に遮断する
4. 思考プロセスの監査と継続的レッドチームによる評価: 最終出力結果だけでなく中間推論やツール呼び出しのパラメータを不変の監査ログとして記録し（PIIのマスキングを併用）、NISTのAgentic AI Profileに準拠した説明責任を果たす。RAS-EvalやARTなどの手法でASR（攻撃成功率）を継続的に測定し、システムの脆性を定量的に可視化する

AIエージェントのリスクは、技術の進歩とともに「単純なプロンプトへの攻撃」から「実行環境と記憶空間のハッキング（ステートフル攻撃）」へと高度化しています。企業は、エージェントを「賢いツール」としてではなく、「予測不可能な能力を持つインサイダー（内部関係者）」としてモデリングし、境界の封じ込めと人間の介入を前提とした防衛戦略を構築することで初めて、真に信頼できる自律型AIシステムの運用が可能となります。

AIエージェントの脅威モデル策定やセキュリティ設計についてお悩みの方は、ぜひAgenticベースにご相談ください。導入審査を見据えた脅威分析から、権限境界の設計、監査証跡の要件定義まで、貴社のエージェント導入を包括的に支援いたします。

この記事の著者

Agentic Base 編集部

AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。