On July 12, a security researcher published wire-level analysis of xAI's Grok Build coding CLI. What they found should change how every team thinks about the AI tools touching their codebase.
Grok Build was uploading entire Git repositories — full commit history, tracked .env files, committed secrets, all of it — to a Google Cloud Storage bucket controlled by xAI. Not just the files relevant to the coding task. Everything.
To put a number on it: on a 12 GB repo, model-turn traffic came to roughly 192 KB. The storage channel moved 5.10 GiB. That's a 27,800x gap between what the model needed to do the job and what left the machine.
The researcher — publishing as cereblab — planted canary credentials in a .env file to test whether secrets were being captured. A fake API_KEY and DB_PASSWORD appeared verbatim in the intercepted traffic. Fake credentials, real proof.
The privacy toggle? Had no effect on the upload. The storage requests continued regardless of whether it was on or off.
What xAI did about it
Here's the part that should bother you even if you never installed Grok Build.
On July 13, xAI quietly flipped a server-side switch. The same 0.2.93 binary that was uploading repositories the day before stopped making storage requests. No new version shipped. No security advisory. No changelog entry. No notification to anyone who had used the tool. No confirmation about what happened to the repositories already in that cloud bucket.
Elon Musk addressed it on X and promised data would be deleted. As of this writing, there is no formal statement, no scope disclosure, no verification that deletion happened.
The disclosure hit the front page of Hacker News on July 14. That's how most affected developers found out.
This is, unfortunately, not a surprising playbook. It's what happens when "move fast" collides with "we never expected anyone to intercept our traffic."
Why this matters if you don't use Grok Build
You should read this even if Grok Build isn't in your stack. The incident is actually a useful lens for every AI coding tool your team is running.
Most of these tools have wide-ranging data collection that is technically disclosed in a terms of service document that nobody reads. What makes the Grok Build case different is that a researcher proved a measurable gap between what the tool appeared to be doing and what it was actually sending. The privacy toggle existed. It just didn't do what it said on the label.
There's no reason to assume Grok Build is uniquely bad here. There's also no systematic testing of the others. GitHub Copilot, Cursor, Windsurf, and others all transmit code to cloud infrastructure. Most have telemetry collection enabled by default. The extent of that telemetry, and whether privacy settings actually gate it, is not independently verified for most of them.
For teams with proprietary IP, NDAs, regulated data, or anything resembling credentials in their codebase — which is to say, most teams — this is a real exposure question, not a hypothetical one.
What to actually do about this
Audit what your devs are running. Start with a quick survey: what AI coding tools are active on developer machines? Grok Build, Cursor, Copilot, Windsurf, GitHub Copilot Workspace, others? Make a list. Most teams don't have one.
Check network traffic on dev machines. If you have a proxy or network monitoring in place, filter for storage-related API calls from developer endpoints. Tools making unusually large outbound requests during what should be small coding tasks are worth investigating. Wireshark or mitmproxy can do this at the machine level if you want to test a specific tool yourself.
Plant a canary credential and watch for it. Create a fake API key with a distinctive string — something like CANARY_TEST_9x4mR7 — and put it in a .env file in a test repo. Track whether that string appears anywhere it shouldn't. This is how cereblab proved the exfiltration. It's not hard to replicate.
Read the actual privacy settings, not just that they exist. If a tool has a "privacy mode" or "do not send telemetry" toggle, verify what it covers. Does it gate storage uploads? Model-turn data? Both? If the documentation doesn't say specifically, assume it doesn't do what you think.
Keep secrets out of repos. This is advice that predates AI coding tools by years, but the Grok Build incident makes it newly urgent. git-secrets, detect-secrets, or gitleaks can scan your repositories for committed credentials. Run one. Fix what you find. An AI tool that exfiltrates your repo shouldn't be able to walk off with real credentials.
Have a conversation with your team about what "trusting a tool" means. An AI coding assistant isn't a local process that stays on the machine. It is, by design, a cloud service. Code goes up. Results come down. The question is: how much goes up, to where, under what retention policy, and who can query it? That question deserves a real answer before you point the tool at your most sensitive repos.
The bigger pattern
This is the second major AI coding tool incident in the past two weeks. GhostApproval showed how a malicious repo can trick a coding agent into overwriting your SSH keys while showing you a harmless filename in the approval dialog. Now Grok Build shows how a tool can silently exfiltrate your entire codebase while its privacy toggle tells you it isn't.
The category of AI coding tools is moving extremely fast. The security review is not keeping pace with the shipping.
For teams that aren't large enough to have dedicated security staff, that gap falls on you to manage. Which means you need to know what's running on your developer machines, where it's sending data, and whether the controls it shows you actually work.
None of this requires abandoning AI coding tools — they're genuinely useful and the productivity gains are real. It does require treating them like what they are: cloud services with significant access to your most sensitive intellectual property.
If you want to know what AI tools your team is running and whether their data handling matches what you'd actually want, we help with that. Usually a sprint of work to map the exposure, tighten the defaults, and give your team a clear policy.