It Already Had Your Keys

On July 12, a security researcher published a wire-level analysis of Grok Build, xAI’s terminal coding agent, that traced what the tool actually sent home. According to that analysis and the reporting that followed, the agent was packaging developers’ entire tracked repositories, full Git history, committed secrets, and files it had never been asked to open, and uploading them to cloud storage. One estimate put the volume at roughly 27,800 times more than the coding task required. A separate, undocumented channel was reported to have sent several gigabytes to a bucket named for session traces. Credentials in tracked files, API keys, database passwords, cloud tokens, SSH keys, went in plain, unredacted form. The “Improve the model” toggle that looked like the off switch reportedly had no effect on any of it.

xAI’s response moved quickly. On July 14, Elon Musk posted that previously uploaded data would be deleted. Within days the company open-sourced the Grok Build harness under Apache 2.0. Security researchers noted that the code capable of transmitting entire codebases remained in the released build, held off by a server-side configuration flag the company can change without shipping an update.

Whether this was an aggressive telemetry default or something else is disputed, and this piece is not an attempt to settle intent. Treat every specific above as reported and still developing. The reason to write about it is not xAI. It is the mistake almost every organization running one of these tools is making at the same time, and will keep making after this particular story fades.

The wrong frame

Read as a breach, the story has a familiar shape: a vendor did something it should not have, users were exposed, the vendor is now cleaning up. File it, patch it, move on.

That framing misses the part that generalizes. The developers who ran Grok Build were not careless. Most organizations that allowed it did the thing their frameworks told them to do. They treated it as a tool. Someone evaluated the app, maybe checked it against an allow-list, maybe ticked the privacy setting, and approved it the way you approve a text editor or a linter. Those are shadow-IT controls, and they answer one question: is this piece of software permitted to be here.

That is the wrong question for what Grok Build actually is. It is not a text editor. It is an actor. It reads across your repository on its own initiative, decides which files are relevant, makes its own network calls, and runs with whatever access the developer who launched it already had. The controls that govern an app sit at install time and ask whether it may run. The risk in an agent sits at runtime and turns on what it does with the access it inherited the moment it started.

An agent does not request access. It inherits yours.

That is the sentence most governance frameworks have not absorbed. A normal application asks for narrow, declared permissions, and you grant them deliberately. An agentic coding assistant does not negotiate scope. It operates inside your session, with your credentials, your repository, your environment variables, and your reach into whatever systems your keys unlock. Its permissions are your permissions. Nobody granted them to the agent on purpose. They came with the session.

So the consequential decision, what this actor is allowed to read and where it is allowed to send it, was never actually made by anyone in the organizations affected. The vendor’s default configuration made it. The toggle that appeared to be the decision point was not wired to the behavior that mattered. The choice got installed by absence, and the cost landed on the developers who ran the tool and the companies whose credentials were in those repositories, none of whom were in the room where the default was set.

Where the control point moved, and why the org chart did not follow

For a decade, the model for governing new software has been procurement plus security review plus an allow-list. That model assumes the unit of risk is the application and the moment of risk is adoption. Approve the right apps, block the wrong ones, and you have done your job.

Agents break that assumption in two places. The unit of risk is not the application; it is the runtime behavior of an actor with inherited privileges. And the moment of risk is not adoption; it is every session, because what the agent reads and transmits is decided by its configuration and its autonomy, not by the one-time decision to allow it. An approved agent with a bad default is more dangerous than an unapproved app, because approval is exactly the signal that tells everyone else to stop asking questions.

This is why the exposure crosses functions and lands nowhere. Security owns the allow-list. Legal owns the data-processing terms. Engineering owns the developer’s toolchain. Procurement owns the vendor relationship. An autonomous coding agent with the developer’s keys touches all four and belongs to none of them, so the question of what it may do with what it can reach has no owner. It is governed, to the extent it is governed at all, by whatever the vendor shipped as the default.

The question that actually needs an owner

The useful question is not “do we allow Grok Build,” or even “do we allow AI coding assistants.” Those are app questions, and you will answer them and still be exposed. The question is: for any agent that runs with a developer’s privileges, what is it permitted to read, what is it permitted to send, where is it permitted to send it, and who signed for that.

That reframes the work from a yes-or-no on a tool to a standing decision about a class of actor. And it makes the governance concrete:

Treat coding agents as privileged service accounts, not as apps. Give them scoped, short-lived credentials rather than the developer’s ambient access. Keep long-lived secrets out of tracked files and Git history entirely, so that “the agent read the repo” and “the agent read our production keys” stop being the same sentence. Control egress: know, and constrain, where an agent is allowed to send data, rather than trusting a vendor toggle to mean what it says. Log what leaves. And name an owner for agent permissions, a single accountable person for the decision that currently no one is making.

None of that requires banning the tools, and none of it depends on trusting any particular vendor’s conduct. It assumes the opposite of trust: that the default will be set by someone whose interests are not yours, and that your job is to decide the parts that matter before the agent runs, not after the analysis is published.

What this is and isn’t

This is not an argument that agentic coding tools are unsafe and should be avoided. They are useful, they are already in your engineering org whether or not they were approved, and the productivity is real. It is an argument that they are a different kind of thing than the software your controls were built for, and that governing them as apps guarantees the gap the Grok Build story exposed.

The wrong default here was not one company’s upload setting. It was the assumption, everywhere, that approving an actor is the same as governing it. That assumption is quiet, it is widespread, and it is being made right now in organizations that will read the Grok Build headlines as someone else’s problem.

Unowned decisions do not stay unowned. They get inherited by default, and so, it turns out, do your keys.

Reporting on the Grok Build transmission behavior reflects a wire-level analysis published July 12, 2026 and subsequent coverage; xAI’s deletion commitment (July 14) and open-sourcing of the harness are as reported. Specifics remain developing and are presented as allegations and findings, not settled fact. This piece is about governance practice, not a determination of intent.