私たちはサイバーセキュリティにおけるAIを、ひとつの角度から読むことに慣れています。攻撃者がエージェントを使ってより速く動く、という角度です。もうひとつの角度のほうが御社にとって重要なのに、注目はずっと少ないのが現状です。御社の開発者マシンで動かしているエージェントそのものが、新たな攻撃対象領域なのです。二か月の間に、三つの独立した研究グループが、いずれも同じ方向を指す調査結果を公表しました。

これらの事例に共通するのは、モデルの欠陥でも誤った回答でもありません。エージェントはサンドボックスから一度も抜け出しておらず、ルールにも違反していません。起きたのは、エージェントがプロジェクト内のファイルを読み書きし、その後サンドボックスの外で動く信頼されたツールがそのファイルの内容を実行した、ということです。サンドボックスは持ちこたえました。侵害はその周りを迂回したのです。

仕組み：何年も前からあるGitのパフォーマンス設定

最もわかりやすい例は、Manifold Security が 2026年9月2日に GitSpawn という名前で公表したものです。これは core.fsmonitor というプロジェクト単位のGit設定を利用します。正当で文書化されたパフォーマンスオプションで、その値は、ディレクトリ全体をスキャンする代わりに変更されたファイルをすばやく特定するためにGitが実行するコマンドです。

では、二つの半分を組み合わせてみましょう。

  • AIコーディングエージェントは、プロジェクトで作業を始める際、リポジトリの状態を把握するために git status や git diff などのGitコマンドを自動的に実行します。これは正常で必要な動作です。
  • リポジトリに悪意ある core.fsmonitor の値が含まれていれば、これらのコマンドを実行するだけで攻撃者のコマンドが実行されます。

その結果、コードリポジトリを開くことは読み取りの出来事ではなくなり、実行の出来事になります。クリックも承認も、開発者に表示される確認もありません。報告によれば、八つのコマンドラインエージェントが影響を受け、そのうちいくつかには修正が続きました。goose は 1.44.0、Claude Code は core.fsmonitor の経路について 2.1.196、Codex CLI は 0.131.0、さらに Cursor です。報告は、公表時点で四つの経路がまだ修正されていないと指摘しました。この種の問題は CVE-2026-72718、CVE-2026-19592、CVE-2026-55607 などの識別子で追跡されました。

単発の事件ではなく、ひとつの種類全体

GitSpawn の六週間前、Pillar Security の研究者は 2026年7月20日に、彼らが「サンドボックス脱出の一週間」と呼ぶシリーズを公表し、三社のベンダーによる四つのコーディングエージェントにわたる七件の脆弱性を記録しました。Cursor、Codex、Gemini CLI、Antigravity です。彼らによる仕組みの説明は、二度読む価値があります。エージェントは箱の中にとどまり、すべてのルールに従います。ただ、箱の外にある信頼されたツールが後で実行、読み込み、またはスキャンするファイルを書くだけなのです。

  • Cursor では、ワークスペースが制御するフック設定ファイルによってサンドボックス外での実行が可能になっていました。CVE-2026-48124 として追跡され、バージョン 3.0.0 で修正されました。
  • Codex CLI では、コマンドの許可リストが git show を名前だけで信頼していましたが、渡されるパラメータによっては読み取り専用にとどまらないことがあります。バージョン 0.95.0 で修正されました。
  • Docker ソケットの問題が、Codex、Cursor、Gemini CLI に同時に影響しました。
  • Antigravity では、macOS Seatbelt の拒否リストの回避と、エディターのタスク設定の問題があり、Google はどちらも悪用が難しいと分類しました。

そして 2026年9月10日、Upstarts Media は、Accomplish というスタートアップによる三件目の開示を報じました。Claude Code、Codex、Cursor のサンドボックスに漏れがあるというものです。そこで興味深い数字は脆弱性ではなく、修正までの時間です。Cursor の問題はおよそ一週間で解決され、OpenAI の二件の問題は八月に、一方 Anthropic の問題は数十回のリリースにわたり約五十日かかりました。三つの研究グループ、三件の報告、二か月、ひとつのパターンです。

コードを書かない企業にとってもなぜ重要なのか

リスクはエージェントに降りかかるのではありません。エージェントを動かすマシンと、そのマシンがつながっているネットワークに降りかかるのです。開発者のワークステーションは、どの企業でも最も権限の高い端末のひとつです。サーバーへのアクセス鍵、デプロイ用トークン、そして多くの場合は本番データベースへの開いた接続を保持しています。そこでコマンドがひとつ実行されることは、小さな出来事ではありません。

