A security researcher pointed a proxy at xAI's official Grok Build coding CLI, gave it a repository, and typed a deliberately boring prompt: "reply OK, do not read any files." The tool replied OK. Then it packaged the entire repository as a git bundle and uploaded it to a Google Cloud Storage bucket. When the researcher cloned that captured bundle back, a file the agent had been explicitly told not to open came back verbatim, unique marker and all, along with the full git history.

That is the headline from a wire-level analysis of Grok Build CLI that climbed to the top of Hacker News this week. It is worth reading in full, because it is careful in a way most "AI tool leaks your data" posts are not. And the careful version is more useful to a business owner than the panicked one.

What the analysis actually proved

Running xAI's Grok Build on a normal consumer login, the researcher documented three things with captured traffic, byte counts, and repro commands:

First, when the agent reads a file, the contents go to xAI unredacted. That includes a .env secrets file, which showed up verbatim in the model-turn request body. Second, and more surprising, the whole repository gets uploaded separately, independent of anything the agent reads. On a 12 GB repo of random files the agent never touched, more than 5 GiB moved through the storage channel while the model conversation itself carried only 192 KB. The upload tracks the size of your codebase, not the size of your task. Third, the destination is a bucket named grok-code-session-traces, the behavior is on by default, and turning off the "Improve the model" setting did not stop it.

Here is the part that earns the analysis its credibility: the author stops short of the dramatic claim. Nothing here proves xAI trains on your code. What is proven is transmission, acceptance, and storage. That restraint matters. A finding that says "your repo is uploaded and stored by default" is strong precisely because it does not need to reach for "and they're stealing your IP" to land.

This isn't really a story about one vendor

It is tempting to file this under "Grok problem" and move on, especially if your team uses something else. That is the wrong lesson.

The real story is that an AI coding tool authenticated with a consumer login, installed with a one-line curl command, moved gigabytes of a private codebase off the machine, and none of it surfaced in the install or quickstart materials. The behavior wasn't hidden behind a hack. It was the default. Whatever tools your developers reach for, the same question applies: when someone on your team installs an AI CLI or editor and clicks "sign in," what leaves the building, and where does it land?

Most owners have never asked, because the honest answer requires reading retention terms that vary wildly between a free consumer tier, a paid API key, and an enterprise agreement with a zero-retention clause. Same brand, very different data handling. The tool doesn't advertise which one you're on while it's working.

The cousin you may have already met

If this feels familiar, it should. A few days ago we wrote about an AI agent that leaked private repos after reading a poisoned public comment. That was an attacker hijacking an agent through malicious input. This is the opposite shape of the same problem: no attacker, no trick, just a tool phoning home in normal operation. One is someone reaching in. The other is the tool reaching out. Both come down to a boundary nobody drew on purpose: what your AI agents are allowed to send, and to whom.

Developers are starting to build that boundary themselves. A recent Laravel News walkthrough, I Tricked My Own AI Into Leaking Everything, shows the pattern taking shape: tool-level authorization so a lookup physically cannot return another user's data, plus output filtering that redacts secrets before a response ever leaves the system. Guardrails as middleware, not as a hope.

What an owner should actually do

None of this means banning AI tools. The productivity is real and your competitors are using them. It means treating the data flow as something you decide rather than something that happens to you. A short, unglamorous checklist covers most of the risk:

Inventory what's in use. List the AI coding and writing tools your team touches and how each one authenticates. Consumer login, personal API key, and company enterprise seat are three different risk profiles, and you probably have all three in the building.

Know your tier's retention terms. For each tool, find out what it stores and for how long on the plan you're actually on. If you can't tell, assume the least private answer until you confirm otherwise.

Keep secrets out of the repo regardless. This one predates AI. Real credentials belong in a secrets manager or environment vault, not in a tracked file. Do this and a repo upload leaks your code, which is bad, but not your production keys, which is a very different Monday.

Write the one-page policy. You don't need a legal document. You need a page that says which tools are approved for which kinds of code, and who to ask. We made the case for the one-page shadow-AI policy when Microsoft shipped Agent 365, and it holds here.

For sensitive work, choose tools that let you draw the line. That can mean a contractual zero-retention tier, a self-hosted model, or middleware that filters outbound content. The point is that "what leaves our systems" becomes a setting you control, not a bucket you discover.

Where this connects to the work we do

When we build AI integrations or custom MCP servers for clients, the boundary of what data leaves their systems is a design decision we make on purpose, up front, in writing. Which model sees what, what gets logged, what never goes to a third party at all. That is not a compliance chore bolted on at the end. It is the difference between an AI feature you can stand behind and one that quietly uploads your work to a bucket you'll read about on Hacker News.

The Grok Build analysis is a good thing, not a scandal. Someone did the tedious work of watching the wire and writing down exactly what happened, with receipts and without exaggeration. The uncomfortable part is that almost no owner has that visibility into the tools already running on their own machines. You don't need a proxy and a canary repo to fix that. You need to ask the question before the tool answers it for you.

Not sure what your team's AI tools are sending or storing? Start a conversation and we'll help you map it.