What actually happened

In July 2026, security researcher cereblab intercepted Grok Build CLI traffic (version 0.2.93) using mitmproxy and published the packet captures publicly. The findings, as reported by International Cyber Digest and Landian News:

  • On a 12 GB test repository, only about 192 KB of traffic was task-relevant. Roughly 5.1 GB was uploaded anyway, the entire tracked repository with full Git history, not just the files the model needed for context.
  • Data landed in a Google Cloud Storage bucket named grok-code-session-traces.
  • A canary credential planted in a .env file appeared verbatim and unredacted in the captured upload traffic, meaning secrets in a repo, not just source code, were leaving the machine.
  • The “Improve the model” toggle, the setting that looked like the data-collection control, did not stop uploads when disabled. The server kept returning trace_upload_enabled: true regardless of the toggle state.
  • One day after the report went public, the server started returning disable_codebase_upload: true, and repeat tests showed no further uploads. This was a silent, server-side change, not a disclosed fix.
  • Version 0.2.98 shipped July 12, 2026 with no changelog mention of the behavior.
  • As of this writing, xAI has issued no security advisory or public explanation, and it’s unclear whether repositories already sitting in that bucket will be deleted.

Why this is worse than a retention-policy dispute

If xAI were to defend this purely as a data retention question, ZDR exists, opt-out exists, that would miss the point. The researcher’s findings show the actual problem was upstream of retention entirely: the tool uploaded far more than the task required, a control that looked like the relevant toggle didn’t do what its label implied, and the fix was applied quietly rather than disclosed. Whether or not the data was ever used for training, the scope of what left each developer’s machine, full history, unread files, live credentials, was never something a user agreed to.

This is the pattern behind most “AI tool did something with our data” incidents. A safeguard may exist somewhere, but the interface never surfaces the real decision, and the label on a toggle doesn’t necessarily match its server-side effect.

Why coding agents are the highest-risk case for this failure

A chat interface has a natural consent boundary: you type something, you decide what to type. A CLI coding agent doesn’t have that boundary by default. To do its job well, it reads files and sends context. That’s the value proposition, more context, better output.

Which means the agent’s default behavior around what gets uploaded, how much, and whether a labeled toggle actually controls it is not an implementation detail. It’s the entire trust model. Grok Build’s case shows what happens when that default is “send the whole repository, including files never read and secrets never meant to leave the environment.”

What to check before giving any coding agent or CLI tool repo access

This incident is a useful checklist to run against any vendor with filesystem or repository access, not just this one:

  • Does the tool send only what the task needs, or does it bundle the full repository by default? A 5.1 GB upload for 192 KB of relevant context is the wrong ratio in either direction.
  • Do UI toggles match server behavior? A privacy setting that doesn’t change what the server actually does is worse than no setting, it creates false confidence.
  • Can your security team independently verify traffic, without relying on vendor-reported logs? The only reason this was caught at all was independent packet capture, not vendor disclosure.
  • What happens to data already collected before a fix ships? “We changed the default going forward” doesn’t answer what happens to the terabytes already in a bucket.
  • Does the vendor disclose silent fixes? A server-side flag flip with no advisory and no changelog entry means your security team has no reliable signal that anything changed, unless they’re re-testing constantly.

The broader lesson for anyone deploying internal AI agents

This isn’t really a story about one vendor. It previews what happens when any organization deploys AI agents against sensitive systems, code, contracts, financial records, without first deciding, explicitly and verifiably, what the agent is allowed to touch, how much it actually sends, and who can audit that independently of the vendor’s own claims.

The controls that would have prevented this backlash aren’t exotic:

  • default to sending only what a task demonstrably needs, not the full underlying dataset,
  • make sure a labeled control actually changes server-side behavior, and test that it does,
  • give security teams a way to verify data flows independently, not just a vendor dashboard,
  • disclose fixes and incidents, silent server-side patches erode trust further, they don’t restore it.

Enterprises deploying internal AI agents, for coding, procurement, or finance workflows, should hold their own tools to the same bar being applied to Grok Build in public right now. If your internal AI agent touches contracts, customer data, financial records, or credentials, verify these five points before rollout, not after a researcher finds out for you.