trust handoff とは、エージェントが生成・変更・指定した入力を、サンドボックス外のより高い権限を持つコンポーネントが信頼して処理する受け渡し経路。設定ファイル、Git の実行経路、許可済みコマンド、ローカルの特権デーモンなどが該当する。
多くのケースでは、サンドボックスのプロセス分離もファイルシステムの制限も動いたまま、開発者のマシン上でコマンドが走りました。セキュリティ企業 Pillar Security が2026年7月20日に公開したレポート「The Week of Sandbox Escapes」は、報告した7件の findings について「ほとんどのケースで、エージェントはサンドボックスを直接破る必要がなかった」と述べています。多くは、エージェントが許可された場所に書いたものを、箱の外にいる信頼されたコンポーネントが後から読んで実行した形。ただし全件がその型ではなく、Antigravity の macOS Seatbelt の件のようにサンドボックスの外での実行そのものが成立したケースも含まれます。この記事では、その機構と4つの失敗モード、製品ごとの差、ベンダー対応の分かれ方、そして手元の環境で今日引き直せる信頼境界までを通しで扱います。
- Pillar Security が Cursor・OpenAI Codex・Gemini CLI・Antigravity で確認した7件の多くは、サンドボックスの実装そのものを破壊するのではなく、箱の外のコンポーネントや許可済み経路を使って境界を越えている。一方で Antigravity の Seatbelt 件のように、サンドボックス外での実行が成立したケースも含まれる
- 共通する成立条件は、エージェントが攻撃者の影響下にある指示を処理し、該当する機能や環境条件が有効になっていること。指示の運び手は README・issue・依存パッケージ・diff のほか、エージェントが読む外部ドキュメントや直接のプロンプトもありうる
- 対応は finding ごとに異なる（2026年7月時点）。Cursor は .claude hook 件と Git メタデータ件を 3.0.0、venv 件を 3.1.2 で修正。OpenAI は Codex CLI v0.95.0 で修正し high severity の報奨金。Antigravity の2件は、Google が “Other valid security vulnerabilities” に分類し悪用難度を理由にダウングレードしたと Pillar Security が報告している
何が確認されたのか — 4製品・7件の到達経路
Pillar Security は数か月をかけて、AIコーディングエージェント4製品それぞれで、セキュリティ境界を越える手法を確認しました。対象は Cursor、OpenAI の Codex、Google の Gemini CLI、そして Google の Antigravity。findings は7件で、これが4つの失敗モードに分類されています。BleepingComputer をはじめとする技術メディアが同レポートを報じました。
先に呼称を1つ整理しておきます。Codex は OpenAI の製品。二次報道の一部に別社製と読める記述がありますが、一次側の表記は “OpenAI’s Codex” です。CLI 版が Codex CLI で、今回 findings のうち1件はこの CLI に紐づいています。
読者が最初に知りたいのは「で、危ないのか」という一点でしょう。答えは条件付きです。共通する前提は、エージェントが攻撃者の影響下にある指示を処理し、該当する機能や環境条件が有効になっていること。悪意ある指示は README、issue、依存パッケージ、diff といった「読み込まれるテキスト」に仕込まれます。ただし運び手はリポジトリだけではありません。エージェントが参照する外部ドキュメントや依存関係のメタデータ、さらには直接のプロンプトも起点になりえます。自分のリポジトリで作業していれば無関係、とは言い切れないのはこのためです。
もう1つ押さえておきたいのが、7件が単独の実装ミスの寄せ集めではないという点です。同じ Docker ソケット経由の経路が Codex・Cursor・Gemini CLI の3製品で同時に成立しています。3社が同じバグを書いたのではなく、3製品が同じ構成の上で動いていた、というほうが実態に近い。だからこそ、製品を1つ乗り換えれば済む話にはなりません。
対応状況も一様ではありませんでした。Cursor は .claude hook 件と Git メタデータ件を 3.0.0、venv 件を 3.1.2 で修正しています。OpenAI は Codex CLI v0.95.0 で修正して high severity の報奨金を支払いました。一方で Google は Antigravity の2件を「その他の有効なセキュリティ脆弱性」に分類して深刻度を下げたと報告されています。ただし2件の状況は同じではなく、片方には関連する緩和策が公式 changelog に出ています。ここが今回いちばん読み解きが必要な部分で、後半で扱います。
箱を壊さずに越える：trust handoff という機構
AIコーディングエージェントのサンドボックス（エージェントの実行を隔離し、ホスト側への影響を制限する仕組み）は、おおむね同じ前提で作られています。多くの製品はワークスペース内を主な書き込み許可領域とし、その外側にあるホストを保護すべき領域として線を引いています。.git や .vscode など一部の敏感なパスに追加の制限を設けている製品もあります。この線引き自体は素直で、実際に「ホストのファイルを直接壊す」類の事故は防げています。
問題は、プロジェクトフォルダの中身が不活性ではないこと。そこに置かれたファイルは、サンドボックスの外にいる別のプロセスから読まれます。Python 拡張がインタプリタを解決するとき、Git 統合がリポジトリを走査するとき、タスクランナーが設定を読むとき、Docker Desktop がローカルソケットで指示を受けるとき。これらはどれもサンドボックスの外側で、開発者の権限で動く信頼されたコンポーネントです。
つまり経路はこうなります。エージェントは許可された場所にファイルを書く。ここまでは完全に規定どおり。その後、箱の外にいるコンポーネントがそのファイルを読み、内容に従って動く。書き込みと実行のあいだで信頼が受け渡され、受け取った側は「誰がこれを書いたのか」を知らないまま実行する。Pillar Security はこの受け渡し（trust handoff）を、classic sandbox escape とは別の問題として整理しています。ここでいう受け渡しは、書かれたファイルが後から実行されることだけを指すわけではありません。エージェントが生成・変更・指定した入力を、より高い権限を持つ別のコンポーネントが信頼して処理する境界すべてが対象で、許可済みコマンドに渡される引数や、ローカルの特権デーモンへ届く要求も含まれます。
これらのサンドボックスは、プロジェクトフォルダの内側にいるエージェントを信頼し、外側にあるホストを保護する。しかし、そのフォルダ内のファイルは不活性ではない。（Pillar Security「The Week of Sandbox Escapes」の要旨より要約・翻訳 / https://www.pillar.security/blog/the-week-of-sandbox-escapes ）
この構図が厄介なのは、どのコンポーネントも単体では正しく動いている点。サンドボックスは書き込みを許可された場所への書き込みを許可した。Python 拡張はワークスペースの設定に従ってインタプリタを起動した。Git は core.fsmonitor に指定された外部ヘルパーを、リポジトリの走査時に実行した。どれも仕様どおりで、この型のケースには「破られた」箇所がありません。
典型的な起点はプロンプトインジェクション（README・issue・依存関係・diff）
一連の経路の入口になるのが、間接的なプロンプトインジェクション（外部データに混ぜ込まれた指示をLLMが指示として解釈してしまう攻撃）です。エージェントは開発者の入力だけを読むわけではありません。リポジトリの README を読み、issue の本文を読み、依存パッケージのメタデータを読み、diff を読む。そのどこかに「このファイルをこう書き換えろ」という指示が自然な文章として埋め込まれていれば、エージェントは作業の一環としてそれを実行しうる。
ワークスペース設定型では、エージェントが作成・変更したファイルそのものが、その時点で最終的なペイロードを実行するわけではありません。ただの設定ファイル、ただのシンボリックリンク、ただのメタデータ。危険なのは、後からサンドボックス外の拡張機能やフックエンジンが、その内容を実行指示として解釈する点です。攻撃者から見れば、解釈してくれる相手は箱の外に何人でもいる、という状況。なお他の型では、エージェント自身がコマンドを実行する経路もあります。
「サンドボックス内で動く」が意味しないこと
「エージェントはサンドボックスの中で動いています」という説明が意味するのは、エージェントのプロセス自身がホストへ直接手を出せないこと。それ以上ではありません。具体的に守られていないのは次の3点です。
サンドボックス内に書かれたファイルの内容は制限されていません。書き込み先のパスが許可されていれば、中身が設定なのかコードなのかを箱は区別しない。次に、そのファイルを誰が後で読むかも制御されていない。エディタの拡張機能もローカルのデーモンも、サンドボックスの管轄外で動きます。最後に、書き込みと実行のあいだの時間差も見ていない。エージェントのセッションが終わった後で、開発者が何気なくエディタを再起動した瞬間に走る、という形も成立します。
サンドボックスは「エージェントがホストを直接壊すこと」を防ぐ道具であって、「エージェントがプロジェクト内の資源を使って外部へ働きかけること」を防ぐ道具ではない。この区別は、ワークスペース設定型の4件に共通する土台です。残る3件はそれぞれ別の経路で境界を越えました。Seatbelt はプロファイルの許可漏れ、GitPwned は許可済みコマンドの引数と副作用、Docker はサンドボックス外の特権デーモンです。
7つの findings と影響製品を一覧で押さえる
個別の findings を整理します。以下の表に出てくるバージョン番号・CVE 番号は本記事執筆時点（2026年7月）で確認できた値であり、追加の修正や再採番が入る可能性があります。手元の環境で対応要否を判断するときは、各ベンダーの公式リリースノートおよびセキュリティアドバイザリで最新の状態を確認してください。この注記は記事全体で1回だけ置き、以降の章では繰り返しません。
| finding | 機構 | 影響製品 | 対応状況 |
|---|---|---|---|
| 特権コンテナ経由の到達 | サンドボックス外の Docker デーモンを使って特権コンテナを起動し、ホスト側の領域へ到達する | Codex / Cursor / Gemini CLI | 扱いは製品ごとに異なる。Cursor は GHSA-v4xv-rqh3-w9mc（影響 <3.0.0）だが Patched versions 欄は None |
| venv インタプリタの差し替え | 仮想環境のインタプリタを書き換え、Python 拡張が discovery 時に起動 | Cursor | GHSA-p9g2-cr55-cw9c（High / CVE なし）、3.1.2 で修正 |
| Git メタデータ経由の間接実行 | fsmonitor 設定を通じて Git 操作時にコマンドが走る | Cursor | Cursor 3.0.0 で修正。Pillar 公開時点で CVE は採番待ち |
| git show の allowlist バイパス（GitPwned） | コマンド名は許可済みでも引数次第で挙動が変わる | Codex CLI | OpenAI が v0.95.0 で修正、high severity として報奨金 |
| .claude hook 設定の非サンドボックス実行 | ワークスペース側が制御できる hook 設定を読み、箱の外でコマンドが走る | Cursor | 3.0.0 で修正（CVE-2026-48124 / GHSA-pc9j-3qc2-95wv） |
| macOS Seatbelt プロファイルのバイパス | denylist 型プロファイルに許可漏れがあり、サンドボックス外での実行が成立 | Antigravity | “Other valid security vulnerabilities” に分類しダウングレードと報告。公式 changelog に該当する修正エントリは見当たらない |
| .vscode task の遅延実行 | タスク定義が後からホスト側で独立に実行される | Antigravity | 同じくダウングレードと報告。一方 Antigravity 2.1.4（2026年6月11日）で .vscode が敏感パス扱いになった |
表を眺めて気づくのは、影響製品の欄が製品ごとにきれいに分かれていないこと。1件目は3製品にまたがり、Cursor にはこの共通件に加えて性質の異なる3件があります。製品の実装品質の順位表として読むと、読み違えます。むしろ「どの部品を共有しているか」で並べ替えたほうが実態に近い。次章でその整理をします。
4つの失敗モードに畳んで理解する
7件を個別に暗記しても、次に出てくる8件目には対応できません。Pillar Security の分類に沿って4類型に畳むと、手元の環境に当てはめて考えられるようになります。
第1類型は、OS の変化に追随できない denylist 型のサンドボックスプロファイル。 禁止したい操作を列挙して塞ぐ方式では、OS 側に新しい API や実行経路が増えるたびに禁止対象を更新する必要があり、追随漏れが生じやすくなります。Antigravity の macOS Seatbelt の件がこれに当たります。
第2類型は、実質的にコードであるワークスペース設定。 .vscode のタスク定義、Python のインタプリタ設定、.git の設定や外部ヘルパーは、見た目は設定でも、読み込んだ側にとっては実行指示です。エージェントがこれらを書き換えられる場所に置いてあると、書き込み権限がそのまま実行権限に化けます。venv 差し替え、fsmonitor 経由、.claude hook、.vscode task の4件が該当。
第3類型は、コマンド名だけを信頼して引数を見ない allowlist。 git のように日常的に使うコマンドを「安全」と登録した瞬間、そのコマンドが持つ全オプションが安全リストに入ります。GitPwned と名付けられた Codex CLI の件がこの形。
第4類型は、箱の外にある特権ローカルデーモン。 Docker Desktop のように、ローカルソケットで指示を受けて高い権限で動くプロセスが、サンドボックスの外に常駐している。エージェントからそのソケットに到達できるなら、箱の中身がどれだけ厳格でも意味が薄れます。3製品にまたがった件がこれ。
4類型が共通して壊しているもの
4つは表面上バラバラですが、崩したものは1つです。エージェントの影響範囲を、サンドボックス内のプロセスだけに限定できるという想定。実際にはファイル、コマンドの引数、ローカルデーモンへの要求といった経路を通って、エージェントの影響は箱の外へ受け渡されました。
特にワークスペース設定型では、実行する側がそのファイルを誰が書いたのかを知りません。エディタの Python 拡張は、ワークスペースのインタプリタ設定を読むとき、それを書いたのが開発者なのか、外部リポジトリの README に埋め込まれた指示に従ったエージェントなのかを区別しません。Git は fsmonitor の設定値の出所を問いません。Docker のデーモンは、ソケットに来た指示が人間の入力か自動生成かを見ない。どのコンポーネントも、ローカルのファイルシステムに書かれている＝開発者本人の意思、という前提で作られています。
この前提は以前から完全ではありませんでした。エディタもビルドツールもパッケージマネージャーも、以前からファイルを書き換えています。問題が大きくなったのは、外部テキストを判断材料にしながら、開発者のローカル環境内で広い範囲のファイルや設定を自動で変更する主体が加わったからです。7件はその変化が具体的に何を意味するかを、4製品で実演した記録として読めます。
Docker ソケットという最短経路
3製品で同時に成立した件を深掘りします。Docker Desktop をはじめとするコンテナ管理ツールは、ローカルソケット（/var/run/docker.sock など）を通じて指示を受け取り、高い権限でコンテナを操作します。このデーモンはサンドボックスの外側にいて、ソケットに届いた指示を素直に実行する。
ここで成立する構図は単純です。エージェントの実行環境からデーモンに到達できるなら、サンドボックスの中の制約を1つも破らずに、高い権限でコンテナを起動できてしまう。Pillar Security が macOS 上で実証した経路は、サンドボックス内から Docker CLI を実行し、ネットワーク越しに取得したルートファイルシステムを docker import して --privileged コンテナを起動、Docker Desktop の VM 内で virtiofs0 をマウントして macOS ユーザーのホームディレクトリへ読み書きする、という流れでした。エージェント側は、サンドボックス内で許可されたネットワークアクセスと Docker CLI の操作を連鎖させただけで、ホストの保護領域へ直接書き込んだわけではありません。
この件が Codex・Cursor・Gemini CLI の3製品で同時に成立した事実が示すのは、特定製品の実装ミスではないということ。3製品はいずれも、開発者マシン上でよくある構成——Docker Desktop が動いていて、そこへ到達できる位置にエージェントがいる——の上で動いていました。製品側が塞ぐ範囲と、環境側が用意してしまう経路の境目に落ちた形です。ただし成立条件は製品設定・Docker Desktop・ネットワーク許可・ローカル環境の組み合わせで決まるため、対応も3社で揃っていません。Cursor の GHSA は影響を <3.0.0 としつつ Patched versions 欄が None のままで、Pillar 側の「修正された」という説明とメタデータが噛み合っていない点にも注意が要ります。
docker.sock をマウントする構成（いわゆる Docker-outside-of-Docker）は、コンテナ内から見れば「ホストの Docker を自由に操作できる状態」です。エージェントをそのコンテナ内で動かしている場合、コンテナによる隔離は事実上効いていません。CI やビルドの都合でこの構成を採っている環境は珍しくないため、エージェントを導入する前に一度確認してください。 手元の構成を確認するコマンドは以下。ソケットが誰から見えているか、コンテナ内にマウントされていないかを見ます。ただし今回実証された経路は Docker CLI とデーモンの組み合わせで成立するため、docker.sock のマウント有無だけでは判定しきれません。エージェントから Docker を操作できる状態かどうか、という広い観点で見てください。
# ホスト側: ソケットの所有者とパーミッションを確認
ls -l /var/run/docker.sock
# 開発コンテナ側: ソケットがマウントされていないか確認
docker inspect <container-name> --format '{{json .Mounts}}'
# 現在の docker context（どのデーモンに繋がっているか）
docker context ls
# その context が参照している実際のエンドポイント
docker context inspect --format '{{json .Endpoints.docker.Host}}'なお、AIコーディング支援ツールを動かすマシン側のスペック要件そのものは別軸の話で、姉妹サイトのGitHub Copilot 推奨スペック｜AI推論用GPUは通常不要・効くRAMと固有の注意点で整理しています。推論をクラウド側に投げる構成では GPU より RAM が効くという話で、今回のセキュリティ論点とは独立して読めます。
対処の方向は、権限を削るより到達経路を切るほうが確実です。エージェントを動かす環境からソケットへのパスを見せない。どうしてもコンテナ操作が必要なら、ソケット直結ではなく権限を絞ったプロキシ越しにする。Docker デーモンへのアクセスは非常に強い権限を与えます。少なくとも今回実証された macOS 構成では、特権コンテナと VirtioFS を介してユーザーのホームディレクトリへ読み書きできました。
ワークスペース設定が実行トリガーになるとき
7件のうち4件は、ワークスペース内の設定や実行可能ファイルが、後からホスト側に解釈される型です。Pillar Security のレポートもこの4件を「Workspace Config Is Often Code」としてまとめています。設定ファイルは設定ではなく、読み込む側にとってはコード。エディタの拡張機能は、設定を「読むだけ」のつもりで実行している。以下では3件を扱い、残る .claude hook の件は CVE が採番されているため次章で個別に扱います。
この類型が見つけにくいのは、書き込まれた瞬間には何も起きないから。ファイルが増えただけの状態で、プロセスは静かなまま。実行のトリガーは、エディタの再起動だったり、Git の操作だったり、拡張機能の初期化だったりします。エージェントのログには、設定ファイルの作成・変更や、そのための準備コマンドは残ります。ただし後から拡張機能が実行した最終ペイロードまでは記録されません。書き込みと実行の主体が分かれるぶん、因果関係を追いにくくなります。
venv と Python 拡張（Cursor）
Python の仮想環境（venv）は、プロジェクト直下に置かれるのが普通です。当然エージェントの書き込み許可範囲に入ります。エディタの Python 拡張は起動時にワークスペースを走査し、使うべきインタプリタを解決して起動する。ここで解決先のインタプリタが差し替えられていれば、拡張機能はそれを疑わずに起動します。
この経路の実行主体はエディタの拡張機能であって、エージェントではありません。だからサンドボックスの外。開発者がプロジェクトを開き直しただけで、条件が揃います。
.git メタデータと fsmonitor（Cursor）
Git には、ファイルシステムの変更監視を外部プロセスに委ねる core.fsmonitor という設定があります。ここに指定された対象は、Git がステータスを確認するタイミングで呼ばれる。git status を打つ、エディタが変更を検出する、といった日常動作が起動条件になります。
.git ディレクトリはプロジェクトフォルダの中にあり、多くのサンドボックス設定で書き込み可能な領域に含まれています。外部から取得したリポジトリを開く前に、ローカル設定を確認する習慣をつけておくと、この種の仕込みは目視で拾えます。
# クローンしたリポジトリのローカル設定を確認する
git config --list --local
# 特に外部プロセスを呼びうる設定を個別に確認
git config --get core.fsmonitor
git config --get core.hooksPathgit clone で持ってきたリポジトリの .git/config は本来クリーンですが、その後にエージェントが触れば話は変わります。エージェント作業後の差分を確認するときは、追跡対象のソースコードだけでなく、追跡されない設定領域にも目を向けてください。
.vscode task の遅延実行（Antigravity）
.vscode/tasks.json に代表されるタスク定義は、エディタがワークスペースを開いた時点で読み込まれ、条件によっては自動で走ります。エージェントがこのファイルを書ける状態にあり、なおかつエディタ本体がサンドボックスの外で動いているなら、書き込みと実行のあいだにいくらでも時間差を置けます。
この時間差が、検知を難しくします。エージェントの実行ログを追っても、書き込みイベントとして記録されるだけ。実際にコマンドが走るのは、開発者が翌日プロジェクトを開いたときかもしれません。因果関係の紐付けが人間の記憶を超える距離まで離れる、という点で第2類型のなかでも扱いが厄介な部類です。
4件に共通する回避方針は同じです。設定ファイルへの書き込みを、ソースコードへの書き込みと同じ扱いにしない。エージェントに .vscode・.git・venv・各種の設定や外部ヘルパーの書き込みを許すなら、その差分は毎回目視で確認する。既知の実行可能な設定領域を書き込み禁止にすれば攻撃面は大きく減らせますが、固定のパス名を並べた denylist だけでは足りません。Git のディレクトリは参照先を別の場所へ差し替えられますし、仮想環境の実行ファイルや、エージェントが新規に作った自動化設定も同じ性質を持ちます。パス名の一致ではなく、その設定を誰が書いたのかと、読んだ側が何を起動しうるのかで制御するのが本筋です。エージェントがこれらを触る必要は、日常的な開発作業ではそれほど多くありません。
コマンド名を信頼し、引数を見ない allowlist
第3の類型が、コマンド名だけを見た allowlist（明示的に許可したものだけを通すリスト）。Pillar Security が「GitPwned」と名付けた finding は、OpenAI の Codex CLI で git show が安全なコマンドとして扱われていた点を突いています。
git show はコミットの内容を表示するだけの読み取り系コマンド。名前だけ見れば無害です。ところが git show には、出力を指定したファイルへ書き込む --output があります。さらに --format で出力内容を制御できるため、外部 diff コマンドを指定した設定を .git/config へ書き込めてしまう。その後にユーザーが git diff を実行した時点で、設定された外部コマンドが起動します。許可判定がコマンド名の一致で終わっていれば、この引数と後続の副作用は捉えられません。
ALLOWED="git ls cat"
cmd=$(echo "$user_cmd" | awk '{print $1" "$2}')※ 許可判定の考え方を単純化した例であり、Codex CLI の実装コードではありません。
コマンド名だけの allowlist では十分な防御になりません。実行を許すかどうかは、コマンド名ではなく「そのプロセスが最終的に何を起動しうるか」で決まります。引数・環境変数・作業ディレクトリのリポジトリ設定まで含めて評価しないと、許可リストは名前の照合表にしかなりません。
OpenAI はこの件を Codex CLI v0.95.0 で修正し、high severity として報奨金を支払ったと Pillar Security の公開レポートに記載されています。修正が入った以上、読者側の作業は「使っているバージョンが v0.95.0 以降か」の確認から。
.claude hook 設定と CVE-2026-48124（Cursor）
7件のうち唯一 CVE 番号が採番されたのが、ワークスペース側が制御できる hook 設定を読み込み、サンドボックス外でコマンドが実行された件。Cursor に紐づく finding で、CVE-2026-48124 / GHSA-pc9j-3qc2-95wv として登録され、Cursor 3.0.0 で修正されています。
ここは誤読が起きやすい箇所です。対象は Cursor が .claude の hook 設定を読む挙動であり、Claude Code 側の脆弱性ではありません。設定ファイルのフォーマットが共通化していくと、「誰が書いた設定を、誰が実行するか」の対応関係が製品をまたいでねじれます。ファイル形式の互換は利便性を上げますが、信頼境界は形式についてこない。
なお、本研究の検証対象は Cursor・OpenAI Codex・Google Gemini CLI・Google Antigravity の4製品です。Anthropic 製品は対象に含まれていません。検証されていないことと安全であることは別なので、「対象外だから問題ない」とは読み替えないでください。
Hook は防御層か、攻撃面か
Hook をガードレールとして使う運用は、当サイトでも Claude Code を安全に自律実行する手順の記事で扱っています。危険なコマンドを実行前に止める仕組みですね。今回の finding は、その hook 設定自体が実行トリガーになりうることを示しました。
矛盾ではありません。分岐点はリポジトリの持ち主ではなく、その設定をエージェントが変更できるか、変更時に承認が入るかです。Cursor の GHSA も、悪意あるワークスペースやエージェントが作成したファイルによって hook を設定できた点を挙げています。
- ユーザーが管理し、エージェントからは書き込めない、または変更時に承認が必要な hook 設定 → 防御層として使える
- 外部リポジトリに含まれる、あるいはエージェントが承認なしに作成・変更できる hook 設定 → 攻撃面になりうる
自分のリポジトリであっても、エージェントが .claude/settings.local.json を書き換えられるなら後者です。同じ機構が、変更権限と承認の有無で向きを反転させます。Hook を「安全機能」として一律に信頼するのではなく、その設定を誰がいつ変更できるかを確認する運用に切り替えることで、この反転のリスクを下げられます。
- その hook 設定は、エージェントから書き込めない場所にあるか。書ける場合、変更時に承認が入るか
- 外部リポジトリを clone した直後、hook 設定を含む差分を目視したか
- エージェントに作業させた後も、hook 設定の差分を確認しているか
macOS Seatbelt の denylist 型プロファイル
第1の類型が、禁止事項を列挙する denylist 型のサンドボックスプロファイル。Antigravity で確認された macOS Seatbelt のバイパスがこれに当たります。
denylist 方式の弱点は構造的です。禁止する対象を列挙する以上、列挙されていない経路は通る。OS がアップデートで新しい API やパスを追加すれば、プロファイルは自動では追随しません。攻撃側は新設された経路を探せばよく、防御側は既知の穴を塞ぎ続ける非対称なレースになります。
対して allowlist 型は、明示的に許可した経路以外をすべて落とす設計。運用の手間は増えますが、OS の変化に対して安全側に倒れます。自分のサンドボックス設定を見直すときは、「何を禁止しているか」ではなく「何を許可しているか」が書かれているかを見てください。前者しか書かれていないなら、OS の機能追加に継続的に追随する必要があり、許可漏れが生じやすい構えだと考えてください。
なお、AI コーディングを快適に回すための開発マシン側の考え方（GPU が要るのか、RAM はどこまで効くのか）は、姉妹サイトのGitHub Copilot 推奨スペック｜AI推論用GPUは通常不要・効くRAMと固有の注意点で整理されています。
ベンダー対応の差をどう読むか
同じ研究から出た findings でも、ベンダーの反応は割れました。
| ベンダー | 対応 | 備考 |
|---|---|---|
| Cursor | 3.0.0 および 3.1.2 で修正 | hook 件は CVE-2026-48124 / GHSA-pc9j-3qc2-95wv、venv 件は GHSA-p9g2-cr55-cw9c（3.1.2） |
| OpenAI | Codex CLI v0.95.0 で修正 | high severity として報奨金を支払い |
| 2件で状況が異なる | いずれも “Other valid security vulnerabilities” に分類しダウングレードと報告。.vscode 側は 2.1.4 で関連する制限が追加された |
Pillar Security が掲載した Google 側の回答では、該当2件は “Other valid security vulnerabilities” に分類され、深刻度がダウングレードされています。理由として示されたのは、悪用にはソーシャルエンジニアリング、または間接的なプロンプトインジェクションを含むリポジトリをユーザーが信頼することが必要で、実行が難しいという点。報告そのものの質は高く評価されたとも記録されています。
どちらの立場にも筋は通ります。読者にとっての含意は、優劣ではなく「深刻度の物差しがベンダーごとに違う」という事実。同じ研究で報告された類似の境界越えでも、ある製品では CVE が採番されて製品側で修正され、別の製品では運用上の注意事項として扱われます。製品を選ぶとき、機能とベンチマークだけでなく、脆弱性報告への対応姿勢も見ておく価値があるのはこのためです。
信頼境界を引き直す — 明日からの構成変更
7件を踏まえて、手元の環境で見直せる点を優先順に整理します。
まず、サンドボックスを唯一の防御線にしないこと。多くの経路は箱の内側で完結したまま外へ到達し、プロファイル自体に許可漏れがあれば箱の外での実行も成立します。強度を上げるだけでは経路は残る。二層目として、信頼できない入力を扱う作業自体を隔離してください。
次に、ワークスペース内の設定領域を信頼境界として扱うこと。.vscode・.claude・venv・.git への書き込みは、ソースコードの編集とは別カテゴリの操作です。エージェントに許すなら差分を毎回確認し、必要なければ書き込み禁止にする。これで第2類型の既知の攻撃面は大きく減らせますが、固定パス名の列挙だけでは塞ぎ切れない点は前章のとおりです。
さらに、エージェントの実行環境から特権デーモンへ到達できる経路を潰すこと。開発コンテナへの docker.sock 直接マウントが代表例で、コンテナから Docker デーモンへ非常に強い操作権限を渡すことになります。今回検証された macOS 構成では、特権コンテナと VirtioFS を介してユーザーのホームディレクトリまで到達できました。
最後に、製品選定の軸に脆弱性対応姿勢を加える。修正の速さと分類の基準は、長期利用では機能差より効いてきます。
まとめ
分かれ目は、エージェントに処理させる入力を信頼できるかどうかだけではありません。サンドボックスのポリシー設計、許可済みコマンドの扱い、ワークスペース設定の出所、特権デーモンへの到達性まで含めて、エージェントから外部コンポーネントへ信頼が渡る経路の全体を見る必要があります。7件はいずれもサンドボックスが有効な状態で成立しています。エージェントプロセスの隔離だけを厳しくしても、外側に信頼経路が残っていれば防げません。起点になるのは外部から持ってきたリポジトリだけではなく、エージェントが読む外部ドキュメントや依存関係、直接のプロンプトも含まれます。
手元で動かす順序は3つ。エージェントの実行環境から docker.sock が見えていないかを確認する。.vscode・.claude・.git・venv への書き込みをソースコード編集と別カテゴリに切り分け、不要なら禁止、許すなら差分を毎回目視する。サンドボックス設定は「何を禁止しているか」ではなく「何を許可しているか」で書かれているかを見る。ここまでで既知の攻撃面は大きく減らせます。あわせてバージョンを確認します。venv・.claude hook・Git メタデータの3件については、Cursor が 3.1.2 以降であること。Docker 件は Pillar Security が修正済みと報告する一方で GHSA の Patched versions 欄は None のままなので、Cursor 公式の最新情報を個別に確認してください。Codex CLI の GitPwned は v0.95.0 で修正されています。Antigravity は2件で状況が異なります。Seatbelt 件は公式 changelog に該当する修正エントリを確認できません。.vscode 件については 2.1.4（2026年6月11日）で .vscode と .cache が敏感パスに追加され、エージェントがアクセスする前に明示的な確認を求める挙動になりました。ただし Google はこれを当該 finding の完全な修正とは明記していないため、最新版の挙動と設定を確認してください。
よくある質問
Q. 検証対象に入っていない製品を使っていれば安全ですか？
そうは読めません。今回の検証対象は Cursor・OpenAI Codex・Google Gemini CLI・Google Antigravity の4製品で、Anthropic 製品は含まれていません。検証されていないことと、同じ経路が成立しないことは別です。一部は製品固有の実装・ポリシー上の脆弱性で、実際に複数件が製品側で修正され GHSA や CVE として扱われています。ただしその背後にある4つの失敗モードは他製品でも再発しうるため、検証対象外の製品も安全とは判断できません。同じ観点で確認してください。
Q. Docker を使っていなければ関係ない話ですか？
Docker を使っていなければ、今回報告された特権コンテナ経由の finding は成立しません。ただし失敗モードとしての「箱の外にある特権ローカルデーモン」は残ります。パッケージマネージャー、クラウド CLI、言語サーバー、ビルドデーモン、ローカル DB なども、エージェントから到達できれば同じ位置に立ちます。残る3類型も Docker と無関係に成立します。ワークスペース設定型（venv のインタプリタ差し替え、Git の fsmonitor 設定、.claude hook、.vscode のタスク定義）は、エディタや Git の通常動作が実行トリガーです。コマンド名だけを見る allowlist は Git 操作が、denylist 型の Seatbelt プロファイルは列挙から漏れた OS 機能が入口になります。
Q. 別の製品に乗り換えれば避けられますか？
難しいところです。Docker ソケット経由の経路は Codex・Cursor・Gemini CLI の3製品で同時に成立しました。3社が同じバグを書いたのではなく、開発者マシン上でよくある同じ構成の上で動いていたためです。製品の入れ替えより、環境側の到達経路を切るほうが効果があります。
Q. エージェントの実行ログを見れば気づけますか？
findings の型によります。ワークスペース設定型の4件は特に気づきにくい部類です。エージェント側にはファイルの作成・変更や、そのための準備コマンドしか残らず、後から別プロセスが実行した最終ペイロードとの因果が見えにくくなります。実際にコマンドが走るのはエディタの再起動時や Git 操作時で、翌日プロジェクトを開いたタイミングになることもある。書き込みと実行のあいだの時間差が、因果の紐付けを難しくします。一方で Docker 経由の件や GitPwned では、エージェント自身が docker import や git show --output といったコマンドを実行するため、不審な引数がエージェントの実行履歴に残る可能性があります。
