A cloud coding agent needs some code to answer useful questions. It does not need a copy of every tracked file and the repository’s complete history to reply “OK.”

That distinction is the center of a wire-level analysis of xAI’s Grok Build CLI. In tests against version 0.2.93, researcher Cereblab captured a separate background upload containing a Git bundle of the repository — including a file the agent had been explicitly told not to read.

TL;DR

  • Grok Build 0.2.93 uploaded a Git bundle through a storage endpoint in the tested consumer configuration, independently of the files used for the model response.
  • Cloning the captured bundle recovered a never-read canary file and the repository’s full Git history.
  • Turning off “Improve the model” did not stop the upload. That control governed data use, not whether the repository left the workstation.
  • xAI later disabled codebase uploads server-side. Elon Musk committed to deleting previously uploaded data, but completion has not been independently confirmed.
  • The evidence proves transmission and server acceptance. It does not prove model training, employee access, or identical behavior for every Grok Build account.

Two Data Paths, Two Different Risks

The research identified two channels.

The first was expected for a cloud agent: when Grok Build read a file, its contents appeared in the request sent to the model endpoint. Synthetic API keys and database passwords placed in a tracked .env-style test file were transmitted verbatim, without redaction. The same content was also found in a staged session-state archive destined for storage.

The second channel changed the risk calculation. Grok Build packaged the workspace as a Git bundle and sent it through POST /v1/storage. This happened even when the prompt instructed the agent to reply with “OK” and read no files.

The researcher preserved the uploaded bundle and cloned it. The resulting repository contained a uniquely marked file that the agent had not opened, plus the commit history. A second repository reproduced the behavior.

This is not the same as the model receiving task-specific context:

ChannelObserved contentSecurity consequence
Model requestFiles the agent readSecrets in opened files can leave the workstation unredacted
Storage uploadTracked repository content and Git historyUnneeded code and historical data cross the trust boundary

In a scale test using roughly 12 GB of never-read random files, the storage channel accepted 5.10 GiB before the capture stopped. The model-turn channel transferred about 192 KB. The run did not prove that the entire 12 GB upload would complete, but it did demonstrate repeated multi-gigabyte storage uploads returning HTTP 200.

Why Git History Makes This Worse

A repository’s current working tree is only the latest page of the story. Git history may still contain credentials removed months ago, internal hostnames, abandoned architecture, customer identifiers, private feature names, or code deleted after a security review.

A developer may inspect the visible files, confirm that no secret is present, and still expose an old token through an earlier commit. A full Git bundle preserves that historical context by design.

The research does not establish that every untracked or .gitignored file was included in the whole-repository channel. The tested secret file was tracked, and the strongest defensible claim is therefore about tracked content and Git history. Files the agent actively read could also be transmitted through the model channel regardless of whether they belonged in source control.

The Privacy Toggle Did Not Stop Transmission

Cereblab repeated the repository test after disabling Grok’s “Improve the model” setting. The Git bundle was still uploaded, and the server settings continued to report trace and upload features as enabled.

This exposes a common privacy-control failure: data retention, model training, telemetry, session synchronization, and network transmission are different controls. An opt-out from training should not be interpreted as “my code stays local” unless the product explicitly promises and technically enforces that boundary.

The capture proves that data left the test machine and that storage requests were accepted. It does not prove that xAI used the repository for training, that an employee viewed it, or how long each object remained stored.

What Changed After Disclosure

On July 14, Cereblab updated the report to say xAI had set disable_codebase_upload: true server-side. Subsequent tests did not observe the repository upload. xAI also added a /privacy opt-out, but the researcher found that it controlled coding-data retention rather than blocking transmission.

Elon Musk publicly committed to deleting previously uploaded data. At the time of writing, the researcher’s update says that deletion has not been independently confirmed as complete.

The current server-side mitigation matters, but it is not a durable client-side security boundary. Remote feature flags can change without a new binary appearing on a developer workstation. xAI’s enterprise documentation now describes managed configuration, fail-closed policy pins, and network destinations, giving organizations better enforcement options than a consumer preference toggle.

Incident Response for Existing Users

If Grok Build 0.2.93 was used against a private or sensitive repository before the server-side change, treat the event as a potential third-party data disclosure and scope it accordingly.

  1. Inventory affected repositories and sessions. Identify where Grok Build ran, under which account, and during what dates. Include sessions launched from parent directories that may themselves have been Git repositories.
  2. Search the current tree and history for secrets. Do not stop at .env. Look for cloud keys, database URLs, package registry tokens, signing material, OAuth secrets, webhook credentials, and private certificates across all commits.
  3. Revoke before replacing. If a valid credential existed in the reachable repository or was read during a session, revoke it and review provider logs. Merely creating a new key does not invalidate the old one.
  4. Review downstream access. Check cloud audit logs, Git hosting audit events, database authentication, package publishing, CI/CD, and SaaS access for use of exposed credentials.
  5. Assess non-secret data. Source code, customer data, licensed assets, vulnerability details, and contractual material may require legal, privacy, customer, or vendor notification even when no credential was present.
  6. Request deletion evidence from xAI. Record the account, repository, approximate session time, product version, and support response. A public commitment is useful; an auditable response tied to your data is better.

Safer Rules for Cloud Coding Agents

Do not make .gitignore carry a job it was never designed to do. It prevents accidental commits; it is not a data-loss-prevention policy for a process that can read the filesystem or package Git history.

For personal and small-team environments, the practical controls are straightforward:

  • Run cloud agents only inside a clean working copy that contains the minimum code required for the task.
  • Keep production credentials out of source files and Git history. Inject short-lived credentials from a secrets manager only when needed.
  • Use separate OS users, containers, or disposable VMs for untrusted repositories and high-autonomy agents.
  • Restrict network egress to documented endpoints and alert on unexpected bulk uploads from developer tools.
  • Re-test data flows after client updates and remote configuration changes. Version approval alone is not enough when behavior is controlled server-side.
  • Prefer enterprise or local deployments with enforceable retention, telemetry, and data-boundary policies for proprietary or regulated code.

The broader lesson is not that cloud coding agents should never receive code. It is that “the agent can access this repository” and “the vendor may copy this repository” are separate permissions. Products should ask for both. Security teams should verify both.

Sources