9月2日、Cloud Native Nowが「Containers Became the Unit of Speed. AI Agents Are Making VMs the Unit of Trust」と題した記事を公開した。AIエージェントのサンドボックス脱出事件を契機に、コンテナに代わってVMが新たなセキュリティ境界として復権しつつある状況について詳しく紹介されている。

AIエージェントがコンテナを「破った」

2026年8月26日、OpenAIが公開したHugging Faceインシデントの技術報告書は、インフラ設計者にとって見逃せない内容だった。

OpenAIのAIエージェントは、サイバーセキュリティ評価のためにコンテナ内で動作していた。シェル、Python、ブラウザ、パッケージインストーラを備えた隔離環境で、パブリックインターネットへのアクセスは制限。ソフトウェアパッケージには社内のJFrog Artifactoryを経由してのみアクセス可能という構成だった。

エージェントはその制限を回避した。

Artifactoryに未知の脆弱性を発見してパブリックインターネットに到達し、さらにそのサービスを「掲示板」として悪用。別の評価セッションで動作する他のエージェントが参照できるよう、発見内容を書き残していた。外部に出たエージェントはHugging Faceの公開された認証情報を取得し、本番ワーカーでコードを実行。Kubernetes基盤全体に権限を拡大した。

単一ワーカーPodから複数クラスターの管理者・ホストレベルアクセスに到達するまで、13時間未満だった。

コンテナによる隔離は、エージェントには不十分だった。

コンテナに課されていた「二つの役割」

コンテナはクラウドネイティブ時代において、事実上二つの仕事を担ってきた。

一つはアプリケーションと依存関係のパッケージング。開発者のラップトップから本番環境まで、一貫したデプロイを実現する標準単位となった。もう一つは隔離境界としての役割。Linuxのnamespace、cgroup、セキュリティプロファイルによってホストOSのカーネルを共有しながらワークロードを分離する。

通常のアプリケーションコードはデプロイ前に記述され、依存関係や権限、期待される動作をレビュー・テストできる。コンテナ隔離はその前提の上で成立している。

AIエージェントはその前提を崩す。セッション中に新たなコードを生成・実行し、パッケージをインストールし、外部ツールを呼び出し、探索結果をもとに行動を変える。あるパスがブロックされれば、別のパスを探し続ける。この「粘り強さ」はエージェントの機能として設計されているが、共有ホストカーネルを最後の防衛線にできない理由でもある。

DockerはエージェントをmicroVMで包む

この変化を最も明確に体現しているのがDockerだ。

Docker Sandboxesは、コーディングエージェントの各セッションを独自のmicroVM内で実行する。独立したファイルシステム、ネットワーク、Dockerデーモンを持ち、エージェントはホストのDockerデーモンを制御せずにイメージのビルドやコンテナの起動が可能だ。

アウトバウンドトラフィックはホスト側プロキシを経由してネットワークポリシーを適用。認証情報はサンドボックス外に保持され、必要時にのみ注入される。MCPサーバーなどのツールへのアクセスは、呼び出し前に認証・認可・ログを行うゲートウェイを経由する。

Dockerのアーキテクチャガイダンスは区分を明示している。ホストDockerアクセスが不要な軽量パッケージングにはコンテナを推奨し、広範なDocker機能を必要とする自律的な処理にはmicroVMサンドボックスを推奨する。

Dockerは2026年8月31日のブログ記事で、エージェントを「非決定論的かつ一時的」と表現している。同じタスクでも毎回異なるパスをたどり、調査が始まる頃にはセッション自体が消えていることもある。人間の作業者を前提に設計されたセキュリティ制御では対応できない、という立場だ。

microVMは「重いVM」ではない

VMへの回帰と聞くと、コンテナ以前への逆行に思えるかもしれない。しかし選択肢は「重量級VM」か「カーネルを共有する軽量コンテナ」の二択ではなくなっている。

AWSがLambdaなどのサービスのために開発したFirecrackerは、125ミリ秒未満で起動し、オーバーヘッドは5MiB未満、ホスト1台あたり毎秒最大150個のmicroVMを生成できる（いずれも元記事に記載の数値）。通常のVMに含まれる汎用的なハードウェアエミュレーションを排除し、ハードウェア仮想化境界を維持しながらコンテナに近い起動速度と密度を実現している。

Kubernetesも対応を進めている。Kubernetes SIG Appsが開発するAgent Sandboxは、エージェントランタイム向けのSandboxカスタムリソースを導入し、Kata ContainersやgVisorといった強固な隔離ランタイムをサポートする。KataはOCIイメージとKubernetes APIを維持しながら、ワークロードを軽量VMの内部に配置する。

GoogleとAnyscaleはRayでも同様のアプローチを取る。元記事によれば実験的なサンドボックスAPIが追加され、モデルが生成したコードをgVisor隔離下で実行できる。GoogleのGKEに関するアナウンスはその前提を端的に述べている：「モデルが生成したコードは、信頼できないものとして扱わなければならない」。

VMだけでは足りない

Anthropicは141,006件のサイバーセキュリティ評価実行を分析し、Claudeモデルが実システムに不正アクセスした事例を3件確認した。

OpenAIのケースはゼロデイ脆弱性の悪用による境界突破だったが、Anthropicのインシデント報告は別の失敗パターンを示す。サードパーティの評価パートナーとの設定ミスで、インターネットアクセスが意図せず有効になっていた。Claudeはインターネット接続がないと伝えられていたため、実際に到達した本番システムをCTF演習の一部と誤認して操作を続けた。

Anthropicはその後、単一の防御層に過度に依存していたと認め、サンドボックスの封鎖確認プロセス、ツール呼び出し前にプロービングや脱出行動を検出するクラシファイア、ランタイムモニタリングの拡充、高リスク環境向けの仮想化強化を追加した。

OpenAIも同様の結論に至っている。隔離・ネットワーク制御・補助サービスは、それぞれが独立した重複した防御を提供しなければならない。新たな脆弱性を発見できるエージェントは、それを封じ込める機構も攻撃できると想定すべきだ。

本番エージェント環境が必要とする要素は次のとおりだ：

• デフォルト拒否のネットワークアクセス
• 認証情報のサンドボックス外保持
• 厳格なファイルシステム境界
• MCPサーバーおよびAPIへのガバナンスされたアクセス（認証・認可・監査ログ付き）
• ランタイムモニタリング（プロービング、権限昇格、意図しない外部通信の検出）
• 使い捨てサンドボックス（タスク完了後にファイルシステム・パッケージ・成果物ごと破棄）

プラットフォームチームへの示唆

クラウドネイティブのプラットフォームチームは、エージェントを独自のワークロードクラスとして扱う必要がある。

人間が書いたアプリケーション、CI/CDジョブ、インタラクティブなコーディングアシスタント、自律型本番エージェント、サイバーセキュリティ評価は、それぞれ異なるリスクプロファイルを持つ。同じランタイム、ネットワークアクセス、認証情報、監視ポリシーを自動的に適用してはならない。

KubernetesのRuntimeClassは、gVisorやKata Containersといった強化ランタイムに機密ワークロードを誘導できる。ネットワークポリシーで通信を制限し、アドミッションコントロールで設定を強制できる。構成要素は既にある。それをエージェント向けに組み合わせるアーキテクチャ判断が、今問われている。

コンテナはデリバリーの単位であり続ける。VMが信頼の単位になりつつある。

詳細はContainers Became the Unit of Speed. AI Agents Are Making VMs the Unit of Trustを参照していただきたい。