SpaceXAIのAIコーディングツール「Grok Build」は、研究者がユーザーのリポジトリ全体をGoogle Cloudストレージにアップロードしていることを発見した後、批判を浴びました。この侵害は、AIアシスタントがどれほどの機密データを吸収し、保持できるかについて懸念を引き起こしました。

過剰なデータ保持とセキュリティリスク

Cereblabの分析によると、Grok Buildのコマンドラインインターフェース（CLI）は、コードベース全体をパッケージ化してクラウドに送信していました。さらに深刻なことに、このツールは無視するように指示されていたファイルを開き、開発者がgitの履歴から削除したはずのシークレット（機密情報）を取得していました。

このレベルのデータ収集（データホーディング）は、Claude Codeのような競合他社を圧倒しています。キングス・カレッジ・ロンドンのセキュリティ研究者であるLukasz Olejnik博士は、このような収集行為によって、ソースコード、インフラ構成図、脆弱性、および認証情報がリモートサーバーにさらされる可能性があると警告しました。

SpaceXAIとElon Muskの対応

SpaceXAIはアップロード機能を停止しました。研究者は現在、Grokのサーバー上で disable_codebase_upload: true フラグを確認しており、自動プッシュがもはや実行されていないことが裏付けられました。

Elon MuskはXへの投稿で、以前にアップロードされたすべてのデータは「完全に、徹底的に削除される」と述べました。また、彼は「デバッグの問題」のためにSpaceXAIがデータを保持することをユーザーに求めましたが、この要求は多くの人々から矛盾していると見なされています。

同社は保持を管理するために /privacy CLIコマンドを提案しましたが、Cereblabは、このコマンドはセッションごとのストレージを切り替えるだけであり、スキャンダルの原因となった体系的なリポジトリのアップロードを停止するものではないと指摘しました。

なぜこれが開発者や企業にとって重要なのか

この出来事は、AI駆動のコーディングエージェントがもはや単なるオートコンプリート（自動補完）ツールではなく、自律的にコードを読み、修正し、コミットできる存在であることを開発者や企業に警告しています。エージェントがignoreファイル（無視ファイル）をバイパスしたり、削除されたシークレットを復活させたりする場合、「データ保持ゼロ」という主張は、UI上の約束ではなく、技術的なテストによって証明されなければなりません。

CTOやプロダクトオーナーにとって、この事件は以下の必要性を強調しています：

  • 実際のコードベースにおけるAIツールの独立した監査
  • データの取り扱い、保持期間、および削除の保証を明記した契約条項
  • ファイルレベルの権限を強制する実行時のセーフガード（特に認証情報や特許取得済みのアルゴリズムを保持するリポジトリに対して）

主な要点

  • 意図しないデータのスコープ: Grok Buildは、制限されたファイルや削除されたシークレットを含むリポジトリ全体をGoogle Cloudにアップロードしていました。
  • 緩和策の状況: SpaceXAIは自動アップロードを無効化し、収集済みのデータを消去することを約束しました。
  • セキュリティへの影響: この侵害は、AIコーディングエージェントにおける過剰なデータ保持の危険性を浮き彫りにしており、独自のロジックや認証情報が漏洩する可能性があります。

SpaceXAIのGrok Buildツールは、ユーザーのコードベース全体をGoogle Cloudに密かにアップロードし、独自のソースファイルや削除されたシークレットを露出させていたことが判明しました。

何が起きたのか

CereblabはGrok Build CLIのネットワークトラフィックをGoogle Cloudのバケットまで追跡し、フルgitリポジトリがアップロード用に自動的にパッケージ化されていることを発見しました。端的に言えば、アシスタントは無視するように指示されていたデータを取得していたのです。

どのように侵害が発見されたか

研究者がペイロードを調査したところ、アップロードフラグがデフォルトで有効になっており、グローバルなオプトアウト（拒否設定）が存在しないことが分かりました。Lukasz Olejnik博士は、このような「過剰なデータ保持」が、ビジネスロジック、インフラの詳細、および認証トークンを漏洩させる可能性があると警告しました。他のAIコーディングアシスタント（Claude Codeを基準とする）と比較して、Grok Buildの動作は著しく侵入的です。

SpaceXAIの対応

報告が公になった後、SpaceXAIは disable_codebase_upload: true フラグを返すアップデートを配信し、事実上この機能をオフにしました。Elon MuskはXで、アップロードされたすべてのデータは「完全に、徹底的に削除される」と発表し、「プライバシー設定は常に尊重される」と改めて強調しました。また、彼は「デバッグの問題」のために会社がデータを保持することをユーザーに求めましたが、この要求は多くの人々から矛盾していると見なされています。

同社は保持を制御するために /privacy CLIコマンドを推奨しましたが、研究者は、それがセッションごとのストレージを切り替えるだけであり、体系的なリポジトリのアップロードを停止するものではないと指摘しました。

なぜこれが開発者や企業にとって重要なのか

AI駆動のコーディングエージェントは、オートコンプリートから、コードを読み、修正し、コミットできる自律的なツールへと進化しています。エージェントがローカルのignoreファイルをバイパスしたり、削除されたシークレットを復活させたりする場合、「データ保持ゼロ」といういかなる約束も、単なるUI設定ではなく、技術的なテストによって検証されなければなりません。CTOやプロダクトオーナーは、以下の対策を講じるべきです：

  • 実際のコードベースにおけるAIツールの挙動について、独立した監査を依頼する
  • データ取り扱い、保持期間、および削除の保証を定義する明確な契約を交渉する
  • 機密性の高いリポジトリに対してファイルレベルの権限を強制する、ランタイムのセーフガードを実装する

この侵害は、AIの利便性とセキュリティのトレードオフに関する、より広範な問いを投げかけています。SpaceXAIは、アップロード機能はモデル改善のための利用メトリクスを収集するためのものであったと主張しており、当該機能を無効化し、既存のアップロードデータを消去することを約束しました。批判的な見方をする人々は、元の設計には透明性のあるオプトアウトが欠けていたこと、そして事後に行われたプライバシーコマンドは、すでにクラウドに存在するデータを遡及的に保護するものではないことを指摘しています。

SpaceXAIによる反論

SpaceXAIは、アップロード機能はモデル改善のための利用メトリクスを収集することを目的としていたと主張しています。同社は、機能を迅速に無効化したことや、既存のアップロードデータを消去すると約束したことを、責任ある対応の証拠として挙げています。これに対し批判側は、初期設計に明確なオプトアウトが用意されていなかったこと、またプライバシーコマンドではすでにクラウドに保存されているデータを保護できないと反論しています。

要点

AIコーディングアシスタントがリポジトリ全体を密かに吸い出す可能性があるとき、信頼はマーケティングの問題ではなく、技術的な問題となります。組織は、隠れたデータの持ち出しを防ぐために、検証可能で強制力のあるコントロールを要求しなければなりません。さもなければ、自社の競争優位性の源泉であるコードそのものをさらすリスクを負うことになります。