Cybersecurity

Rotate Every Secret Grok Build Ever Saw

A wire-level analysis found xAI's Grok Build CLI uploaded entire repositories, including a tracked .env file with live keys, to an xAI storage bucket - and the privacy toggle did not stop it. What every team that ran it owes its customers now.

CybersecurityBy Servola Tech Desk2026-07-146 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

Key takeaways

A wire-level test of xAI's Grok Build CLI version 0.2.93 found it uploaded 5.10 gigabytes of a repository the assistant was never asked to read, including a tracked .env file carrying live API keys and database passwords, so every credential in every repository ever opened with that tool should now be treated as disclosed to a third party and rotated this week.
The tool's privacy setting was not wired to the upload path: with "Improve the model" switched off, the server still reported trace_upload_enabled as true, which means the control on the screen was not the control on the wire.
xAI stopped the uploads on 13 July 2026 with a server-side switch, not a new client release, so the binary that teams had reviewed, pinned and approved was never the thing deciding what left the machine.
If the repository held personal data or credentials to systems that do, this is a processor disclosure under the GDPR and the clock on your own notification duty started when you learned of it, not when xAI fixes it.

The file that was never opened

The researcher planted a decoy. A single file, sitting in a test repository, that the assistant was never asked to open and never referenced: a canary. Then they put the traffic on the wire under a proxy and watched what Grok Build, xAI's coding CLI, actually sent home. The canary came back in the intercepted bundle. It had left the machine without ever being read.

The published wire-level analysis of version 0.2.93 describes two separate channels. The first is the one everybody expects from a cloud coding assistant: a model-turn channel that carries the files the agent genuinely reads, so it can answer. The second is a background storage channel that ships a snapshot of the whole workspace to a storage bucket, whether the agent looked at those files or not.

The gap between the two is the finding. On a 12 gigabyte test repository, the model-turn channel moved about 192 kilobytes. The background channel moved 5.10 gibibytes, in 73 chunks of roughly 75 megabytes each. That is a difference of roughly 27,800 times. One channel was doing the work. The other was copying the building.

Among the files that went was a tracked .env, the file convention that developers use to hold exactly the things that must never travel: API keys, database passwords. It went verbatim and unredacted.

The switch on the screen was not the switch on the wire

Every AI developer tool now ships a toggle that says some version of "help improve the model." It is the control that procurement asks about, that a data protection officer writes into the assessment, and that an engineering lead points to when someone asks whether the code is safe.

The researcher turned it off. Then they checked what the server thought. The settings endpoint kept returning trace_upload_enabled as true. The uploads carried on.

This is the part worth separating from the headline. The defect was not that a coding assistant sends code to a server, which is the entire premise of a cloud coding assistant and is why you read the terms before you install one. The defect is that the consent control and the data path were never connected to each other. The toggle governed training. The upload was a different pipe, and nothing on the screen reached it.

A control that does not control anything is worse than no control, because a team that sees it will stop looking.

A server-side fix is the real finding

On 13 July 2026 the uploads stopped. What is instructive is how. There was no new client release, no version bump, no changelog entry for users to review and approve. The same 0.2.93 binary simply stopped making storage requests, because the server started answering with a new flag that disabled the codebase upload. Elon Musk said the data already uploaded would be, in his words, "completely and utterly deleted."

Read that sequence again from a governance point of view. The behaviour of the software on your developers' laptops was changed remotely, by the vendor, without touching the artefact you approved. Which means it could have been changed in the other direction the same way, and it would have looked identical from your side.

This is the structural lesson, and it applies far beyond xAI. If a tool's data behaviour is determined by server-side flags, then reviewing the client once tells you what it did on the day you looked. It does not tell you what it does now. Pinning a version, reading the release notes and signing off is a process built for software that ships its behaviour in the binary. Most AI tooling no longer does.

xAI has not published why the uploads existed, how long the data was retained, who could reach it, or how many users were affected. Those four answers are what a customer needs to size the incident, and their absence is itself information.

What a European team owes its customers now

