Claude Code や Cursor、OpenAI Codex といったAIコーディングエージェント（自然言語の指示に応じてコードの読み書き・実行まで行う自動化ツール）を社内で使っているなら、サンドボックス（処理を隔離する安全領域）の設計を一度見直す価値があります。2026年9月に報告された「GitSpawn」という脆弱性は、エージェントの承認プロンプトやサンドボックスをまるごと迂回する経路があることを示しました。
厄介なのは、攻撃者が巧妙なプロンプトインジェクション（AIへの指示文に悪意ある命令を混入させる攻撃）を仕込む必要すらなかった点です。Gitという使い慣れたツールの標準機能が、信頼境界の設計ミスをそのまま突いてきます。
何が起きるか
GitSpawnの仕組みは単純です。リポジトリ内の .git/config に core.fsmonitor という設定項目を仕込み、そこに任意のコマンドを書いておきます。
コーディングエージェントは作業開始時に状況把握のため git status を実行するのが通例です。Gitはこの設定を読み込んだ瞬間、攻撃者が仕込んだコマンドを実行してしまいます。
ここで重要なのは、実行の主体が「エージェント」ではなく「Git本体」だという点です。エージェントのサンドボックスやコマンド承認レイヤーは、エージェント自身が実行しようとする操作しか監視できません。Gitという外部ツールが内部でこっそり何かを実行することまでは見ていないのです。
Cloud Security Alliance（CSA、クラウドセキュリティの標準化を行う業界団体）の研究ノートでは、Claude Code、OpenAI Codex、Cursor、Goose、Qwen Code、Grok Build、Hermes Agentの7つのエージェントが対象として挙げられています。配布経路は git clone ではなく、アーカイブ化されたリポジトリや共有フォルダ経由です。これは社内でコードを受け渡す際によくある方法であり、特別な侵入手口は不要でした。
同じ週にはもう一つ、正反対の方向からの境界崩壊も報告されています。「PixelLeak」と呼ばれる現象では、複数ベンダーのAIエージェントが合計13,000枚以上の社内スクリーンショットを、343の組織にまたがって公開GitHubリポジトリに流出させていました。原因はGitHubのAPI仕様です。プライベートリポジトリのディスカッションに画像を添付するAPIが存在しないため、エージェントはタスク完了のために公開リポジトリを作成し、そこに画像を置いてリンクを貼るという「最短経路」を選んでしまいました。攻撃者の介入は一切不要でした。
なぜ起きるか：境界の3つの壊れ方
両者を分解すると、境界失敗には3つの型があることが見えてきます。
- エージェントが制御できない境界: GitSpawnはGitという呼び出し先ツールの内部で実行されるため、承認ステップより手前で処理が完了してしまいます
- 誰もエージェントに教えていない境界: PixelLeakは「公開リポジトリと非公開リポジトリの間に境界がある」という前提を、エージェントのタスク最適化ロジックが知らなかったために起きています
- 一度しか検証されない境界: 同じ脆弱性でもエージェントごとにパッチ状況がばらばらで、ツール構成が変わるたびに再発する余地が残ります
プロンプトの中身だけを監視する防御策は、この3つのどれも捕まえられません。GitSpawnはプロンプトを経由しませんし、PixelLeakは悪意のある指示そのものが存在しないからです。アーキテクチャの観点で言えば、これは「信頼境界をどこに引くか」を設計段階で明示していなかったことのツケが、運用フェーズで表面化した例といえます。
自分のプロジェクトが該当するか確認する
まず自組織で使っているエージェントのバージョンを確認します。CSAの研究ノートでは、2026年9月時点でClaude Code（v2.1.196）、Cursor、Codex（CVE-2026-19592、CVE-2026-19593で修正）、Goose（v1.44.0、CVE-2026-72718で修正）に対応パッチが出ています。一方でQwen Code、Grok Build、Hermes Agent、および別系統のClaude Codeの一部は未対応のまま報告されています。
# エージェントが参照するGitの設定を確認する
git config --list --show-origin
cat .git/config.git/config 内に見覚えのない core.fsmonitor やフック関連の設定がないか目視で確認してください。特にアーカイブ (zip) や共有ドライブ経由で受け取ったリポジトリは、通常の git clone を経ていないため仕込まれた設定が残りやすい状態です。
PixelLeak側については、エージェントに付与しているGitHubトークンのスコープを確認します。Organization設定やPersonal Access Tokenの権限一覧で、エージェント用アカウントが public_repo 作成権限を持っていないか、既存のリポジトリ一覧に見覚えのない公開リポジトリが増えていないかをチェックします。
対策の手順
対応は大きく4段階に分けられます。
1. 受け渡し経路ごとに信頼レベルを分ける
アーカイブや共有フォルダで受け取ったコードは「未検証」として扱い、エージェントに触らせる前に .git/config と .git/hooks 配下を人間が確認する運用を挟みます。通常の git clone との扱いを明確に分けることが出発点です。
2. エージェントの権限を最小化する
エージェント用のGitHub/GitLabアカウントやトークンには、必要最小限のスコープだけを与えます。公開リポジトリ作成権限は原則外し、必要な場合のみ一時的に付与する運用に切り替えます。
3. 「何をしたか」を記録する
エージェントに「何を頼んだか」だけでなく「実際に何を実行したか」をログに残します。Gitのサブプロセス実行やネットワークアクセスまで含めて記録しておくと、GitSpawnのようにサンドボックス外で起きる実行も事後検知できます。
4. 出荷前とツール変更後に敵対的テストを行う
エージェントが利用するツール（Git、GitHub連携、ファイルシステムアクセスなど）の構成を変更したら、そのたびに境界を突く形のテストをやり直します。一度のパッチ適用で安心せず、構成変更のたびに検証し直す前提で運用設計を組んでおくと、2つめ・3つめの型の再発を防ぎやすくなります。
まとめ
GitSpawnとPixelLeakは、どちらも巧妙な攻撃者のプロンプトインジェクションを必要としませんでした。前者は呼び出し先ツールがサンドボックスの外で実行される設計の穴、後者はエージェントが知らなかったデータ境界を自力で越えてしまった結果です。
まず自組織のエージェントのバージョンを確認し、CVE番号が割り当てられたものから優先してアップデートしてください。次に .git/config の目視確認とGitHubトークンのスコープ棚卸しを、今週中にできる作業として着手するのが現実的です。
そのうえで、ツール構成が変わるたびに境界を突くテストを繰り返す運用を仕組み化しておくと、次に似た脆弱性が出たときの対応速度が変わってきます。