世界を動かす技術を、日本語で。

xAIのGrok Build CLIが実際にxAIに送信するもの

2026年7月12日原文(gist.github.com)

概要

  • xAI Grok Build CLI は、ユーザーのリポジトリ全体や機密ファイルを Google Cloud Storage にアップロード。
  • 証拠付きの再現性ある解析 で、通信内容やアップロード挙動を詳細に検証。
  • .env等の機密情報も無加工で送信、アップロード先は常にGCSバケット。
  • モデル学習利用は未証明、だが転送・保存自体は確実に実施。
  • CLI設定変更ではアップロード無効化不可、デフォルトで有効。

xAI Grok Build CLIの通信内容とアップロード挙動の詳細解析

  • Grok Build CLI (バージョン0.2.93)は、通常のコンシューマーログイン時に3つの重要な動作を実施。
    • ファイル内容の送信 :読み込んだファイル(例:.envやsecretsファイル)を 無加工・無検閲でxAIにPOST
    • リポジトリ全体のアップロード全トラックファイル+git履歴 をまとめてGoogle Cloud Storage(GCS)バケット(grok-code-session-traces)にアップロード。
    • アップロード挙動の自動化 :CLIの「Improve the model」オプションをオフにしても アップロードは自動で有効
  • 証拠取得方法
    • mitmproxy を利用したHTTPS通信の傍受・復号化。
    • 各リクエストのエンドポイント・HTTPメソッド・ステータスコード・バイトサイズ・ホスト名 を記録。
    • キャプチャした証拠ファイル (リクエストボディ、アップロード済みアーカイブ、git bundleなど)をSHA-256で検証。
  • 送信内容の具体例
    • POST /v1/responses :モデル推論時に 読み込んだファイル内容(例:API_KEYやDB_PASSWORDを含む.env) をそのまま送信。
    • POST /v1/storageリポジトリ全体をアーカイブ化し、GCSバケットへアップロード。git bundle形式で 未読ファイルも含む
  • アップロード規模
    • テストでは 12GBリポジトリで5.1GB超のデータを無停止でアップロード、ストレージ容量制限なし。
    • アップロードはリポジトリサイズに比例、モデル推論経路(/v1/responses)は数百KBのみ。
  • アップロード内容の再現確認
    • アップロード済みgit bundleをclone することで、 CLIに「読まない」と指示したファイルまで復元可能 (例:never_read_canary.txt)。
  • アップロード先の特定
    • Google Cloud Storage のgrok-code-session-tracesバケットが明示的に指定。
    • AWS S3は利用されていない
  • CLIドキュメントには明記なし (クイックスタート等には記載見当たらず、完全なドキュメント監査は未実施)。
  • アップロードの無効化不可
    • 「Improve the model」オプションを無効化してもアップロードは継続
    • CLI設定でtrace_upload_enabledがtrueのまま
  • 学習利用の証拠は未取得
    • 転送・受領・保存は証明済み だが、xAI側でのモデル学習利用は未証明(ポリシー次第)。

実験環境・再現手順

  • macOS Apple Silicon、grok 0.2.93、mitmproxy使用。
  • Canaryリポジトリ :各ファイルに固有マーカー付与、漏洩時の特定を容易化。
  • mitmproxyでHTTPS通信を復号・記録、Grok CLIをプロキシ経由で実行。
  • アップロードアーカイブの中身を直接展開・検証

ファイル送信の証拠

  • POST /v1/responses 経由で secrets.envや.envの内容をそのまま送信 (例:API_KEY=CANARY7F3A9-SECRET-should-not-leave)。
  • POST /v1/storage 経由で 同内容をアーカイブ化しGCSバケットへ
  • コントロール実験 :読ませていないファイル(untouched_secret.txt)は /v1/responses経路では送信されない が、 /v1/storage経路でのアップロード有無は未検証

