9月29日、Google AIが「7 ways to lock down AI agent sandboxes in production (beyond Docker containers)」と題した記事を公開した。自律型AIエージェントをローカルのDockerコンテナで動かすのは手軽だが、本番環境では標準的なDockerのカーネル共有モデルが深刻なセキュリティホールになりうる——そのギャップを埋める7つの実践的手法が詳述されている。
自律型コーディングエージェントをローカルのDockerコンテナで動かすのは手軽だが、本番環境では話が変わる。標準的なDockerコンテナはホストOSのカーネルを共有しており、エージェントが悪意あるコードを実行した場合にホストへのエスケープが起きうる。さらに、コンテナ内に渡したAPIキーはプロンプトインジェクション攻撃によって外部サーバーへ漏洩しうるというのが現実だ（元記事ではこのリスクを実演付きで解説している）。
最重要ポイント①：Dockerではなく本物のカーネル分離を使う
最も根本的な対策がこれだ。標準Dockerではなく、gVisorまたはマイクロVMを使ったカーネルレベルの隔離を選択する。
gVisor（ユーザー空間カーネルサンドボックス）：Cloud RunやGKE Sandboxで採用されている方式。コンテナとホストOS間のすべてのファイル・ネットワーク操作をプロキシが検査する。ミリ秒単位で起動でき、通常のコンテナイメージをそのまま使えるが、
npm installのような大量ファイル操作は若干遅くなる。軽量マイクロVM（Firecracker / KVM）：ハードウェア仮想化を使い、エージェントごとに独立したLinuxカーネルを約125ミリ秒で起動する。エージェントがroot権限を必要とする重いビルド処理を行う場合に適している。Compute Engine Confidential VMsもこの選択肢に含まれる。Pythonやbashスクリプトの実行だけが目的ならば、Gemini Enterprise Code Execution Sandboxというマネージドな選択肢もある。
最重要ポイント②：セッション全体にわたる累積行動を監視する
単一ツール呼び出しへの事前フックチェック（例：rm -rfのブロック、払い戻しツールに$50上限を設定）だけでは不十分だ。単一ステップのルールにはメモリがない。
Google Cloudのエンジニアリングチームが実証したケースでは、$50上限を設けても、エージェントがissue_refund($20)を6回ループ実行することで合計$120を引き出すことができた。単一ステップのパラメータチェックに加え、セッションレベルの予算管理とModel Armorのような異常検知を組み合わせ、会話全体を通じた累積影響を追跡する必要がある。
残り5つの手法
③ APIキーをサンドボックスの外に置く：一時トークンであっても環境変数として渡してはいけない。Google Cloud Secret Managerにキーを保管し、エージェントの外部API呼び出しはApigee AI Gateway経由でルーティングする。ゲートウェイがIAM Workload Identityでエージェントを認証し、承認済みの宛先URLへの通信時にのみキーを付与する。
④ セットアップスクリプト段階からネットワークを遮断する：エージェントの推論中はインターネットをブロックしても、npm installやpip installのセットアップ段階では開放されているケースが多い。VPC Service Controlsとegressファイアウォールルールでライフサイクル全体をブロックし、パッケージはArtifact Registryの事前スキャン済みキャッシュから取得する。
⑤ CI/テストファイルを読み取り専用でマウントする：エージェントが.github/workflowsやcloudbuild.yamlなどのCIファイルを編集できる状態では、テストアサーションを削除して「テスト通過」を偽装するリスクがある。テストスイートとCI設定フォルダを読み取り専用でマウントし、エージェントがビルドパイプラインを変更しようとしたプルリクエストは自動的にブロックする。元記事ではgit worktreeによる分離ワークスペースの活用も紹介されている。
⑥ LLM待機中のアイドルコンピュートコストを削減する：サンドボックスのコスト最適化はセキュリティ設計と密接に関係する。長時間セッション中、サンドボックスがCPUを実際に使うのはごく一部で、多くの時間はLLMのトークン返却や人間の承認待ちでアイドル状態にある。24/7稼働の仮想マシンではアイドル分まで課金されるため、Cloud RunのようなアクティブCPU課金のサーバーレスランタイムを使い、セッション状態はGemini Enterprise Agent Platform Sessionsに外部保存する。コストを抑えながら短命なサンドボックスをセッションごとに払い出すアーキテクチャは、攻撃面の最小化という観点でも理にかなっている。
⑦ 監査ログをリアルタイムでサンドボックス外に送信する：エージェントがターミナルアクセスを持つ同じコンテナ内にログを保存すると、コンテナクラッシュや不正コマンドでログが消滅する。Cloud TraceとCloud Audit Logsへリアルタイムでストリーミングし、1ターンごとに「何を要求したか」「許可/ブロックされたか」「実際に触れたファイル・URLは何か」「コンテナと権限が終了時に削除されたか」の4点を記録する。
詳細は7 ways to lock down AI agent sandboxes in production (beyond Docker containers)を参照していただきたい。
