Elon Musk、Grok Buildがユーザーコードをアップロードしていたことを認める、SpaceXAIは全データ削除を約束
Elon Muskは、ユーザーが「モデルの改善に協力する」オプションを無効にしていた場合でも、Grok Buildがコードリポジトリ全体を企業管理下のクラウドストレージへアップロードしていたことを認めた。
この事実は、特定ベンダーとの関係を明示していない、Cereblabという匿名の独立系AI安全性研究者によって明らかにされた。研究者は再現可能な通信レベルの実証において、ローカルで信頼された証明書を用いたmitmproxy経由でHTTPS通信をルーティングし、macOS上のGrok Build CLI v0.2.93をテストした。12GBのテスト用リポジトリでは、73個のチャンクに分けて5.1GiBのストレージ通信が発生した一方、モデルとの会話に使用されたデータ量は約192KBだった。
その後、Muskは、それまでにアップロードされたユーザーデータを削除すると約束した。SpaceXAIは保持期間を管理するための/privacyコントロールもユーザーに案内した。同社の公式コマンドドキュメントでは、これはプライバシーとデータ保持の状態を表示または切り替えるものと説明されている。
この問題は、モデルのトレーニングを管理するコントロールと、コードがユーザーのマシン外へ送信されるかどうかという別の問題との間に隔たりがあることを浮き彫りにしている。このトグルによってアップロードも防止されると解釈した開発者は、その適用範囲を誤解していた可能性がある。
今回の出来事により、SpaceXAIは、サーバー側の変更によってリポジトリの転送が停止し、保持されていたデータが削除されたことを証明するよう迫られている。また、プロンプトに回答するために一定のリモートコードアクセスを必要とするクラウドベースのコーディングエージェントを評価する開発者にとって、より広範な問題も提起している。
Grok Buildは、SpaceXAIのターミナルベースのAIプログラミングエージェントである。一部の報道では「xAIツール」と呼ばれているものの、現在の公式製品資料では、Grok Buildはx.aiドメイン上で提供されるSpaceXAI製品と位置付けられている。そのため、ここでは会社名として「SpaceXAI」を使用し、Grok Buildを製品、Grokをその基盤となる製品ファミリーとして扱う。
Cereblabによる最も強力なテストでは、「OKと返信し、いかなるファイルも開かないで」というプロンプトが使用された。それにもかかわらず、Grok BuildはPOST /v1/storageを通じてGitバンドルを送信した。取得したペイロードをクローンすると、47個のファイル、4件のコミット、完全な履歴、そしてエージェントに読み取らないよう指示していたカナリアファイルが復元された。報告された送信先は、grok-code-session-tracesという名前のGoogle Cloud Storageバケットだった。
転送中の通信はHTTPSで暗号化されていたが、研究者はローカルの信頼済み証明書をインストールすることで内容を確認できた。公開されている証拠からは、このバケットの保存時暗号化設定、アクセス履歴、地理的な保存場所、保持期間は確認できない。
@a_green_beingとして投稿した別のユーザーは、4つのリポジトリで339件のrepo_state.upload.enqueuedログイベントを確認したと報告した。その中には、記録されたリポジトリパスがユーザーのホームディレクトリになっていたものも含まれていた。この証言は、より広範な収集が行われていた可能性を裏付けるが、独立した監査を受けたフォレンジック調査の結果ではなく、あくまでユーザーからの報告である。
Muskは、これらの情報開示を受けて事実を認めた。Axiosの報道によると、Muskは発表前にアップロードされたデータを完全に削除すると約束した。SpaceXAIは、ゼロデータ保持契約の顧客についてはトレースデータやコードデータを保持していなかったと説明し、その後、デフォルトのデータ保持を無効化した。削除が行われたことは、まだ独立した監査によって確認されていない。
問題の核心は、目に見えるトレーニング用トグルからユーザーが合理的に推測した内容と、テストで明らかになった実際の挙動との間にある。Cereblabは、モデル改善を無効にしても、当初はリポジトリのパッケージ化や送信が防止されず、サーバーが引き続きtrace_upload_enabled: trueを返していたことを確認した。
この違いは重要である。企業はコードをトレーニングに使用しなくても、デバッグ、トレースの保存、またはその他の運用目的でコードを送信・保持することができる。SpaceXAIは、データ保持はデバッグに有用だと説明し、ゼロデータ保持契約は順守されていたと述べた。しかし、完全なリポジトリとGit履歴がデフォルトで収集されていた理由を説明する包括的なインシデント報告書は公開していない。
証拠にも限界がある。Cereblabがテストしたのは、管理された2つのリポジトリ上で動作する初期のCLIバージョン0.2.93であり、すべてのオペレーティングシステム、アカウント階層、設定、リリースを対象としたものではない。このテストは当該条件下での挙動を実証しているが、影響を受けた顧客数や、SpaceXAIの従業員または第三者が保存されたコードにアクセスしたかどうかまでは明らかにしていない。
その後、Cereblabは同じバイナリを使用してテストを6回繰り返し、SpaceXAIがサーバー設定をdisable_codebase_upload: trueおよびtrace_upload_enabled: falseに変更した後は、ストレージへのアップロードが発生しないことを確認した。これはサーバー側で対策が講じられたことを示しているが、以前に保持されたデータが削除されたことを証明するものではない。
影響を受けたバージョンのGrok Buildを実行していたマシン上に独自コードを保存している開発者が、最も直接的な影響を受けるグループである。実際には、リポジトリのバンドルには現在のチェックアウトで見えるファイル以外の情報も含まれる可能性がある。Git履歴には、削除済みの認証情報、社内エンドポイント、顧客識別子、未公開のソースコードが残っている場合がある。
ユーザーは~/.grok/logs/unified.jsonlでrepo_state.uploadイベントを調べ、Grokがどのパスをリポジトリのルートとして扱っていたかを確認できる。機密情報がマシン外に送信された可能性が判明した場合は、該当する認証情報をローテーションすべきである。クラウドストレージから削除しても、それ以前にアクセスされていた可能性を取り消すことはできない。
元の研究者が実施した限定的なテストを再現するには、Grok Build v0.2.93、一意のカナリアを含む使い捨てのGitリポジトリ、そして隔離されたテスト環境にのみインストールされたHTTPS検査プロキシが必要になる。テスト用プロンプトでは、エージェントにファイルを読み取らないよう指示する。その後、調査担当者はモデル通信と/v1/storageリクエストを比較し、取得したGitバンドルがあればクローンを試みることができる。このテストを本番環境のリポジトリで実施してはならない。
SpaceXAIは、影響を受けたアカウントの総数、アップロード機能が稼働していた全期間、バケットのアクセスログ、第三者による削除確認を公開していない。同社の企業向け規約では一般に削除義務に一定の例外が認められている一方、SpaceXAIは、ゼロデータ保持契約を結んでいるGrok Buildユーザーはデータ保持の対象ではなかったと説明している。
/privacyコマンドは、より明確なコントロールポイントを提供するが、これはデータ保持を管理するものであり、推論やその他の処理のためにコードが一切送信されないことを証明するものではない。ユーザーは、このコマンドをオフラインモードとして扱うのではなく、ネットワーク上の挙動とアカウント単位のデータ保持状態の両方を確認すべきである。
Cereblabは、Claude Code、OpenAI Codex、Geminiに対して同等のアイドルプロンプトテストを実施したところ、完全なリポジトリバンドルは生成されず、これらのツールが送信したのは実際に開いたファイルのみだったと報告している。これは有用な管理された比較だが、包括的なセキュリティランキングではなく、バージョンや設定によって結果が変わる可能性がある。
SpaceXAIはその後、Grok Buildのハーネスをオープンソース化し、独立したレビュー担当者がリポジトリのパッケージ化とアップロード経路をより詳しく確認できるようにした。ソースレビューは説明責任の向上につながるが、サーバー側の設定とデータ削除については、依然としてクライアントコードから検証できる範囲外にある。
ユーザーは今後3か月間、3つの兆候を注視すべきである。第一に、何が削除されたのか、削除がいつ完了したのか、保存されたリポジトリにアクセスがあったのかを確認する、詳細な企業インシデント報告書または独立監査。第二に、モデルのトレーニングに関する同意、運用上の送信、デバッグ目的の保持、ゼロデータ保持の挙動を明確に区別するドキュメント。第三に、現行リリースで元の/v1/storage転送を再現しようとする独立した試みである。
これらがいずれも現れなければ、過去のデータ保持と削除をめぐる不確実性は残り続ける。SpaceXAIが検証可能なログを公開し、保持期間を正確に定義し、現行ビルドが反復テストに耐えられれば、表明されたポリシーと観測された挙動との隔たりを縮め始めることができる。
AIコーディングエージェントを評価するチームにとって、実務上の教訓は、クラウドツールを全面的に拒否するというものではなく、より限定的なものである。新しいエージェントは使い捨てのリポジトリ内で実行し、機密情報はアクセス可能な作業ディレクトリの外に置き、外向きの通信を監視し、非公開コードへのアクセスを許可する前にデータ保持条件を確認すべきである。