リポジトリ全体アップロードの証拠

  • リポジトリサイズ増加に応じてアップロードもスケール
    • 64MB→単一POST、600MB→7.5MB分割POST、3GB→50MB分割PUT、12GB→75MB分割POST(合計5.1GB超)。
  • アップロードは全ファイル対象未読ファイルも含む
  • manifest.jsonやmetadata.json の内容から 全ファイルがGCSにコンテンツアドレス指定で保存 されていることを確認。

セキュリティ・プライバシー上の注意点

  • .envやsecrets.env等の機密情報も無検閲送信リポジトリ全体のアップロードも自動
  • CLI設定でアップロード無効化できない ため、 利用者は機密情報の管理や使用リスクに十分注意が必要
  • 証拠に基づく事実 は「転送・受領・保存」までであり、 xAIの学習利用は未証明

証拠・再現性と未証明事項

  • 全証拠ファイルはSHA-256で検証済み、再現手順も明示。
  • 未証明事項リスト :例).gitignoreされたファイルのアップロード有無、真の高エントロピーAPIキーの扱い、xAIによる学習利用。

まとめ xAI Grok Build CLIは、ユーザーのローカルリポジトリ全体や読んだファイル内容を、ユーザーの明示的な同意やCLI設定変更なしにGoogle Cloud Storageへアップロードする挙動がデフォルトで有効。機密ファイルも無加工で送信されるため、利用には十分な注意が必要。

Hackerたちの意見

「リポジトリ全体をアップロードするんだよね — トラッキングされているファイルの内容とgitの履歴すべてを、エージェントが読んでいるものに関係なく」マジかよ!!エロンがこういうことをして追いつこうとするのはなんとなく予想してたけど、これはめちゃくちゃ心配だわ。だから、彼らの価格設定は競争力があるし、grok-4.5は実際に十分良いけど、結局選ばなかったんだよね。

OpenAIはマイクロソフトとの提携で、すべてのGitHubリポジトリにアクセスできるの?

こういうCLIは全部サンドボックス内で動かす理由があるんだ。ディレクトリへのアクセスを制限してね。もしCLIが間違ってSSHキーや他の敏感な情報を引っ張ってきたらどうする?プログラマーはそういうミスをよくするから、"アクセスできるファイルを全部アップロードする"が意図的かミスか、そんなのに頼りたくないんだ。1 - https://github.com/ashishb/amazing-sandbox

無料トライアルを試すのに躊躇してたのは、どんなデータを共有する必要があるのか情報が見つからなかったからなんだよね……

イーロンや本物の人間がこれに関わっているなんて、非常にナイーブな考えだよ。全体の分析パイプラインは、ほぼ確実にバイブコードされていて、人間によるレビューは一切ないだろうね。

これは完全にデータの抜き出しで、違法にすべきだよ。

あの人や彼が持ってるサービスを本当に信じてる人いるの?まあ、いいや、世の中にはいつもバカがいることを忘れてた。

アメリカには2.7百万のStarlink加入者がいるけど、彼らがバカだとは思わないな。

これが、claude-codeやcodex、grok-buildみたいなネイティブのプロプライエタリコーディングエージェントランナーがプライバシーにとって危険な理由の一つなんだよね…次のアップデートでどんな「秘密のソース」を追加するか分からないから…オープンコードを使ってAPI経由でモデルを利用する方がずっと安全なんだけど、でもその分、ネイティブエージェントランナーと同じパフォーマンスは出ないんだよね…

十分な使用があれば、ツールコールだけでコードベース全体を再構築できるし、それはサーバーサイドで全部行われるから全く検出されない。grokがやってることはもっと露骨だけど、オープンコードを使ったりしても、意味のあるセキュリティの境界は作れないよ。それって、チートスを鍵として使うミームみたいなもんだね。

同意するけど、Codexはオープンソースだよ。

最後に確認した時、CodexはまだApache-2.0ライセンスのオープンソースだったよ。

Hacker Newsで議論の続きを見る