Grok Build’s Repo Upload Scandal: Deletion Is Not a Privacy Control

CEREBLAB gave Grok Build CLI v0.2.93 an idle task: “reply OK, do not open any files.” The agent replied—but its network traffic did something else.

The client packaged the repository as a Git bundle and sent it to cloud storage. CEREBLAB cloned the captured payload and recovered 47 files, four commits, and the file the agent had been told not to read (CEREBLAB, July 13, 2026).

That test turns a fuzzy privacy debate into an engineering question: what can leave the machine when the task requires nothing?

A promise to delete data later cannot replace a boundary that prevents unnecessary transmission now.

One incident, four different controls

Coverage of coding-agent privacy often compresses four controls under the word “privacy.” Teams need to separate them.

1. Task access: which files, commands, secrets, and repositories the agent can reach.
2. Transmission: which bytes may leave the machine and which destinations may receive them.
3. Retention: what a provider stores after receiving those bytes, for how long, and for what purpose.
4. Remote control: which client behaviors a provider can change through server-delivered configuration.

These controls fail independently. A workspace permission can limit access without limiting network traffic. A zero-retention setting can reduce server-side storage without stopping transmission. An open client can expose a code path while a remote flag still decides whether that path runs.