7月20日、Tom Smithが「xAI Open-Sources Grok Build Coding Agent After Cloud Upload Exposes SSH Keys, Repos」と題した記事を公開した。xAIのAIコーディングエージェント「Grok Build」がSSHキーを含む開発者リポジトリをGoogleクラウドへ無断送信していた事件と、その直後に実施されたオープンソース化の経緯を詳しく報告している。

192KBの仕事に5.1GBの"おまけ"

事件の経緯はシンプルかつ深刻だ。

セキュリティ研究者Cereblabは、ネットワーク傍受ツールmitmproxyを使ってGrok Build CLIバージョン0.2.93のトラフィックを解析した。12GBのテストリポジトリに対し、コーディングタスク本体が生成したトラフィックは約192KB。ところが、undocumentedな別のストレージチャネルが5.1GB（73チャンク）をgrok-code-session-tracesという名前のGoogleクラウドバケットへ送信していた。タスクに必要なデータ量の約27,800倍にのぼる。

エージェントが一度も開いていないファイルも送信対象だった。さらに、.envファイルに書かれた認証情報が平文・無削除のままアップロードされていた。

ユーザーの一人はホームディレクトリでツールを実行したところ、SSHキー、パスワードマネージャーのデータベース、個人ドキュメント、写真が引き込まれるのを目撃した。xAIのマーケティング資料は「セッション中にコードベースの情報は送信されない」と明言していたが、実態はその正反対だった。

「モデルを改善する」というプライバシートグルは、研究者らによればこの挙動に一切影響しなかった。オンでもオフでもアップロードは発生する。存在しないも同然の設定だ。

告知なき停止、そして3日後のオープンソース化

xAIは7月13日、セキュリティアドバイザリも更新履歴の記載もなく、サーバーサイドでアップロードを停止した。Elon MuskはXで「以前にアップロードされたユーザーデータはすべて完全に削除する」と投稿したが、影響を受けたユーザー数、データの保存期間、個々の開発者が削除を確認する手段は一切示されていない。

そして7月15日、xAIはGrok Buildをオープンソース化した。

GitHubリポジトリ（xai-org/grok-build）はRust製のワークスペースで、100万行超のコードをカバーする。エージェントループ、ファイル編集・シェル実行ツール、ターミナルUI、そしてスキル・プラグイン・フック・MCPサーバー・サブエージェントの拡張システムが含まれる。ローカルでコンパイルし、セルフホスト型の推論エンドポイントに向ければ、クラウドを経由しない構成も可能だ。

ライセンスはApache 2.0であり、コードは全体を読める。ただし、xAI自身のコントリビューションガイドラインには「外部からのプルリクエストは受け付けない」と明記されている。Apache 2.0はフォークや改変・再配布の自由を保証するライセンスであるため、コミュニティが独自にフォークして開発を進めることは妨げられない。ただしxAIが管理するメインリポジトリへの直接貢献は認められておらず、コミュニティ主導のプロジェクトとは性格が異なる。セキュリティ報告はGitHub IssuesではなくHackerOne経由だ。

「ソフトウェアの欠陥が信頼の危機に変わった」

The Futurum GroupでVP・プラクティスリードを務めるMitch Ashleyは、この事件を一時的なバグではなくガバナンスの欠如として捉える。

「Grok Buildの事件は、コーディングエージェントが管理されていない非人間アイデンティティとして、ソース・認証情報・インフラへの恒常的なアクセスを与えられていることを示している。にもかかわらず、セキュリティプログラムは依然としてエージェントを通常の開発者ツールと同様に扱っている」

この乖離が、ソフトウェアの欠陥を信頼の危機に変えたとAshleyは指摘する。

「事後にソースを公開することは、証明可能なセキュリティ統制の代替にはならない。修正前に生きた認証情報に対してツールを実行した開発者は、xAIの削除主張に関係なく、今すぐローテーションすべきだ」

Ashleyの言葉が示すとおり、今回のオープンソース化は透明性への一歩ではあるが、「事件後3日での公開」という文脈においては、再発防止の仕組みや影響範囲の開示が伴わない限り、幕引きの側面が否めない。コードが読めることと、それが安全に運用されていたことの証明は別物だ。

※編集部の考察：xAIがコミュニティからのプルリクエストを受け付けないまま「オープンソース」を名乗る判断は、開示の姿勢としては評価できる一方、外部からのセキュリティ改善を取り込む経路を自ら閉じているとも言える。今後、フォークコミュニティが形成されるかどうかが、このリリースの実質的な意味を測るひとつの指標になるだろう。

競合他社との比較と業界全体への示唆

今回の調査で、Claude Code、Codex CLI、Gemini CLIには同様のリポジトリ全体アップロード挙動は確認されなかった。これはGrok Build実装固有の問題である可能性を示唆するが、だからといってAIコーディングエージェント全体が安全というわけではない。ファイルシステムへのアクセス権を持つツールに対するワイヤーレベルの監査は、もはや過剰な用心ではなく合理的なベースラインだ。

AIコーディングエージェントは今やClaude Code、GitHub Copilot、Cursorなど多数の製品が競合する市場となっており、各社がローカル実行とクラウド連携の設計トレードオフを抱えている。今回の事件は、ユーザーがツールを選ぶ際にプライバシーポリシーの文言ではなくネットワーク挙動そのものを検証すべきという実践的な教訓を業界に突きつけた。

7月13日以前にGrok Buildを本番の認証情報を含むリポジトリに対して実行した開発者は、xAIの削除対応の結果にかかわらず、それらの認証情報をローテーションする必要がある。

詳細はxAI Open-Sources Grok Build Coding Agent After Cloud Upload Exposes SSH Keys, Reposを参照していただきたい。