「読んでない」はずのコードが、丸ごとクラウドに

xAI が提供する公式のコーディングCLI「Grok Build」に関して、独立の AI 安全性リサーチャー @cereblab 氏がワイヤーレベルの解析結果を公開しました。結論はかなり強烈で、CLI がエージェントとして扱ったファイルの中身だけでなく、リポジトリ全体が xAI 側の Google Cloud Storage バケットに丸ごと送られていた、というものです。私も普段からコーディングエージェントを毎日触っているので、これは他人事に思えず記事にまとめておきたくなりました。

何が調べられたのか

対象は grok 0.2.93 で、macOS の Apple Silicon 環境で mitmproxy 経由の通信キャプチャを取り、リクエストのメソッド・宛先・ステータス・バイト数まで押さえた再現可能な調査になっています。テスト用リポジトリには「CANARY7F3A9」のような固有マーカーを仕込み、どのファイルの内容がどこに流れたのかを一意に追跡できるようにしてあります。捏造しづらい設計で、成果物として通信ログや GCS バケット名まで晒されているのが特徴です。

3つのポイント

一つ目は、`.env` の中身も生のまま送信されていたという点です。API_KEY や DB_PASSWORD の値がマスクされないまま `/v1/responses` のモデル呼び出しボディに、さらに session_state というアーカイブとして `/v1/storage` にも入っていたと報告されています。

二つ目は、エージェントが「読んでいない」ファイルまで一緒に上がっているという点です。「返事だけしてファイルを読むな」というプロンプトを渡した対照実験でも、リポジトリが git bundle として `/v1/storage` に POST され、開けもしなかったカナリアファイルの中身が復元できたそうです。12GB のリポジトリで試すと 75MB チャンク 73 個、合計 5.10GiB が全部 200 で通り、ストレージ側の上限は見つからなかったとのこと。

三つ目は、この挙動がデフォルトで有効で、UI 上の「モデルの改善に協力する」をオフにしても止まらなかった、という点です。設定 API を叩くと trace_upload_enabled が true のまま返ってきたそうで、単に「オプトアウトしたつもり」で回避できるものではありませんでした。

AIコーディングエージェントを選ぶ基準が変わる

公開後、xAI 側は `disable_codebase_upload: true` でサーバー側から一時的に無効化し、`/privacy` オプトアウトも足したそうですが、著者いわく後者は保存期間の設定であって送信自体は止まらない、とのこと。Elon Musk 氏はすでに送られたデータを削除すると表明していますが、私たちユーザーの立場では「削除された証拠」を確認する術は基本的にありません。

私はここから、AI コーディングエージェントを試すときには「何を読むか」よりも「バックグラウンドで何を送るか」を確認することが、これからの必須項目になったと感じています。特に社外秘のリポジトリや顧客データを含む環境では、CLI のインストーラを走らせる前に、通信先とアップロード対象を契約条項・プライバシーポリシーで押さえておくべきだと思います。私自身、業務用マシンにいきなり導入するのではなく、まず捨てられるサンドボックス VM で挙動を眺めてから判断する、という運用に寄せていくつもりです。

← ブログ一覧に戻る