AIエージェントのセキュリティはなぜ難しいのか？Google等が示す11の攻撃事例とシステム防御の指針
公開日
セキュリティ
AIが自律的にツールを操作してタスクをこなす「Agentic Computing（エージェントコンピューティング）」が急速に進化しています。しかし、AIモデル単体をどれほど賢く、安全に振る舞うようトレーニングしても、悪意ある攻撃を防ぎきれず、システム全体としてのセキュリティを確保するには不十分であることが明らかになりつつあります。
本記事では、Google、UC San Diego、UW Madisonなどの研究チームが発表した論文「Systems Security Foundations for Agentic Computing」（2025年）に基づき、AIエージェント特有のセキュリティ課題、実際に確認された攻撃事例、そして堅牢なシステム構築に向けた具体的な指針を解説します。
AIモデルの「アライメント」だけでは防げない理由
現在、AIエージェントのセキュリティ対策の多くは、モデルの アライメント（調整） に依存しています。これは、モデルをトレーニングして「攻撃的な入力に抵抗する」「有害な出力をしない」ようにするというアプローチです。
しかし論文では、コンピュータセキュリティの観点から「これは常に無害で役立つソフトウェアを書こうとする努力に等しく、不十分な戦略である」と断じています。ソフトウェアの歴史が証明しているように、単一のプログラム（この場合はAIモデル）をバグや脆弱性から完全に守ることは不可能です。
必要なのは「システムアプローチ」
従来のコンピュータセキュリティでは、システム全体で防御する「システムアプローチ」が採用されてきました。これは、ハードウェア、OS、アプリケーションといった異なるレイヤーに「決定論的なガードレール（確実な防御壁）」を設ける手法です。
図表1：標準的なセキュリティアーキテクチャ（青が信頼できるコンポーネント、赤が信頼できないコンポーネント
図表1に示すように、堅牢なシステムには以下の要素が不可欠です。
- TCB（Trusted Computing Base）： 攻撃者が絶対に干渉できない、システムの信頼の核（OSカーネルなど）。
- セキュリティポリシー： 誰が何にアクセスできるかを定めた明確なルール。
- セキュリティ境界： 信頼できる領域（青）と信頼できない領域（赤）の境界線。
- 参照モニタ： 全てのリクエストをポリシーと照合し、許可・拒否を判断する門番。
AIエージェントにおいても、モデル単体の防御に頼るのではなく、このようなシステムレベルでのアーキテクチャ設計が求められています。
既存のセキュリティ原則を阻む「4つの技術的壁」
しかし、従来のセキュリティ原則をそのままAIエージェントに適用しようとすると、AI特有の性質による4つの大きな壁に直面します。
① 確率的なTCB（信頼の基点が揺らぐ）
従来のハードウェアやOSは「決定論的」に動作します（例：書き込み禁止メモリへの書き込みは100%エラーになる）。しかし、AIエージェントにおけるTCBの中心はLLM（大規模言語モデル） であり、その動作は「確率的」です。セキュリティチェックが99%成功しても、残りの1%で突破されるリスクが常に残ります。
② 動的でタスク固有のポリシー
従来のアプリは「カメラを使う」「連絡先を見る」など、インストール時に必要な権限を定義できました。しかし、AIエージェントはユーザーの自然言語による指示（プロンプト）に応じて動的にタスクを生成します。タスクが始まるまで、エージェントがどのツールやデータにアクセスすべきかが予測できず、事前に厳格なポリシー（最小特権）を定めることが極めて困難です。
③ 曖昧なセキュリティ境界（セマンティックギャップ）
OSには「カーネル空間」と「ユーザー空間」という明確な境界があり、システムコールという監視ポイントが存在します。一方、AIエージェントは自然言語の指示を受けて、WebブラウザやAPIツールを直接操作します。ここには明確な中間層が存在しないため、「意図しない操作」を検知して遮断するための適切な監視ポイントを見つけるのが困難です。
④ プロンプトインジェクションの本質
プロンプトインジェクションは、AIへの入力に悪意ある命令を紛れ込ませる攻撃です。論文では、これを従来のセキュリティにおける「動的コード読み込み（Dynamic Code Loading）」と同質の問題と定義しています。Webページにおける外部JavaScriptの読み込みと同様、外部から渡されたデータがいつの間にか「実行可能な命令」として処理されてしまう構造的な脆弱性です。
11の攻撃事例から見る脆弱性の実態
論文では、実際に確認された11の攻撃事例を分析しています。これらの攻撃は、以下の5つのセキュリティ原則のいずれか（または複数）が破られたことで成立しました。
侵害された5つの重要原則
- 最小特権: 必要最低限の権限のみを与えること。
- TCB耐タンパー性: システムの核となる設定や記憶が書き換えられないこと。
- 完全な仲介: 全ての操作に対して毎回必ずセキュリティチェックを行うこと。
- 安全な情報フロー: 機密情報が許可なく外部へ流れないこと。
- 人間の脆弱性: ユーザーの誤操作や判断ミス（ソーシャルエンジニアリング）を防ぐこと。
攻撃事例と違反原則の対応表
| 攻撃名 | 最小特権 | TCB耐タンパー性 | 完全な仲介 | 安全な情報フロー | 人間の脆弱性 |
|---|---|---|---|---|---|
| Microsoft Copilot Exfiltration | ✓ | – | ✓ | ✓ | – |
| Devin AI Exposed Ports | ✓ | – | – | ✓ | – |
| ChatGPT Long-Term Memory SpAIware | – | ✓ | – | ✓ | – |
| Amp AI Code Arbitrary Command Execution | – | ✓ | – | ✓ | – |
| DeepSeek AI Account Takeover | – | – | ✓ | ✓ | – |
| Terminal DiLLMa | – | – | ✓ | ✓ | – |
| ChatGPT Operator Prompt Injection | – | – | – | ✓ | ✓ |
| Devin AI Secret Leaks | ✓ | – | – | ✓ | – |
| Cursor AgentFlayer | ✓ | – | – | ✓ | – |
| Claude Code Exfiltration | ✓ | – | – | ✓ | – |
| AI ClickFix | ✓ | – | – | ✓ | ✓ |
具体的な攻撃手口（3つのカテゴリ）
これらの攻撃は、具体的にどのような手口で行われたのでしょうか？大きく3つのパターンに分類できます。
パターンA：機密情報の持ち出し
エージェントを騙して機密データを読み取らせ、外部へ送信させる攻撃です。「安全な情報フロー」の原則違反が主因です。
- Microsoft Copilot Exfiltration: メールに隠されたプロンプトが発動し、ユーザーの機密情報を検索して攻撃者へ送信させました。
- Claude Code Exfiltration: 開発ツールのふりをしてDNSリクエストを発生させ、開発環境のAPIキーなどをDNSクエリに乗せて流出させました（下図参照）。
- ChatGPT Memory SpAIware: 長期記憶機能（Memory）に悪意ある指示を埋め込み、将来の会話内容を永続的に攻撃者へ送信し続ける「スパイウェア」化させました。
図表2：Claude CodeにおけるDNS経由のデータ流出。pingコマンドが悪用されている。
パターンB：システムの乗っ取りと改ざん
エージェントの権限を悪用し、システム設定を変更したり、任意のコードを実行したりします。
- Devin AI Exposed Ports: Devinが持つポート公開ツール（
expose_port）を悪用し、Devin自身の内部ファイルシステムをネット上に公開状態にしました。 - DeepSeek AI Account Takeover: プロンプトインジェクションとXSSを組み合わせ、ユーザーのブラウザ上で不正スクリプトを実行し、アカウントを乗っ取りました。
パターンC：ソーシャルエンジニアリング
エージェントを介して、ユーザー自身に危険な操作を行わせます。
- AI ClickFix / ChatGPT Operator: エージェントに「このコマンドをターミナルに貼り付けて」といった指示を表示させ、ユーザーがそれを信頼して実行することでPCが侵害されました。これは「人間の脆弱性」を突いた攻撃です。
安全なエージェント構築に向けた3つの重要テーマ
これらの脅威に対抗するため、論文では以下の3つの研究領域における進展を提言しています。
① 「命令」と「データ」の確実な分離
プロンプトインジェクションの根本原因は、LLMが「システムからの命令」と「外部からのデータ」を区別できないことにあります。CPUにおける「実行不可ビット（NX bit）」のように、データ領域にあるコードは絶対に実行させないような、確実な分離メカニズムの実装が急務です。
② エージェントのための「最小特権」とアクセス制御
エージェントは便利さゆえに過剰な権限を持ちがちです。「このGitHub Issueを要約して」というタスクなら、読み取り権限だけを与え、書き込みや削除はブロックすべきです。自然言語のタスクから「今必要な権限」だけを動的に推論し、制限をかける技術が必要です。
③ データの動きを監視する「情報フロー制御」
アクセス制御が「入り口」の防御なら、情報フロー制御は「出口」の防御です。機密データ（APIキーなど）に目印（ラベル）を付け、そのデータが信頼できない外部ネットワークへ送信されようとした瞬間に検知・遮断する仕組みです。LLM内部での複雑な計算過程で、どうラベルを追跡し続けるかが研究の焦点となります。
結論：確率的なAIを、決定論的なシステムで守る
AIエージェントのセキュリティは、モデルを賢くするだけでは達成できません。モデルが確率的に動作（＝たまに間違う）することを前提とし、その周囲を「決定論的なシステム」で囲うアーキテクチャへの移行が必要です。
入力を厳格に検証し、実行できるツールをタスクごとに制限し、データの流出経路を監視する。従来のコンピュータセキュリティが培ってきた知見を、AIという新しい文脈で再実装することが、安全なエージェント活用の鍵となるでしょう。
AIエージェントの脅威と導入前チェック項目を体系的に確認したい場合は、 AIエージェントのセキュリティリスク総まとめ もあわせてご覧ください。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: