One Person on Your IT Team Used Grok. Your Repo Is in Someone Else's Bucket.

Breaking and still developing. This is written as of 14 July 2026. The wire-level evidence landed on 12 July, the collection behaviour stopped on 13 July, the vendor responded on X on 14 July, and further analysis is still being published. Everything below is sourced to captured evidence rather than to reporting, and the limits of that evidence are stated explicitly. New facts will land after this is published. Verify current state before acting on any specific claim about what a vendor is doing today.

The urgency is not the news cycle. It is your clock. If anyone in your organisation ran this tool against a repository containing secrets, those credentials should be treated as transmitted and rotated now, regardless of any deletion promise. If EU personal data sat in one of those repositories, a regulatory deadline may already be running. Both of those are true today, whatever comes out tomorrow.

The call you do not want to get

The call is not "we had a breach." It is worse than that. A large enterprise, a brand you would recognise, and the sentence is:

That is the whole incident. There was no attacker, no vulnerability, and no phishing email. One capable engineer, working faster, installed a coding CLI on a machine that touches sensitive corporate systems and pointed it at a repository. Everything tracked in that repository, plus its full commit history, plus whatever was ever committed and later deleted, left the network and landed in cloud storage controlled by a company that organisation has no contract with, no data processing agreement with, and no relationship with at all.

Nobody did anything wrong by the standards they were held to. There was no policy against it, because nobody thought to write a policy against a tool the company does not use.

This is why the right reaction to the news is not "are we a Grok shop." It is "does any person with access to sensitive systems run anything we did not put there."

For most organisations, the honest answer is yes. Verizon's 2026 Data Breach Investigations Report, published in May, found that 45% of employees are now regular AI users on corporate devices, up from 15% the year before, and that 67% of them reach those services through non-corporate accounts. Shadow AI is now the third most common non-malicious insider action in Verizon's data-loss-prevention dataset, a fourfold rise year over year. The single most common category of data those employees send to external AI models is source code.

If you are not technical, this is the part that matters

Strip out the terminology and the incident is simple.

A company's source code lives in a repository. Think of it as the filing cabinet holding everything the business has ever built: the product, the internal systems, the configuration, and, in most organisations, a few passwords and access keys that were saved in the wrong place years ago and never cleaned up. It is one of the most valuable and most sensitive assets a company owns, and it is also a record of every version of itself, so a password deleted three years ago is still sitting in the history.

An AI coding assistant is a tool that reads some of those files to help an engineer work faster. Sending the file it is working on to the AI provider is normal and expected. That is the product.

What the evidence shows is that this particular tool did something else at the same time. Alongside the handful of files it needed, it quietly packaged up the entire filing cabinet, history included, and shipped it to storage owned by the AI company. On one test, the tool sent roughly 27,800 times more data than the task required. It did it even when the engineer explicitly told it not to open any files. And the privacy setting the user was given, the one a reasonable person would read as "do not take my data," did not stop it, because that setting controlled something else entirely.

So the three things a non-technical executive needs to hold:

Your people did nothing wrong. The engineer followed every rule. The tool did something in a channel no human could see, consent to, or switch off.

Your exposure is your history, not your current files. Anything ever committed to that repository is potentially gone, including credentials someone deleted long ago and assumed were safe.

The vendor's promise is not a control. The behaviour was switched off remotely, without a software update. Whatever can be switched off remotely can be switched back on the same way, and the customer would not know either time.

The rest of this piece is what was proven, what was not, and exactly what to do in the next 72 hours.

What was actually proven

Precision matters here, because the story has been reported loosely and the loose version will get you laughed out of a security review.

A researcher publishing as cereblab routed the Grok Build CLI (version 0.2.93) through mitmproxy on their own machine, against their own throwaway repositories, using fake canary secrets. They published the full wire-level teardown, the captured artifacts, SHA-256 hashes, and a reproduction harness anyone can run.

There were two separate channels. Channel A is the model turn: the files the agent actually reads, sent so it can answer. Every cloud coding agent does this, and it is not the story. Channel B is a separate whole-repository upload to a storage endpoint. That is the story.

The byte split is the proof. On a 12 GB repository of random files the agent never read, the model channel moved about 192 KB. The storage channel moved 5.10 GiB across 73 chunks, every one returning HTTP 200, still climbing when the capture was cut off. The upload tracks repository size, not task size, which means it cannot be explained as context.

The decisive test. Given the prompt "Reply with exactly: OK. Do not read or open any files," the CLI uploaded the entire repository as a git bundle. Cloning that captured bundle recovered a planted file the agent had been told not to open, marker verbatim, plus the full commit history. Replicated on a second, unrelated repository, same result.

The toggle did nothing, and the read files were not redacted. With "Improve the model" switched off, the primary user-facing privacy control, the repository still uploaded and the server still reported trace_upload_enabled: true. The opt-out governs training. It never governed transmission. Separately, a tracked .env containing canary API_KEY and DB_PASSWORD values went across verbatim in the model channel and was packaged into an archive bound for storage.

Now the part most coverage skipped, and the part that will keep you from overclaiming.

What was not proven. The captures establish transmission, acceptance, and storage. They do not prove that SpaceXAI trained on the code, that any employee read it, or that gitignored-and-never-committed files were swept in. The researcher is explicit about all three. The canary values were formatted strings rather than real high-entropy tokens, so the test does not establish that no format-aware redactor exists for, say, an sk- shaped key.

And the mechanism is git, which cuts both ways. "Whole repo" means tracked files plus history. A file that was gitignored and never committed stayed out of the bundle. A secret that was committed once in 2023 and deleted the next day is in the history, and therefore in the bundle. Deleting it later did not pull it back.

That last sentence is the one that determines your blast radius.

Why this is not just normal telemetry

Cloud coding agents send code to a server. That is not news, it is the product. Three things separate this from routine telemetry.

The collection was decoupled from the task. The tool sent the codebase, not the context, and kept uploading after the model was rate-limited and had stopped answering.

It was not the category default. The same researcher ran the identical canary harness against Claude Code, Codex, and Gemini CLI, and none of them produced a whole-repo bundle, leaked the never-read canary, or carried the deleted-history secret. Every one of those tools is still a cloud tool that transmits the files it opens, so "local only" remains the wrong mental model for all of them, and the comparison is version-specific and time-bound. But wholesale workspace collection was specific to one product, which makes it a vendor choice rather than a law of physics.

And the one control users were given governed the wrong thing. "Improve the model" is a training-consent control. Users read it as a data-collection control. Those are different mechanisms at the architecture level, and only one of them was ever exposed.

Where it stands now, and this is still moving. The upload has since stopped. Not through a client update, but through a server-side flag (disable_codebase_upload: true) delivered to the same unchanged binary. Nobody has established why, and the researcher is careful not to claim credit for it. What is documented is the sequence, not the cause. The company responded publicly on X rather than through a security advisory, pointing to Zero Data Retention for enterprise and API-key use, and to a /privacy CLI command for everyone else that it says disables retention and deletes previously synced data. Elon Musk separately posted on 13 July that all previously uploaded user data would be "completely and utterly deleted," in response to the wider controversy rather than as a specific commitment about repositories.

Take all of that at face value and it still does not close your exposure. The mitigation was verified on a single account, with no confirmation that it is global or permanent. Follow-up analysis of a later build found the upload code still present in the binary, dormant behind a server flag, which means it can be re-enabled without shipping an update. And deletion of a stored copy does not un-transmit a credential.

There is no way for a customer to independently verify the deletion. If your board asks whether the code is gone, the honest answer is that you cannot know, which is precisely why the response below runs on rotation rather than on trust.

Your policy did not fail. Your policy was never in the path.

Here is the structural point, and the reason a governance policy would not have saved the organisation in that opening phone call.

Their AI policy, if they had one, said something like "do not put company data into unapproved AI tools." That is aimed at a human decision: do not paste the thing. Their engineer did not paste anything. Their engineer told the agent not to open any files, and the repository left anyway.

The exposure came from the tool's architecture, in a channel the human could not see, could not consent to, and could not have opted out of even if they had wanted to. A policy that governs behaviour cannot stop a mechanism that operates below behaviour.

This is the thing for a C-suite to absorb. You cannot train your way out of it and you cannot policy your way out of it. Your people can do everything right and still lose the codebase, because the thing that needed governing was never the person. It was the network boundary.

What to do in the next 72 hours

Hand this to whoever owns security. It is ordered by what is bleeding.

One point of sequencing first, because it is the most expensive mistake available here. If personal data of EU residents sat in any affected repository, the GDPR clock starts when you have a reasonable degree of certainty that a security incident has compromised personal data, not when your investigation finishes. Failing to notify is a standalone violation, separate from the breach itself, carrying up to EUR 10 million or 2% of global turnover under Article 83(4). Do not let a technical investigation quietly run past a legal deadline. Get counsel and your DPO in the room on day one, not at the end.

Hour 0 to 4. Find out whether it happened. Do not ask people. Ask the network and the endpoints. Query EDR and endpoint inventory for the binary and the install path (~/.grok/). It installs to a user directory and needs no admin rights, which is exactly why it will not appear in your software asset inventory. Pull outbound proxy and DNS logs from developer machines for the CLI API hosts and for storage.googleapis.com. You are looking for large, sustained POST volume from an endpoint with no business generating it. The destination bucket named in the captures is grok-code-session-traces. Check for the local staging directory, ~/.grok/upload_queue. It stages snapshots per turn and can grow to tens of gigabytes, which is not subtle once you look. Personal devices and personal accounts are in scope. Netskope’s Cloud and Threat Report 2026, published in January and covering October 2024 to October 2025, found that 47% of generative AI users still work through personal, unmanaged accounts. Your MDM boundary is not your exposure boundary.

Hour 4 to 24. Establish blast radius. For every repository opened in the tool: the unit of exposure is the git history, not the working tree. Run history-aware secret scanning across the full commit graph rather than the current checkout: gitleaks detect --log-opts="--all", or trufflehog git file://<repo>. A secret committed and reverted three years ago is in scope. Inventory what those repos carry beyond code: hardcoded connection strings, seed data and fixtures holding real customer records, .env.example files that were never actually examples, test fixtures containing real PII (far more common than anyone admits), infrastructure-as-code with embedded tokens, and internal architecture and network topology. PII in a fixture file is not an intellectual-property problem. It is a different regulation and a different clock, which is why counsel is already in the room.

Hour 24 to 72. Rotate. Rotate every credential in scope, history included, regardless of any deletion promise. A stored copy being deleted does not change the fact that the secret was transmitted. Its integrity is gone. Treat it as burned. Run the vendor’s own control as a belt-and-braces measure, never as a substitute for rotation: for anyone who used the tool, /privacy in the CLI, per the vendor’s stated guidance, changes retention settings and triggers deletion of previously synced data. And document the decision either way. If you assess that notification is not required, the reasoning has to be written down. Regulators audit the register, and a missing entry for a known incident reads worse than a documented low-risk one.

Then, and only then, decide about the tool. The instinct will be to ban it. Resist that for a moment. When approved alternatives exist, unauthorised AI use drops. When they do not, a ban produces exactly the behaviour you are trying to stop, on personal devices, where you have no visibility at all. Your engineer reached for that tool because it made them faster and you had not given them a sanctioned way to be that fast.

The toggle is not the control

Everything above is incident response, and incidents pass. This part does not.

A vendor's privacy setting is a statement of intent. Your network boundary is a control. One of those is enforceable by you. The other is enforceable by them, and they can change it with a server-side flag, without shipping an update, and without telling you.

That is not hypothetical. It is mechanically what happened here, in both directions. The upload was on by default and invisible, then off by server flag and invisible, with the same binary, the same version number, and the same user producing different behaviour. At no point did the customer have a say, any visibility, or a way to verify.

If the only thing standing between your source code and a third party's storage bucket is a checkbox in someone else's product, you do not have a control. You have a preference, held on your behalf, by a company whose incentives are not yours.

What a real AI data boundary looks like

This is not exotic, and that is what makes the incident embarrassing for the industry. The controls that would have caught it are mature, mostly open source, and cheap. They were simply never applied to AI tooling, because AI tooling arrived through the developer's laptop rather than through procurement.

Four layers, in priority order by what stops the most for the least effort.

Layer 1. Default-deny egress on any machine running an AI agent. The agent gets a proxy and an allowlist, and no other network path. Twelve domains is a realistic allowlist for real development work. A whole-repo upload to an undisclosed storage bucket does not survive contact with default-deny egress, because the destination is not on the list. This is the highest-leverage control available and most organisations do not have it.

Layer 2. Never let the agent hold the real credential. Secrets get injected at the boundary and the agent works with proxy tokens that are worthless off the machine. If the agent cannot read the real secret, it cannot transmit the real secret, and the entire .env finding in this incident becomes a non-event.

Layer 3. Repository hygiene as a security control, not tidiness. Secrets never enter git, enforced by pre-commit hooks and history-aware scanning. This is a direct read of the incident's mechanics: the bundle carries tracked files plus history. Gitignored and never committed stayed out. Committed once, ever, and it ships. Your git history is an attack surface, and it is the surface this incident actually hit.

Layer 4. Verify on the wire before you trust the docs, and again after every update. The reason we know any of this is that one person spent an afternoon with mitmproxy and a canary repository. A canary file with a unique marker, a proxy, and a grep. Any competent engineer can run it, almost no enterprise does, and the result is that vendor behaviour is taken on faith right up until someone publishes a gist. A marketing claim of "local-first" is not a security finding. What crosses the network is a matter of fact, and facts are testable.

The question to ask every AI vendor now

The evaluation question everyone has been asking is "do you train on our data?" It is now demonstrably insufficient. It was answered here by a toggle that worked exactly as described and protected nothing, because it governed training while the exposure sat in transmission.

Ask this instead, of every AI vendor, every AI feature shipped into a platform you already run, and every coding agent your engineers install:

Then hold it against the questions that actually determine exposure. What infrastructure is this running on, and where. What data leaves our tenant when the feature is enabled, as distinct from what the feature needs. Is it training on our data (necessary, nowhere near sufficient). Can we turn it off fully, at the transmission layer rather than the consent layer. And what happens at renewal, or at the next release, when this stops being optional or the default flips.

Everything downstream of the model is where the exposure lives. This incident is the cleanest available demonstration of that, because the model was never even sent the data. It still left.

Where this leaves us

Three things are true at once. The report is rigorous, reproducible, and unusually careful about the limits of what it proves. The collection behaviour has stopped, though through a mechanism that can be reversed as silently as it was applied. And none of that helps the organisation whose repository, history, and whatever personal data was sitting in a test fixture left the building last week because one competent person on the IT team was trying to work faster.

The incident will fade. The class of problem will not, and it is not really about one company's coding tool.

Every AI tool that reads local files is simultaneously a file reader, a network client, a shell, a credential holder, and a frontend to somebody else's infrastructure. That trust boundary did not exist in your estate three years ago. In most enterprises it is currently governed by a policy document and the good judgment of whoever installed the tool, and you now have a very public, very well-documented example of what that costs.

Kerrigan Baron leads solutions at AtomDigit. We build AI systems with the data boundary designed in rather than bolted on: how we work.