エージェントはサンドボックスから出なかった

コーディングエージェントがサンドボックスの中で動くのは、無謀なことをした とき——そしてそれは必ず起きる。一日中信頼できないテキストを読み、その大半を 信じてしまうからだ——被害がサンドボックスの壁で止まるようにするためだ。それが 約束である。2026年7月20日、Pillar Security はその約束が破れる7つの方法を、最も使われているエージェントのうち4つ——Cursor、 OpenAI の Codex CLI、Google の Gemini CLI、Antigravity——にわたって公開した。 BleepingComputer が同じ週にこれを報じた。

驚くべき数字は7ではない。7つに共通するのはこうだ。研究者自身の言葉で言えば、 「ほぼすべての事例で、エージェントはサンドボックスを直接破る必要はなかった。 サンドボックスの外にある信頼されたコンポーネントが、後で実行・読み込み・ スキャン、あるいは安全とみなすものを書けばよかっただけだ」。

手口——中にとどまり、ファイルを書き、ホストに実行させる

コーディングエージェントのサンドボックスが実際に何を囲っているかを考えて みよう。それはエージェントのプロセス——モデルの判断を実行するもの——を 囲っている。エージェントのファイルは囲っていない。仕事そのものがファイルを 書くことだからだ。ソース、設定、ビルドスクリプト。それらのファイルは、あなたの 他のツールが読むのと同じディスクに落ちる。そして、あなたの他のツールは サンドボックスの中にいない。エディタの Python 拡張はサンドボックスの中に いない。あなたの git もサンドボックスの中にいない。Docker デーモンも サンドボックスの中にいない。それらはディスク上にあるものを信頼する。つい 最近まで、そのディスクに書き込むのはあなただけだったからだ。

だからエージェントは壁に触れない。書いてよいまさにその場所にファイルを書き、 反対側の何かがそれを読むのを待つ。Pillar の7つの脱出は、その同じ一手の7つの バージョンだ。

Antigravity は同じ形のものをさらに2つ加えた——ある事例を見落とした macOS Seatbelt の拒否リストと、エージェントが書き、IDE が後で自ら実行した VS Code のタスク設定だ。どちらも実行はより難しいと評価されたが、残りと韻を踏んで いる。

なぜ一つずつ修正しても形は塞がらないのか

これらはどれも修正を受けたし、良い修正だ。Cursor は 3.0.0 を、Codex CLI は 0.95.0 を出し、Docker ソケットはロックダウンされた。これらのツールを使って いるなら、更新すべきだ。しかし、ここでの修正が何をしなければならないかを見て ほしい。エージェントが書けて、かつ別のプログラムが指示として扱うファイルを すべて——フック設定、インタプリタのパス、git のメタデータ、タスク定義、lint のルール、来四半期に登場する何であれ——見つけ出し、その一つ一つを特別扱いし なければならない。それは拒否リストであり、Pillar が拒否リストを4つの繰り返される 失敗モードの筆頭に挙げるのは、「『既定で許可』から出発するサンドボックス プロファイルは、OS が公開するあらゆる危険な操作を覚えていなければならない」 からだ。OS は操作を追加し続ける。リストが完成することはない。

より深い理由は、報告書の中の定義のように読める一文だ。「エージェントが システムの将来の入力を書けるなら、そもそもサンドボックスに入れられてなど いなかった」。エージェントのプロセスの周りに引かれた境界は、エージェントが ディスクと信頼されたデーモン群を他のすべてと共有するマシンの上では、間違った ものの周りに引かれている。影響範囲は、と彼らは書く、「エージェントのプロセス ではない。エージェントが書けて、ホストが後で信頼するすべてを含む」。開発者の ノートパソコンでは、それはほぼすべてだ。

Bromure はどこに線を引くか