Start with the assumption that costs the least to be wrong about: treat every secret that lived in any repository opened with Grok Build as disclosed. Rotate API keys, database credentials, signing keys and tokens. Do it on the basis of which repositories were opened, not which files you think the assistant read, because the whole point of the finding is that those two sets are not the same.

Then check what else was in those repositories. Source code alone is a commercial problem. Personal data, or credentials that reach systems holding personal data, is a legal one. Under the GDPR, an AI vendor processing your repository on your instruction is a processor, and a copy of that repository landing in a storage bucket outside the agreed purpose is a disclosure you have to assess. Your duty to notify runs from when you became aware, and a vendor's remediation does not reset it.

Essential and important entities under NIS2 should treat this as a supply chain incident and log it as one, because that is what it is: a defect in a supplier's product that moved your data somewhere you did not choose.

None of this requires certainty about what xAI did with the data. It requires only that you cannot currently prove it did not matter.

How to buy an AI coding tool after this

The useful change is not a ban. Teams that forbid AI coding assistants outright mostly discover their developers installed one anyway, and now nobody is logging it. The useful change is to stop treating the client as the boundary.

Ask a vendor three questions before the next tool goes on a laptop. Which endpoints does it talk to, and can we see that on our own network rather than in your documentation. Can your server change what the installed client sends without shipping a new version, and if so, what tells us when it happens. If a setting is off in our tenant, what is the server-side representation of that setting, and will you let us verify it.

Then make the answers testable rather than contractual. A proxy and an afternoon produced this finding. That is a cheaper control than any assurance questionnaire, and it is the only one that measures behaviour instead of intent. Secrets, meanwhile, should not be in a repository a coding agent can see at all: environment injection at runtime and a managed secrets store turn this class of incident from a breach into a shrug.

The tools are worth having. What is not worth having is a review process that reads the label and never looks at the wire.

Frequently asked questions

Do we have to rotate secrets if we only used Grok Build on one small project?

Yes, if that project's repository contained credentials in tracked files. The upload was a snapshot of the workspace, not of the files the assistant read, so the size of the project and the amount of work you did with the tool are not what determines exposure. What determines it is whether a secret was sitting in the repository while the tool was running.

xAI says the data will be deleted. Is that enough to close this out?

It is not, for two reasons. A deletion promise is not a deletion record, and you cannot evidence to a regulator or a customer that a copy in a third party's storage was destroyed on the basis of a public statement. More practically, your notification duty under the GDPR runs from your own awareness, and a supplier fixing its product afterwards does not retire an obligation that already started.

Does this mean cloud AI coding assistants are unsafe to use in regulated work?

It means the client is not the security boundary and cannot be audited as if it were. A cloud assistant that is honest about sending code to a server, and whose settings demonstrably govern the traffic you can see on your own network, is a manageable risk. A tool whose data behaviour can be changed from the vendor's side without a release is one you have to monitor continuously rather than approve once.

The instinct after an incident like this is to argue about whether xAI meant it. That argument does not change a single thing you have to do. The repositories were copied, the secrets were in them, and the control that was supposed to prevent it was never connected to the pipe that did it. Rotate the credentials, log the incident, and from now on point a proxy at every AI tool before you point your developers at it.

xAIGrok BuildAI coding toolssecrets managementGDPRsupply chaindeveloper toolsdata exfiltration

Grok 4.5 Loses the Benchmarks and Wins the Bill

xAI launched Grok 4.5 at 2 and 6 dollars per million tokens, a third of Opus, and it finishes tasks with 4.2 times fewer output tokens. It loses the benchmarks and wins the bill.

3 min read

Artificial Intelligence

The Best Voice AI Is Not the One You Can Deploy

OpenAI launched GPT-Live, a full-duplex voice model rated better than Advanced Voice Mode, but the developer API is on a waitlist. The voice you can deploy this quarter is a different product.

4 min read

Digital Sovereignty

The EU Council Revived the Rule That Scans Private Messages

The EU Council revived the lapsed rule that lets providers scan private messages with AI. For owners, confidential communication is now a governance choice.

2 min read

← All articles