The Training Opt-Out Is Not a Data-Egress Control

A 12 GB repository produced 5.10 GiB of upload traffic, split across 73 chunks of roughly 75 MB each, every one returning HTTP 200. The training opt-out was on the whole time. A reproduced wire-level audit of a vendor coding CLI (xAI’s Grok Build CLI, per the audit) captured exactly that on the network, and the researcher recovered the uploaded data verbatim afterward, including files the agent was told never to open and an unredacted .env, by running git clone against the vendor bucket.

The audit (cereblab, July 2026) draws one line that a governance team should copy into its threat model: “Opting out does not stop your repository from leaving the machine.” A second researcher reproduced the capture independently. Treat this as a wire observation, not a statement of vendor intent. There is no evidence the vendor trains on the data. The finding is narrower and, for anyone shipping code with these tools, worse: the toggle you clicked governs one thing, and the bytes leaving your machine are a different thing.

What the Toggle Actually Controls

“Opt out of training” is a promise about a downstream use of data. It says the vendor will not feed your content into a model update. It says nothing about whether the content leaves your machine, where it lands, how long it persists, or who can read it there. Those are egress questions, and the toggle sits nowhere near the egress path.

The audit makes the distance measurable. Two channels left the machine during the session. The model-turn channel, the actual conversation the agent had with the model, carried 192 KB. The storage channel, the repository upload, carried 5.10 GiB. That is roughly 27,800 times more data going to vendor storage than the model reasoning ever touched. The agent did not need the whole repo to answer. It shipped the whole repo anyway.

So the mental model most teams carry, that the tool reads the files it needs and the opt-out keeps the rest private, is wrong on both halves. The tool uploaded files it never opened. And the opt-out, being a training control, never had an opinion about the upload.

Consent Expressed as a Setting Is Not Enforcement

A UI toggle records an intention. Enforcement is a property of the runtime that carries the bytes. When those two live in different layers, the intention is decoration.

This is the same failure we described in prompt governance that never reaches the runtime: a policy stated in one place, an action taken in another, and nothing in between forcing the action to obey the policy. A setting that says “do not train” while the process opens a 73-chunk upload stream to vendor storage is that pattern in its purest form. The user consented to one thing. The runtime did another. No component reconciled them because no component was positioned to.

The recovered .env is where this stops being abstract. Secrets that were never meant to leave the developer’s disk were sitting in the vendor bucket in plaintext, alongside full git history and the files explicitly marked do-not-open. Anyone with read access to that storage, vendor staff, a misconfiguration, a future breach, holds working credentials to whatever those secrets unlock. The training question is irrelevant to that exposure. The data left, and now its safety depends entirely on someone else’s storage posture.

Why the Whole Repo Leaves

The audit does not need a malicious explanation, and neither does your risk assessment. A coding agent that wants good context has an obvious incentive to sync the working tree to a place it can query cheaply. Uploading everything once is simpler to build than deciding, file by file, what is relevant. The 75 MB chunks and the clean run of 200s look like a straightforward, well-functioning sync, not an exfiltration exploit.

That is precisely why it is dangerous. The behavior is a design default, not an attack, so it triggers no alarm and survives every review that only asks “is the vendor trustworthy?” The vendor can be entirely honest about not training and this upload still happens, because the upload was never the thing the training promise covered. Convenience, not malice, is what moves your repository off the machine.

The Boundary Has to Be Where the Bytes Are

If the setting cannot stop the egress, something in the egress path has to. That means enforcement at the layer where the tool actually makes network calls: the process boundary and the network it sits on.

Concretely, that is egress filtering the agent runtime cannot talk itself out of. A coding CLI that has no route to arbitrary vendor storage cannot upload 5.10 GiB to it, regardless of what its internal sync logic wants to do. This is the same principle behind keeping credentials off the agent entirely, which we covered in credential exchange as a containment primitive: do not trust the runtime to volunteer restraint, remove its ability to do the dangerous thing. There the removed capability is a standing secret. Here it is an open path to bulk upload.

The building blocks already exist. An allowlist of egress destinations at the network layer, so the agent reaches the model endpoint and nothing else. Traffic inspection that flags a gigabyte-scale upload before it completes rather than after. A sandbox that mounts only the files a task needs, so “the whole repo” is not even present to be shipped. None of these depend on reading a vendor’s privacy policy correctly. They hold whether or not the vendor is honest, and they hold across every tool, because they sit below the tool.

Do This Now

Run the audit on your own tools. Put a coding CLI you use behind a proxy that logs egress, point it at a repo seeded with a canary secret and a file named do-not-upload, and watch what leaves. The wire tells you what the settings page cannot. If bytes you did not authorize reach a destination you did not choose, you have found a boundary that lives in the wrong layer.

Then move the boundary. Default-deny egress for agent runtimes, allowlist the model endpoint, and mount task-scoped file sets instead of whole working trees. Stop treating a vendor’s training toggle as a data-egress control; it was never built to be one. The question for your next architecture review is not “did we opt out of training?” It is “what stops this process from uploading the repository, and is that thing something we control?” Everything that answers “the vendor’s setting” is a boundary you do not own. Everything that answers “our egress policy” is one you do.

---

This analysis synthesizes What xAI Grok Build CLI actually sends to xAI (cereblab, July 2026).

Victorino Group helps teams enforce data boundaries at the runtime, not the settings page. Let’s talk.