xAI、データ流出のGrok Buildをオープンソース化

AIスタートアップxAIのターミナル型コーディングエージェント「Grok Build」が、開発者のGitリポジトリ全体を無断でクラウドにアップロードしていたことが発覚しました。SSHキーやパスワード、コミット履歴に残る機密情報まで対象になっていたとされ、xAIは騒動発覚から数時間後にツールのソースコード(Rust製、約84万4530行)をApache 2.0ライセンスでGitHub上に公開しています。

背景と文脈
技術/ビジネス面
これからどうなるか
まとめ
参考リンク – xai-org/grok-build, now open source – xAI open-sources Grok Build on GitHub after massive data breach

背景と文脈

発端は、セキュリティ研究者「cereblab」氏による調査でした。Grok Build CLIのバージョン0.2.93を対象に通信解析を行ったところ、「grok-code-session-traces」という名前のGoogle Cloud Storageバケットへ、Gitリポジトリの中身がまるごと送信されていることが判明しました。検証用の12GBのリポジトリでは、タスクに必要な通信量がわずか192KBだったのに対し、実際には約5.1GBものデータが外部に送られていたといいます。

問題は送信範囲の広さです。追跡対象になっているファイルだけでなく、過去にコミットされ、その後ワーキングツリーからは削除された機密情報も、コミット履歴に残っている限り対象になります。2026年7月13日より前にGitリポジトリのあるディレクトリでGrok Buildを実行した開発者は、APIキーやデータベースのパスワード、クラウドの認証トークン、SSHキーなど、追跡対象ファイルとコミット履歴に含まれるあらゆる認証情報が送信された可能性があると考えるべき状況です。

この問題はHacker Newsでもトップ記事として大きな注目を集めました。AIコーディングエージェントは、コードベース全体を読み込んで文脈を把握する必要があるという性質上、通常のツール以上に広範なアクセス権を要求します。その利便性の裏側で、実際に何が送信されているかを利用者側が検証しにくい構造そのものが、今回の問題の温床になったといえます。

技術/ビジネス面

暗い環境でキーボードを操作する様子 — Photo by Jason Jarrach on Unsplash

利用者を誤解させていたのは、ツール内の「Improve the model」というトグルスイッチでした。多くの開発者はこれをオフにすればデータ収集そのものを止められると考えていましたが、実際にはこの設定は収集したデータを学習に使うかどうかを制御するだけで、コードが手元の端末から外部に送信されるかどうかとは無関係だったのです。

xAIは問題発覚後、この機能を無効化しましたが、セキュリティ研究者の分析によれば、リポジトリを丸ごと外部送信するコード自体は公開されたバイナリの中に今も残っています。無効化はサーバー側の設定フラグによるもので、ソフトウェアの更新なしにxAI側がいつでも再有効化できる状態だといいます。イーロン・マスク氏は、予防措置としてこれまでにアップロードされた全ユーザーデータを完全に削除するとコメントしました。

xAIはこの騒動を受けて、Grok Buildのソースコード約84万4530行をApache 2.0ライセンスの下でGitHubに公開しました。透明性の確保を図る狙いとみられますが、問題のコード自体が残存している以上、公開だけでは根本的な解決になっていないとの指摘も出ています。

これからどうなるか

今回の一件は、AIコーディングエージェントが「タスクに必要なファイルだけ」を扱っているとは限らないことを示しました。ツールの同意設定が実際の挙動と一致しているかどうかは、利用規約やUIの文言だけでは判断できません。

開発者にとっての教訓は明確です。AIコーディングエージェントをGitリポジトリのあるディレクトリで実行する前に、ネットワークトラフィックを自分で検証する、あるいは信頼できる第三者の監査結果を確認する習慣が必要になります。特に過去にコミットして削除したはずの認証情報は、コミット履歴をたどれば今でも読み取れることを再認識し、該当する鍵やパスワードのローテーション(定期的な更新)を検討する価値があるでしょう。同様のツールをCI/CD環境に組み込んでいる場合は、送信先ドメインを許可リストで制限するなど、通信そのものを技術的に制約する対策も検討に値します。