11月4日、Matt Saundersが「Docker Urges Isolation and Governance for AI Agent Security」と題した記事を公開した。この記事では、AIエージェントが自律的にツールを呼び出し・コードを実行する環境で生じる5つのセキュリティリスクと、Dockerが推奨する対策について詳しく紹介されている。以下に、その内容を紹介する。

AIエージェントのセキュリティが「従来の対策では不十分」な理由

DockerはプロダクトマネージャーのEric JiaとプリンシパルプロダクトマーケティングマネージャーのSrini Sekaranが共著したブログ記事を公開し、AIエージェント特有のセキュリティリスクを整理した。

従来のWebセキュリティは「既知のエンドポイントに到達するリクエストを決定的なコードで処理する」というモデルを前提としているが、エージェントはこのモデルに当てはまらない。コーディングエージェントは1つの指示を受けただけで、ファイルの読み込み・依存パッケージのインストール・設定の変更・テスト実行・コミットのプッシュまで連鎖的に実行する。エージェントが乗っ取られたり誤誘導されたりした場合、通常のサービスよりはるかに広い範囲の操作が行われる可能性がある。

「エージェントは質問に答えるだけでなく、自律的にブラウズし、コードを実行し、ツールを呼び出す。そのため、悪意ある・または操作された1つの指示が、単なる誤答ではなく実害に変わりうる」
— Eric Jia & Srini Sekaran（Docker公式ブログ）

5つのリスク：最も深刻なのは「プロンプトインジェクション」

1. プロンプトインジェクション（最重要）

Dockerが最大のリスクとして挙げるのがプロンプトインジェクションだ。システムを直接攻撃するのではなく、エージェントが読み込む素材（Webページ・コードコメント・Issueトラッカー・ドキュメント）に攻撃者が指示を埋め込む手法である。

記事ではコーディングエージェントがリポジトリ内に隠された指示に従い、ユーザーが意図しない操作を実行した実例が示されている。

Dockerが強調するのは、モデルへの指示だけでは防御できないという点だ。

「エージェントには正当な指示と注入された指示を確実に区別する手段がない。だから防御策は、乗っ取られたエージェントがアクセスできる範囲を制限することだ」
— Eric Jia & Srini Sekaran

2. ツールの悪用・ポイズニング

エージェントにタスクに不要なツールを与えると、それだけ攻撃対象が広がる。さらに、ツールの説明文自体に隠れた指示を仕込み、エージェントをツールの誤用に誘導する「ツールポイズニング」も指摘されている。

この脅威はOWASPのAgentic AI Threats and Mitigations（2025年9月にInfoQが報道）とも一致しており、OWASPはアクセス検証・行動監視・操作境界の設定・改ざん防止ログを推奨している。

3. 過剰な自律性（Excessive Autonomy）

記事では「YOLOモード」——すべての操作を自動承認する設定——を代表例として挙げる。生産性は上がるが、同時にリスクも拡大する。

具体的な事例として以下の2件が示されている：

• 開発者がコーディングエージェントに古いリポジトリのクリーンアップを依頼したところ、エージェントがrm -rf ~/コマンドを確認なしで実行し、ホームディレクトリを丸ごと削除した
• AWSのエンジニアがCost Explorerのバグ修正をオペレーターレベルの権限でエージェントに依頼した結果、エージェントが本番環境を削除・再構築することを選択し、13時間にわたるリージョナル障害を引き起こした

4. クレデンシャルの漏洩

エージェントが開発者の個人トークンを継承すると、あらゆる操作がその人のフルアクセス権限で実行される。Dockerは短命なクレデンシャルをランタイム時にインジェクトし、会話コンテキストには含めないことを推奨する。プロンプト・設定ファイル・イメージの環境変数に含まれたシークレットは、プロンプトインジェクションを通じて読み取られるリスクがある。

5. データ外部流出

ネットワークアクセスを持つエージェントがコンテキスト内に機密情報を保持している場合、意図しない送信先にそのデータを送信する可能性がある。マルチエージェントシステムではエージェント間のデータ受け渡しごとにリスクが増す。Dockerはネットワーク送信先の許可リスト（allowlist）制御と、エージェント間のすべてのハンドオフを「信頼できない入力」として扱うことを推奨する。

Dockerの答え：Sandboxes + AI Governance

Dockerはこれらのリスクへの対策として、2つの製品を位置づける。

• Docker Sandboxes：各エージェントをファイルシステムとネットワークを制御した使い捨てのマイクロVM上で実行
• AI Governance：エージェントが使用できるアクション・ツール・クレデンシャルを定義・強制する仕組み

Dockerは「隔離（Isolation）が最もインパクトの大きい出発点」とした上で、ガバナンスがエージェント群全体の監視を担うと説明する。

この方向性は他の取り組みとも共鳴している。GoogleのGKEセキュリティブループリント（InfoQ、2026年7月報道）はgVisorベースのGKE Sandboxを推奨し、Metaはプロンプトインジェクション検出・推論チェック・静的解析を組み合わせたLlamaFirewallをオープンソースで公開している。

コミュニティの反応：「コンテナだけでは足りない」

r/AI_Agentsのスレッドでは、隔離の粒度について議論が起きている。

「Dockerはテナンシーとリスクモデルを最初に評価しないと判断できない。Dockerはおよそ40の特権的なシステムコールを無効化するが、約500のシステムコールは残る。deny-by-defaultのアクセス権、最小権限の原則、ポリシー強制ポイント、情報フローの制御が必要だ」
— HectaMan（r/AI_Agents）

「ローカルマシンで自分のためだけに動くエージェントならDockerで十分かもしれないが、他人のコードを実行する場合はカーネルを共有するのは避けたい。その場合はマイクロVMかgVisorベースの隔離を使うべきだ」
— Groady（r/AI_Agents）

議論の焦点は「コンテナ vs コンテナなし」ではなく、隔離の境界線がワークロードの信頼境界に合致しているかという点に移っている。

結論

AIエージェントがリポジトリ・クラウドアカウント・本番システムへの書き込み権限を持つようになった今、エージェントへの入力が敵対的である可能性を前提とし、誤った判断が広範な侵害につながらない設計が求められる。Dockerのガイドはその出発点として有用だが、より難しい問いはこうだ——エージェントが本当に必要な権限は何か、その権限をいつ失効させるか、実行された操作を誰がレビューするか。

詳細はDocker Urges Isolation and Governance for AI Agent Securityを参照していただきたい。