このシナリオは、サウジ市場では机上の空論ではありません。次のケースを自社に照らして確認してください。

  • 外部の委託先や開発会社が納品したコードを、御社のチームが社内ネットワーク上のマシンでAIエージェントを使って開く。
  • オープンソースのプロジェクトを、開発者がライブラリや簡単な修正を試すためにダウンロードする。
  • メールや WhatsApp で送られてきたファイルを、サプライヤーから受け取り、解凍してそのままエディターで開く。
  • 採用候補者が提出したサンプルプロジェクトを、技術面の審査担当者が開く。
  • 古いブランチや移管されたリポジトリが、買収やプロジェクトの引き継ぎの際に渡される。

これらのどのケースでも、暗黙の前提は「ファイルを読むために開くのは安全な行為だ」ということです。壊れたのは、まさにその前提です。

今週やるべきこと

五つのステップがあり、最初のステップには予算が要りません。

  1. 今日、チーム全体でエージェントのツールを更新する。これらのツールの多くには修正が出ており、価値があるのは一人ではなく全員が修正済みのバージョンを使っていることです。まず誰が何をどのバージョンで動かしているかを把握することから始めてください。その一覧自体が、たいてい存在しないからです。
  2. 受け取ったコードを信頼できないコンテンツとして扱う。委託先やオープンな出どころからのコードは、読む文書ではなく、実行されるものです。最初に開くときは、業務ネットワークから切り離されたマシンやコンテナで開いてください。
  3. 開発マシンを本番環境の鍵から切り離す。外部由来のプロジェクトを開くマシンに、本番サーバーのトークンを置かないでください。そうすれば損失はその端末の中にとどまります。
  4. デプロイは個人のノートPCではなく中央のパイプラインを通す。デプロイが権限を限定したひとつのビルドパイプラインを通るようになれば、一台のマシンの侵害は本番環境への道ではなくなります。
  5. 開発委託契約に条項を追加する。コードをどのように、どのリポジトリから納品するかを指定し、ベンダーにツールを最新に保つよう求める権利が御社にはあります。これは技術論争ではなく、契約条件です。

国内的にも、これらはどれも任意の良い習慣ではありません。国家サイバーセキュリティ庁（NCA）が発行する必須サイバーセキュリティ管理策には、エンドポイントセキュリティ、変更・開発管理のセキュリティ、第三者セキュリティについての明確な領域が含まれており、個人データ保護の責任は個人データ保護法（PDPL）のもとで組織に残ります。ベンダーのプロジェクトを開いた開発者マシンを通じて扉が開いたとしても、それで責任が軽くなるわけではありません。

Origami の見解

私たちはこの三件の報告を、急速に広まったある考えへの修正として読んでいます。エージェントがサンドボックスに閉じ込められている限り、サンドボックスで十分だという考えです。これらの脆弱性は隔離を破りませんでした。箱の中で書かれたものを、箱の外で動くツールへ運ぶ正当な橋を利用したのです。つまり正しい問いは、エージェントがサンドボックス内にあるかどうかではなく、エージェントが生み出したものをどのツールが読み、そのツールがどんな権限で動いているか、ということです。

お客様のところで目にすることからの実務的な観察があります。開発チームにおけるAIツールの導入は、それを管理するどんなポリシーよりも何か月も先を行っています。開発者がツールを試し、気に入り、決定もレビューも一覧化もないまま日々のワークフローの一部になります。問題はツールではありません。問題は、誰も見ていない扉から入ってきたことです。私たちがお客様の環境をレビューするときは、まさにここから始めます。チームのマシンで実際にどのツールが、どんな権限で動いているのか、そして今夜そのうちの一台でコマンドがひとつ実行されたら何が起きるのか。この観点からのレビューをご希望でしたら、お問い合わせページからご連絡ください。

まとめ

二か月の間に公表された三件の独立した開示が語ることは同じです。AIコーディングエージェントは、プロジェクトを開くことを読み取りから実行に変えてしまい、そのために必要なのは外部の者が設定ファイルに一行を仕込むことだけです。ほとんどのツールで修正が公開され、一部の経路は開いたままでしたが、この教訓はどのリリースよりも長く生き残ります。権限の高いマシンで動かすツールはすべて、ポリシーに記載されているかどうかにかかわらず、御社の攻撃対象領域の一部です。ひとつの問いから始めてください。今この瞬間、チームの誰が、どのマシンで、どのバージョンのAIエージェントを動かしているでしょうか。

出典