xAI Grok Build CLI 0.2.93 分析：未編集のシークレットとリポジトリ全体のアップロード

xAI Grok Build CLI（バージョン 0.2.93）のワイヤーレベル分析により、ツールが未編集のシークレットを送信し、ローカルリポジトリ全体を xAI サーバーにアップロードすることが示されています。この動作は、AI エージェントがセッション中に実際にファイルを読み取るかどうかに関係なく発生し、"Improve the model" 設定が無効化されていても持続します。

未編集のシークレットの送信

Grok Build CLI がファイルを読み取ると、その内容は赤字処理なしで xAI に送信されます。これには .env や secrets.env といった機密ファイルが含まれます。データは以下の 2 つの異なるチャネルを通じて送信されます。

Model-Turn Channel: ファイル内容が POST /v1/responses リクエストボディにシリアライズされ、モデルとのやり取りに使用されます。
Storage Channel: 内容が session_state アーカイブにパッケージ化され、POST /v1/storage を介してアップロードされます。

取得したトラフィックの分析により、カナリアシークレット（例: API_KEY=CANARY7F3A9-SECRET）が両エンドポイントにそのまま送信され、HTTP 200 ステータスコードで受理されていることが確認されました。

Git バンドルによるリポジトリ全体のアップロード

エージェントが読み取るファイル以外にも、Grok Build は作業領域の完全なスナップショットを取得します。ツールはリポジトリ全体（すべてのトラッキングされたファイルと完全な git 履歴）を POST /v1/storage を介して git バンドルとしてアップロードします。

大量アップロードの証拠

ボリュームの不均衡: エージェントに 読まない と明示されたランダムファイルを含む 12 GB のリポジトリでテストしたところ、model‑turn チャネル（/v1/responses）はわずか 192 KB のデータしか送信しませんでした。一方、storage チャネル（/v1/storage）は 5.10 GiB のデータをアップロードしており、キャプチャが途中で切れた時点でもこの量が記録されています。この約 27,800 倍の比率は、アップロードがコードベースのスナップショットであり、モデルが実際に取り込んだ内容の反映ではないことを示しています。
Git Clone による検証: POST /v1/storage リクエストを取得することで git バンドルを復元できました。git clone を実行すると、エージェントに 開かない と指示されたファイルやそれらのユニークマーカーがそのまま再現されました。
スケール: アップロード機構はマルチギガバイト規模に拡張可能です。12 GB リポジトリのテストでは、82 回の content POST（約 75 MB のチャンクが 73 個）すべてが HTTP 200 を返し、テスト範囲内でストレージサイズの上限に達していないことが示されました。

保存先とインフラストラクチャ

アップロードされたデータは grok-code-session-traces という名前の Google Cloud Storage（GCS）バケットにルーティングされます。これは以下により確認されています。

バイナリ解析: バイナリ内の文字列が grok-code-session-traces と storage.googleapis.com を参照しています。
メタデータ検査: ステージングされた metadata.json ファイルは、gs://grok-code-session-traces/repo_changes_dedup/v2/... という形式でファイルごとの保存先を示しています。

さらに、CLI は Mixpanel（api.mixpanel.com）および xAI の独自イベントトラッキング（grok.com/_data/v1/events）を通じたサードパーティテレメトリも利用しています。

同意、ポリシー、オプトアウトの制限

xAI の消費者ポリシーでは、ユーザーがモデル改善のためにデータを使用することをオプトアウトできるとされていますが、このトグルはリポジトリアップロードプロセスを止めません。

オプトアウトの無効性: "Improve the model" を OFF にしても、CLI は依然としてリポジトリ全体を git バンドルとしてアップロードし、サーバーの /v1/settings 応答は引き続き "trace_upload_enabled": true を返すことがテストで確認されました。
ドキュメントの欠落: repo_state と session_state を grok-code-session-traces バケットにアップロードする具体的なメカニズムは、CLI のインストールスクリプトやクイックスタート資料には記載されていません。

コミュニティの見解と緩和策

この調査結果を受けた技術的議論は、プロプライエタリなエージェントランナーの使用に関する重大なプライバシー懸念を浮き彫りにしています。

"これが正に理由です… 私はそれらを使わないことにしました。 [リポジトリ全体のアップロード] は極めて懸念されます。"

このようなツールを使用せざるを得ないユーザー向けに、いくつかの緩和策が提案されています。

サンドボックス化: bubblewrap や landstrip などのツールを使用して、エージェントのアクセスを必要なプロジェクトディレクトリのみに制限し、ネットワーク名前空間を隔離して特定の LLM プロバイダーのホスト名だけを許可します。
プロキシ: カスタムプロキシ（例: CLIProxyAPI のフォーク）を実装し、外部へ送信されるストリームをシークレットでスキャンし、上流プロバイダーに届く前に一意の識別子に置き換えます。
環境分離: エージェントを専用の UNIX アカウントで実行し、ホームディレクトリおよび /etc や /proc ファイルシステムへのアクセスを制限します。

調査結果の技術的サマリー

発見	詳細	ステータス
シークレット漏洩	`.env` ファイルが `/v1/responses` と `/v1/storage` を介して未編集のまま送信される	検証済み
リポジトリアップロード	トラッキングされた作業領域全体と git 履歴が git バンドルとしてアップロードされる	検証済み
データ量	マルチ GB のアップロードが確認されている（最大 5.1 GiB が取得）	検証済み
保存先	Google Cloud Storage バケット `grok-code-session-traces`	検証済み
オプトアウト	"Improve the model" トグルはアップロードを停止しない	検証済み