xAI Grok Build 0.2.93、5.10GiBの完全リポジトリをアップロード――デフォルト有効のプライバシー設定が物議を醸す

xAI Grok Build 0.2.93は、ツール呼び出しが不要なシナリオにおいても、ユーザーの完全なGitリポジトリをコミット履歴および未マスクの.envシークレットとともに、grok-code-session-tracesというGoogleクラウドストレージバケットへアップロードしており、この動作はユーザーの指示とは無関係に実行されていた。

事実の検証

2026年7月、セキュリティ研究者のcereblab氏がMITMProxyを使用してmacOS上のHTTPSトラフィックを傍受し、Grok Buildに2つの独立した転送経路が存在することを発見した。第1の経路はモデルとの対話チャネルであり、エージェントが明示的に読み取ったファイルの内容のみを送信する。第2の経路はバックグラウンドのストレージチャネルであり、POST /v1/storageを通じてワークスペース全体のスナップショットをxAIが運営するストレージバケットへアップロードする。研究者はリポジトリ内にnever_read_canary.txtというファイルを仕込み、Grokに読み取らないよう指示したが、そのファイルは完全にアップロードされており、アップロード範囲がモデルの実際の使用ニーズを超えていることが証明された。12GBのテストリポジトリにおいて、モデルチャネルが転送したデータはわずか192KBであったのに対し、ストレージチャネルは5.10GiBものデータを転送しており、その比率は約27,800倍に達する。同一テストにおいて、.envファイル内のAPI_KEYおよびDB_PASSWORDがリクエストボディとセッションアーカイブに平文で記録されていることも確認された。

メカニズムの解析

Grok Build CLIのインストールスクリプトおよびクイックスタートドキュメントには、このストレージチャネルに関する説明が一切記載されていなかった。ユーザーが「Improve the model」スイッチをオフにした後も、サーバーのレスポンスにはtrace_upload_enabled: trueが表示され続け、バックグラウンドのアップロードは継続されていた。xAIはその後、サーバーサイドの変更によってdisable_codebase_uploadをtrueに設定し、ユーザーが共有の確認と無効化を行うための/privacyコマンドを新たに追加した。ただし、このオプションはデフォルトで有効の状態になっている。企業ユーザーがZero Data Retention設定を有効にしている場合、コードおよびトレースデータは保存されない。

業界への影響

開発者にとって、このインシデントは、明示的な同意なしにローカルのコードベースがローカル環境の外に出る可能性を直接的に露呈させた。個人開発者や小規模チームがGrok Buildを引き続き使用する場合は、直ちに/privacy opt-outコマンドを実行して転送を停止する必要があり、そうしなければ知的財産の管理権が一部クラウド側に移ることになる。企業ユーザーに対してはZero Data Retentionオプションが隔離の手段を提供しているが、独立した監査機能が欠如しており、過去にアップロードされたデータが完全に削除されたかどうかを検証する方法がない。競合環境への影響としては、OpenAI CEOのSam Altman氏が「concerning（懸念される）」とコメントしており、同種のAIコーディングツール間でデータ処理の透明性に差異があることが、ユーザー移行の引き金になり得ることを示している。xAI自身にとっては、迅速なサーバーサイド修正によりそれ以上のアップロードは阻止されたものの、過去にアップロードされたデータの保持期間と削除範囲については公式な説明がなされていない。

戦略的見通し

現時点の事実に基づけば、最も可能性の高い展開は、より多くの開発者がローカルファースト、またはデータ最小化原則を明確に掲げるコーディングツールへ移行することである。検証すべきシグナルとしては、xAIが独立したサードパーティ監査レポートを公表するかどうか、および今後のバージョンでオプション外のすべてのストレージチャネルがデフォルトで無効化されるかどうかが挙げられる。