研究者がGrokに対して「ファイルを読まずに『OK』とだけ答えるように」と指示しても、リポジトリ全体のアップロードは止まりませんでした。キャプチャしたアップロードデータからは、Grok Buildが「読むな」と明示的に指示されていたファイルも完全に復元できたといいます
。
別のセキュリティ研究者Hariも逆解析でこれを確認し、Grok Buildがユーザーのディレクトリ全体を明示的な許可なくアップロードしていたと報告しています。あるテストでは、約11.2 GiBのリポジトリを使った実験で、実際のコーディングタスクに必要なデータは約192 KBだったにもかかわらず、少なくとも5.1 GiBのデータがバックグラウンド経路で送信されていました
。
イーロン・マスクCEOはXでこの問題を認め、最初の言葉は「True(本当だ)」でした。続けて「予防措置として、SpaceXAIに以前アップロードされたすべてのユーザーデータは、完全かつ徹底的に削除される。一切の残骸も残らない」と約束しました
。
xAIも声明を発表し、ユーザーのプライバシーを真剣に受け止めていると述べました。また、ゼロデータ保持(ZDR) を利用するエンタープライズ顧客については、コードやトレーニングデータが使用されることはなかったと説明しています。
実際の対応として、xAIはサーバー側の変更で/v1/save-sessionエンドポイントを無効化し、リポジトリのバックグラウンドアップロードを停止しました。このアップロードは2026年7月13日までに止まっています
。
xAIの対応は速報的な問題を止めるには有効でしたが、以下の根本的な課題は解決されていません。
研究者が指摘したように、Grok Build CLIクライアント(バージョン0.2.93)自体は一度もアップデートされていません。xAIは単にサーバー側の受信エンドポイントをオフにしただけです。つまり、クライアントのコードには依然としてリポジトリ全体をアップロードする機能が残っており、エンドポイントが再び有効になれば同じ挙動が再開される可能性があります。
研究者はxAIのいわゆる「プライバシーモード」やデータ保持のオプトアウトコマンドをテストしましたが、バックグラウンドでのリポジトリ全体のアップロードを防ぐことはできませんでした。研究者は「xAIのプライバシーコマンドが問題を修正したわけではない」と明言しています
。実際には、
disable_codebase_uploadという隠されたサーバー側フラグがtrueに設定されたことでアップロードが停止したのです。
修正前に送信された認証情報、プロプライエタリなコード、シークレットは、すでにxAIのクラウドインフラに保存されています。研究者はアップロードをキャプチャし、Gitバンドルをクローンして、Grokが「読むな」と指示されていたファイルを復元することに成功しています
。
| 項目 | 詳細 |
|---|---|
| 影響を受けたツール | Grok Build CLI バージョン0.2.93 |
| 発覚日 | 2026年7月12日 |
| アップロードされたデータ | Gitリポジトリ全体、全コミット履歴、マスキングされていない.envシークレット |
| 送信先 | Google Cloud Storageバケット(grok-code-session-trace) |
| 研究者 | cereblab(独立研究者)、Hariも独立に確認 |
| マスクCEOの対応 | 問題を公に認め、全過去データの削除を約束 |
| 適用された修正 | サーバー側での/v1/save-sessionエンドポイント無効化、隠しフラグdisable_codebase_uploadの設定 |
| クライアントの更新 | なし |
| プライバシーオプトアウトの有効性 | 無効——オプトアウトしてもアップロードは継続 |
| データ削除の検証 | 公表時点で独立した検証はなし |
Grok Buildのこのインシデントは、AIコーディング支援ツールが「何を」「どこまで」クラウドに送信しているのか、その不透明さを浮き彫りにしました。
xAIがクライアントアップデートをリリースし、データ削除の独立した検証結果を公表するまでは、Grok Buildを使用した開発者は、自分のリポジトリ内のすべての認証情報、プロプライエタリなコード、機密情報がxAIのクラウドインフラに送信された可能性があると想定して行動すべきです。
この一件は、AIツールを開発プロセスに組み込む際のセキュリティとプライバシーリスクについて、業界全体が真剣に向き合うべき警鐘と言えるでしょう。