Bromure Agentic Coding は、危険なファイルを列挙しようとはしないし、フックや 仮想環境やタスクランナーについてサンドボックスに教え込もうともしない。境界を 動かすのだ。各プロファイルのエージェントは、Apple Silicon 上の使い捨ての Linux VM の中で動き、macOS からハイパーバイザ1つ分離れている。このモデルでは、 「サンドボックスの外の信頼されたツール」——エディタの Python 拡張、あなたの git、Docker デーモン、IDE のタスクランナー——は権限の壁の反対側にいるのでは ない。ハイパーバイザの反対側にいて、VM のディスクをまったく読まない。

それがすべての違いだ。Pillar の手口は、同じ場所に2つのものを必要とする。 エージェントが書けるディスクと、そのディスクを読む信頼されたプログラムだ。 エージェントのディスクを VM の中に置けば、2つめは消える。エージェントはフック 設定を書き、仮想環境のインタプリタをすり替え、タスク定義を仕込むことができる ——7つの脱出すべてのファイルを——が、そのファイルシステムを監視して拾い上げる 非サンドボックスなホストツールは存在しない。実行されるものは箱の中で、使い捨て の ubuntu ユーザーとして、何も持たないマシンの中で実行される。

脱出には名指しておく価値のある後半がある。Bromure はそれにも答えるからだ。 エージェントが書いたファイルが、実際に VM の中のツールによって実行されたと しよう——コードを実行する目的は、たいてい何かを盗むか、どこかに到達することだ。 ここではどちらも行き止まりだ。コードは、その旅を割に合わせる認証情報 ——Anthropic の鍵、AWS の鍵、GitHub のトークン——を狙い、囮を見つける。ホスト上 の認証情報ブローカーが brm_… のような プレースホルダ、合成された kubeconfig、使い捨ての SSH 鍵を注入し、本物の値を ネットワーク境界でのみ、あなたがすでに承認した宛先へのリクエストに対してだけ 差し替える。そして外向きの一歩——戦利品の持ち出しや、第二のホストへの到達 ——はホストのプロキシを越える。そこでは真の宛先が出ていく途中で制限され、 プロファイルが前面に立てるクラウドや git の API に対する破壊的な操作 ——delete、drop、terminate——は、エージェントがどう言いくるめられたとしても、 それを拒める防護柵に突き当たる。

そのすべての手前に、これらの脱出を根元でとらえる層がある。どれも injection ——エージェントが読むファイルやツールの結果に含まれる悪意ある指示で、そもそも 汚染された設定を書けと命じるもの——から始まる。Bromure は、モデルがそれに 基づいて動く前に、その信頼できないコンテンツをデバイス上の インジェクション検出器で採点する。 その大半を捕らえるが、十分に目新しいペイロードは1つの分類器をすり抜けることが ある。まさにそれこそが、それを使い捨ての箱の代わりにではなく、その前に置く 理由だ。

境界は間違ったものの周りにあった

Pillar の一週間から残る教訓は、修正すべき7つのバグのリストではない。 エージェントのプロセスをサンドボックスに入れることは——そのプロセスがディスクと 信頼されたツール群を、あなたの持つすべてと共有するマシンの上では——線を間違った ものの周りに引く、ということだ。エージェントは、すでに外にある何かの入力を 書けるのなら、脱出する必要などない。

既知のファイルを修正するのは正しく、そうすべきだ。しかしそれは、ホストツールが 信頼すると決める未来のあらゆる形式に対する競争であり、その競争は終わらない。 Bromure Agentic Coding はそこから降りる。エージェントは汚染されたファイルを書く よう言いくるめられると想定し、あるツールがそれを読むとき、そのツールが ——あなたの鍵を抱えたノートパソコンではなく——秘密には囮を、回線には関所を備えた 使い捨ての箱の中にいるようにする。それが、絶えず修正し続けなければならない壁と、 書いても読み手のいない、一段下に引かれた線との違いだ。 インストールして、あなたのものではない——失っても構わない マシンをエージェントに与えよう。