AIエージェントは、サンドボックスを破らずに脱出できる

サンドボックスは、AIコーディングエージェントにとって重要なセキュリティ対策となっていますが、新たな研究によると、多くの組織が想定しているような隔離を必ずしも実現できていない可能性があるといいます。

Pillar Securityは、Cursor、Codex、Gemini CLI、Antigravityといったツール内のエージェントが、技術的にはサンドボックスから「脱出」することなく、間接的にセキュリティ境界を越えられることを示す一連の脆弱性を公表しました。

「ほとんどすべてのケースで、エージェントはサンドボックスを直接破る必要がありませんでした」と研究者らはブログ記事で述べています。「サンドボックスの外側にある信頼済みコンポーネントが、後で実行・読み込み・スキャン、あるいは安全とみなして処理するようなものを書き込みさえすればよかったのです」

今回の調査結果では、AIサンドボックスにおける4つの具体的かつ再現可能な失敗パターンが明らかになりました。具体的には、デナイリスト方式のサンドボックスがOSの複雑さの増大に対応しきれていないこと、ワークスペース設定が実質的に実行可能なコードになってしまうこと、コマンドの許可リストがコマンドの呼び出し内容ではなくコマンド名のみを信頼していること、そしてサンドボックスの外側に完全に存在する権限の高いローカルデーモンがあることです。

「CISOやセキュリティ製品の購買担当者は、エージェント型のIDEやCLIにサンドボックスが搭載されているというだけでは不十分だと認識する必要があります」と研究者らは述べ、サンドボックスの実際の境界線がどこにあるのかを把握しておくことが重要だと付け加えています。

サンドボックスを破らずに脱出する

Pillarは、AI支援開発におけるサンドボックス化についての基本的な理解に一石を投じました。今回実証された攻撃は、カーネルの脆弱性悪用やコンテナからの脱出といった手法ではなく、間接的な仕組みに依存していました。

実演されたすべての攻撃経路において、エージェントはサンドボックス内に留まったまま、後にホスト側の信頼済みアプリケーションが読み込むファイルを作成していました。

こうしたファイルには、ワークスペース設定、自動化スクリプト、IDE設定、そして開発者のワークフローに自然に組み込まれる仮想環境の中身などが含まれます。外部ツールが後になってサンドボックスの外側でこれらのファイルを実行または解釈すると、隔離環境内で生成されたコードが、サンドボックスのルールに違反することなく、実質的にセキュリティ境界を越えてしまうのです。

エージェントごとに異なるサンドボックス脱出手法

Pillarは、複数のAIコーディングツールにわたって、それぞれ異なる手法でこのパターンを実演しました。Antigravityでは、研究者らはmacOSのSeatbelt(サンドボックス)プロファイルにおけるデナイリスト方式の弱点を突き、後でサンドボックスの外側で実行されるVS Codeのタスク設定を悪用しました。一方Cursorでは、エージェントが作成したPython仮想環境や、代替のGitディレクトリ、そして最終的にホスト権限で実行されるワークスペースのフック設定を信頼してしまうことが示されました。

研究者らはまた、Docker Desktopの権限の高いデーモンを経由して、Cursor、Codex CLI、Gemini CLIに共通して影響する共通の脱出経路も発見しました。これにより、サンドボックス化されたエージェントが制限された環境の外側でコマンドを実行できてしまいます。

Codex CLIに関する別の発見では、安全とされていたGitの許可リストを操作することで、リポジトリの設定を変更し、後の段階でコード実行を引き起こせることが分かりました。

エージェント型開発には異なるセキュリティモデルが必要

Pillarは、企業がエージェント型ソフトウェアに向けた新たなセキュリティモデルを必要としていると主張しています。既存のエンドポイント保護は通常、プロセスが実行環境から脱出できるかどうかに焦点を当てています。しかし自律的なエージェントは、他の信頼済みシステムが読み込むコンテンツを継続的に生成し続けるという点で、この前提に挑戦を突きつけています。

研究者らは、実行を引き起こす可能性のあるワークスペース設定を機密資産として扱うこと、エージェントがホスト側の自動化処理を作成・変更する前に明示的な承認を必須とすること、ヘルパープロセスがエージェントの直接実行と同じセキュリティポリシーの下で動作するようにすること、そしてユーザーが作成したファイルとリポジトリまたはエージェントが生成したコンテンツを区別できる来歴情報を保持することを推奨しています。

また、単なるプロセスの呼び出しではなくコマンドの副作用を軸にセキュリティポリシーを設計すること、権限の高いローカルサービスへのアクセスを制限すること、そして開発ワークフロー全体を通じて信頼の受け渡しを監視することも組織に対して助言しています。