Summary

xAI's Grok Build CLI (v0.2.93) transmits file contents, including .env secrets, to xAI's servers without redaction. It also uploads the entire repository as a git bundle to Google Cloud Storage, even when the agent is told not to read files. The uploads happen by default and are not disabled by toggling the "Improve the model" setting.

Technical Details

The analysis was performed using mitmproxy to capture traffic from grok 0.2.93 (SHA-256: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c) on macOS Apple Silicon. The binary is a first-party Rust crate with source paths like crates/codegen/xai-data-collector/src/gcs.rs and crates/codegen/xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs.

Finding 1: Secrets Transmitted Unredacted

A .env file containing API_KEY=CANARY7F3A9-SECRET-should-not-leave and DB_PASSWORD=CANARY7F3A9-DBPASS was found verbatim in two channels:

  • Model turn (POST /v1/responses): A 48,070-byte request body contained the secrets. Reproduce: grep -a "CANARY7F3A9-DBPASS" secrets_responses_body.bin.
  • Session state archive (POST /v1/storage): The same secrets were found in a compressed archive. Reproduce: gzip -dc secrets_session_state.tar.gz | tar -xO | grep -ao 'CANARY7F3A9-[A-Z]*'.

A control run with a file the agent was told not to open showed that unread files were not present in the model-turn channel, but the whole-repo upload channel (see below) still includes them.

Finding 2: Whole Repo Uploaded at GB Scale

Grok uploads a snapshot of the entire workspace to grok-code-session-traces (a Google Cloud Storage bucket). Evidence:

  • Byte volume split: In a 12 GB repo of random files the agent never read, the model-turn channel moved 192 KB, while the storage channel moved 5.10 GiB (73 chunks of ~75 MB each, all HTTP 200). This ~27,800× ratio proves the storage channel carries the whole repo, not just read files.
  • Staged manifest: A captured staged_base_tree_manifest.json listed src/_probe/never_read_canary.txt — a file never asked to open — alongside real sources.

Finding 3: No Opt-Out via Settings

Even with "Improve the model" disabled, the /v1/settings endpoint still returned trace_upload_enabled: true. The upload machinery is active by default and not surfaced in the CLI's install/quickstart materials.

Why It Matters

If you use Grok Build CLI with any repository containing secrets (API keys, database passwords, etc.), those secrets are being transmitted to xAI's servers and stored in Google Cloud Storage. This happens regardless of whether you opt out of model improvement. The tool also uploads your entire codebase, including files you never ask it to read.

Editor's Take

I've been skeptical of AI coding tools that phone home, but this is egregious. I run most AI tools in a sandbox with no network access, and after seeing this analysis, I'd recommend everyone do the same with Grok. The fact that the setting to "improve the model" doesn't actually stop the uploads is a breach of trust. If xAI wants developers to use this tool, they need to provide a clear, functional opt-out and document the data flow. Until then, I'd treat Grok as a data exfiltration risk.

Developer Insights

  1. Run Grok Build CLI in a sandboxed environment with no network access to sensitive repositories.
  2. Do not include .env files or other secrets in any repository you use with Grok.
  3. Monitor network traffic from the CLI to verify what data is being sent.

Tags

  • xAI
  • Grok
  • privacy
  • security
  • CLI
  • data-exfiltration
  • AI-tools
  • secrets-management

Category

  • ai

Quality Score

85