Data-Exfiltration Behaviors Contradicting "Local-First" Marketing

The researcher identified two materially different data paths leaving the developer's machine :

• The model-turn channel (POST /v1/responses): files the agent opened were serialized into model requests. This is the expected behavior of a cloud coding agent.
• The storage channel (POST /v1/storage): the entire repository was independently packaged as a git bundle and uploaded in ~75 MB chunks to a Google Cloud Storage bucket named grok-code-session-traces .

The scale disparity proved the upload was not driven by what the agent read. On a 12 GB test repository, the storage channel moved 5.10 GiB across 73 chunks (all HTTP 200), while the model-turn channel moved just 192 KB — a ~27,800× ratio . Even with the prompt "reply OK, do not read any files," the tool uploaded the entire repo as a git bundle; cloning the captured bundle recovered a file (src/_probe/never_read_canary.txt) that the agent was explicitly told not to open, along with the full git commit history .

Types of Secrets and Files Transmitted Without Redaction

• .env files containing API keys, database passwords, and other credentials were transmitted verbatim, without masking or redaction through both channels . In controlled tests, a 48 KB file containing database credentials and API keys appeared in the clear in the request body .
• Every tracked file in the repository, plus the full git history (all commits, branches, tags) was bundled and uploaded . This means emoved secrets that were committed months ago but later rotated may still exist in the uploaded data.
• The upload machinery was identified as a first-party Rust crate (xai-data-collector) resident in the binary, with source paths like crates/codegen/xai-data-collector/src/gcs.rs and crates/codegen/xai-grok-shell/src/upload/ .
• On a real 12 GB codebase of never-read random files, the storage endpoint accepted uploads without any size-based rejection; the only non-200 responses were model-usage quota errors (402/429), not storage failures .

Opt-Out Toggle Failure

The researcher tested the "Improve the model" privacy toggle and found it did not stop the uploads .

• After disabling the toggle and restarting, the server settings endpoint still returned trace_upload_enabled: true .
• The storage channel continued accepting chunked git-bundle uploads with HTTP 200 responses .
• A disable_codebase_upload=true config option exists in the harness settings, but its relationship to the server-side behavior is undocumented, and the researcher's tests showed the server did not respect client-side preferences .

Recommended Mitigations for Affected Developers

The original researcher and subsequent analysis outlets recommend the following :

Immediate actions for teams that used Grok Build CLI on private repos:

• Rotate all credentials that existed in any .env file, configuration file, or git history within repositories used with Grok Build, as they may have been transmitted and stored in the grok-code-session-traces GCS bucket .
• Audit git history for secrets that may have existed in any past commit, since the CLI sent the full commit history .
• Assume data was stored, not just transmitted — the server returned HTTP 200 on all storage requests, confirming acceptance .
• Ask xAI whether the bucket has been deleted, what access controls existed, and whether a Data Processing Agreement covered it (none was published at disclosure time) .

Architectural mitigations for any coding agent:

• Run agents in containers/VMs with only the task directory mounted, no home directory, no SSH agent, no Docker socket, and no cloud credential directories exposed .
• Implement egress controls: allow model inference endpoints and authentication hosts, but deny direct generic object-storage uploads. Alert on transfers exceeding 100 MB .
• Use full-host packet capture, DNS logging, and endpoint network telemetry to detect uploads by background coordinator processes that foreground byte counters would miss .
• Test minimum and maximum prompts under wire capture — cases where the agent is told not to read files are critical for detecting exfiltration beyond the context window .
• Run at least three prompt cases: (1) "reply OK, do not read any files," (2) read one specific file, (3) inspect the project language — then compare bytes per endpoint .

Data-Exfiltration Behaviors Contradicting "Local-First" Marketing

The researcher identified two materially different data paths leaving the developer's machine :

• The model-turn channel (POST /v1/responses): files the agent opened were serialized into model requests. This is the expected behavior of a cloud coding agent.
• The storage channel (POST /v1/storage): the entire repository was independently packaged as a git bundle and uploaded in ~75 MB chunks to a Google Cloud Storage bucket named grok-code-session-traces .

The scale disparity proved the upload was not driven by what the agent read. On a 12 GB test repository, the storage channel moved 5.10 GiB across 73 chunks (all HTTP 200), while the model-turn channel moved just 192 KB — a ~27,800× ratio . Even with the prompt "reply OK, do not read any files," the tool uploaded the entire repo as a git bundle; cloning the captured bundle recovered a file (src/_probe/never_read_canary.txt) that the agent was explicitly told not to open, along with the full git commit history .

Types of Secrets and Files Transmitted Without Redaction

• .env files containing API keys, database passwords, and other credentials were transmitted verbatim, without masking or redaction through both channels . In controlled tests, a 48 KB file containing database credentials and API keys appeared in the clear in the request body .
• Every tracked file in the repository, plus the full git history (all commits, branches, tags) was bundled and uploaded . This means emoved secrets that were committed months ago but later rotated may still exist in the uploaded data.
• The upload machinery was identified as a first-party Rust crate (xai-data-collector) resident in the binary, with source paths like crates/codegen/xai-data-collector/src/gcs.rs and crates/codegen/xai-grok-shell/src/upload/ .
• On a real 12 GB codebase of never-read random files, the storage endpoint accepted uploads without any size-based rejection; the only non-200 responses were model-usage quota errors (402/429), not storage failures .

Opt-Out Toggle Failure

The researcher tested the "Improve the model" privacy toggle and found it did not stop the uploads .

• After disabling the toggle and restarting, the server settings endpoint still returned trace_upload_enabled: true .
• The storage channel continued accepting chunked git-bundle uploads with HTTP 200 responses .
• A disable_codebase_upload=true config option exists in the harness settings, but its relationship to the server-side behavior is undocumented, and the researcher's tests showed the server did not respect client-side preferences .

Recommended Mitigations for Affected Developers

The original researcher and subsequent analysis outlets recommend the following :

Immediate actions for teams that used Grok Build CLI on private repos:

• Rotate all credentials that existed in any .env file, configuration file, or git history within repositories used with Grok Build, as they may have been transmitted and stored in the grok-code-session-traces GCS bucket .
• Audit git history for secrets that may have existed in any past commit, since the CLI sent the full commit history .
• Assume data was stored, not just transmitted — the server returned HTTP 200 on all storage requests, confirming acceptance .
• Ask xAI whether the bucket has been deleted, what access controls existed, and whether a Data Processing Agreement covered it (none was published at disclosure time) .

Architectural mitigations for any coding agent:

• Run agents in containers/VMs with only the task directory mounted, no home directory, no SSH agent, no Docker socket, and no cloud credential directories exposed .
• Implement egress controls: allow model inference endpoints and authentication hosts, but deny direct generic object-storage uploads. Alert on transfers exceeding 100 MB .
• Use full-host packet capture, DNS logging, and endpoint network telemetry to detect uploads by background coordinator processes that foreground byte counters would miss .
• Test minimum and maximum prompts under wire capture — cases where the agent is told not to read files are critical for detecting exfiltration beyond the context window .
• Run at least three prompt cases: (1) "reply OK, do not read any files," (2) read one specific file, (3) inspect the project language — then compare bytes per endpoint .