xAI Grok Build CLIが送信するデータをワイヤー解析
原題: What xAI's Grok Build CLI Actually Sends to xAI
なぜ重要か
開発者向けCLIツールがコードや機密情報をサーバーへ大量送信する実態が示され、AI開発ツールのデータ収集慣行とプライバシーリスクへの業界的な注目が高まる。
セキュリティ研究者が、xAIの公式コーディングCLIツール「Grok Build」（バージョン0.2.93）が、ユーザーのローカルリポジトリ全体および.envファイル内の機密情報をxAIのサーバーへ送信していることをワイヤーレベルの通信解析によって確認した。送信先はGoogle Cloud Storageバケット「grok-code-session-traces」であることも判明した。
GitHubのGistに公開された調査レポートによると、研究者のcereblabが自身のマシン上でダミーリポジトリと偽の「カナリア」シークレットを使用して検証した結果、Grok Build CLIが3つの重大な動作を行うことが確認された。
第一に、CLIが読み込んだファイルの内容（.envファイルに含まれる機密情報を含む）をxAIへ無加工・無削除のまま送信する。この機密情報は、モデルへのリアルタイムリクエスト（POST /v1/responses）と、セッション状態アーカイブのアップロード（POST /v1/storage）の2つの経路で送信されることが確認された。
第二に、AIエージェントが実際に読み込んだファイルとは無関係に、リポジトリ全体（追跡済みファイルの内容とgit履歴）をアップロードする。研究者が「ファイルを読まずにOKと返答せよ」という指示を与えた状態で検証したところ、Grokはリポジトリ全体をgitバンドル形式でPOST /v1/storageへアップロードし、HTTP 200レスポンスを受け取った。キャプチャしたバンドルをgit cloneすると、エージェントに読み込まないよう指示したファイル「src/_probe/never_read_canary.txt」の内容と完全なgit履歴が復元できた。
第三に、12GBのリポジトリを使用した検証では、/v1/storageが5.10GiBのデータを転送（すべてHTTP 200）した一方、モデルターンのチャンネルはわずか192KBにとどまり、約27,800倍の差が生じた。これにより、大量アップロードがモデルの読み込み内容ではなくコードベース全体に起因するものであることが裏付けられた。
アップロード先はAWS S3ではなく、Google Cloud StorageバケットのURLとして「gs://grok-code-session-traces/…」がバイナリおよびキャプチャしたmetadata.jsonに記載されていた。研究者は、このメカニズムがxAIの公式ドキュメントに明示されていなかったと述べている。