何が発覚したのか
AI安全性の研究者Cereblabが日曜日に公開した調査報告によると、コマンドラインツール「Grok Build」は、ファイルを読み込んだり処理したりするたびに、その内容を無修正のままGoogle Cloud Storageのバケットへ送信していました。しかもGrok Buildは、プロンプトに答えるために必要なファイルだけでなく、リポジトリ全体をGitバンドルとしてまとめてアップロードしていたといいます。
Cereblabが「OKとだけ返答し、ファイルは一切開くな」と指示したテストでも、Grok Buildはリポジトリ全体を送信していました。
この挙動はClaude Code・Gemini・Codexなど他のCLIツールとは対照的です。他のツールはプロンプトに必要な個別ファイルだけを開く設計になっており、リポジトリ全体やGit履歴をまとめて送る仕様にはなっていません。
数か月前に削除した秘密情報まで流出
特に深刻なのは、送信されたGit履歴の中に、数か月前に削除されたはずの秘密情報が含まれていたことです。Cereblabは別のリポジトリでもこの挙動を再現できたと報告しています。
報告公開後、他のGrok Buildユーザーからも同様の被害報告が相次ぎました。
- SSHキーを含むユーザーディレクトリ全体が開かれ、アップロードされた事例
- パスワードマネージャーのデータベースファイルが送信された事例
- 削除済みのはずの機密情報がGit履歴経由で流出した事例
これらの報告が注目を集めたことで、SpaceXAIの経営陣とマスク氏本人が公に対応を表明する事態となりました。
修正の中身とゼロデータ保持の設定
Cereblabの確認によれば、CLIの開発チームが disable_codebase_upload を true に設定したことで、リポジトリ全体の送信は止まったとのことです。SpaceXAIはX(旧Twitter)上で、ゼロデータ保持(ZDR)を有効にしている顧客のコードは一切保持されないと説明し、ZDRを有効にしていないユーザーでも /privacy コマンドで過去の同期データを含めて削除できると案内しています。
| 対応 | 内容 |
|---|---|
| 直接の修正 | disable_codebase_upload: true というグローバルフラグをサーバー側で有効化 |
| ユーザー側の設定 | /privacy コマンドでセッション単位の保持設定を変更可能 |
| マスク氏の表明 | これまでアップロードされた全データを削除すると約束 |
ただしCereblabは、実際に転送を止めたのはこのグローバルフラグであり、/privacy コマンドはセッションごとの保持設定に過ぎない点を指摘しており、ユーザーへの説明としては不十分だとしています。
普段からClaude CodeやCodexのようなAIコーディングツールを使う身としては、こうしたツールがリポジトリの中身をどこまで送信しているのか、設定画面だけでは分かりづらい点に不安を感じます。契約前にデータ保持ポリシーを確認する習慣をつけたいと感じました。
マスク氏の姿勢にも批判
マスク氏は全データの削除を約束する一方、別の投稿では「デバッグに役立つため、データはある程度共有し続けてほしい」とユーザーに呼びかけており、この点にも批判が集まっています。The Registerは、SpaceXAIが実際にデータを削除したかどうかを独自に検証できていないと注記しています。
無断アップロードを謝罪しつつ、同じ口で追加のデータ共有を呼びかける姿勢は、企業としての説明責任という点で疑問が残ります。