Grok Build、読んでいないファイルもGit履歴も丸ごと外部送信 認証情報も無加工のまま

xAI（旧TwitterのAI部門、現SpaceXAI）が提供するAIコーディング支援ツール「Grok Build」が、ユーザーの意図を超えて大量のデータを外部へ送信していたことが、セキュリティ調査機関cereblabの検証で明らかになった。APIキーやパスワードといった認証情報は伏せ字処理されずそのまま推論通信に乗り、さらに「このファイルは読まずにOKと答えて」と明示的に指示した場合でも、Gitリポジトリ全体をまとめた「Git bundle」が丸ごとアップロードされていたという。

実際の推論利用量とかけ離れた送信量 #

cereblabは追跡用のダミーデータを仕込んだ実験用リポジトリ（11.2GiB）を用意し、Grok Build 0.2.93の通信を監視した。結果、AIの推論に実際に使われたデータはわずか192KiBだったにもかかわらず、送信された総データ量は少なくとも5.10GiBに達していた。使用量の実に2万7000倍近いデータが、開いてすらいないファイルやコミット履歴ごと外部へ複製されていた計算だ。送信先はxAI管理下のGoogle Cloud Storageバケット「grok-code-session-traces」で、しかも「モデル改善への学習利用」をオプトアウトしていても、このリポジトリ丸ごとアップロード自体は止まらなかった。

ハッカー視点で見る本当のリスク #

これは単なるログ肥大化の話ではない。開発中のリポジトリには .env の残骸や検証用の本番トークン、社内API仕様など、攻撃者にとって一次情報の宝庫になり得るデータが紛れ込みやすい。それがツール側の一存でまるごとクラウドに複製されれば、ユーザーは「何が漏れたか」を後から把握する術を失う。AIコーディングエージェントはこの1年で急速に普及したが、便利さの裏で「どこまで送信されるか」の透明性はベンダーごとに差が大きく、開発現場における新たなサプライチェーンリスクの火種になりつつある。

開発者が今すぐ取れる防御策 #

対策は地道だが確実だ。①シークレットはリポジトリに直接置かず環境変数や外部シークレットマネージャに退避する、②AIコーディングツール導入前にデータ送信ポリシーと「オプトアウトの実効性」を確認する、③Grok Buildなど該当ツールを使った履歴があるなら、触れた可能性のある認証情報は速やかにローテーションする——この3点は最低限のラインとして押さえておきたい。