If you installed xAI's Grok Build coding CLI on a development machine anytime before July 10, there's a reasonable chance it quietly shipped your entire Git repository — commit history, .env files, SSH keys, and whatever else happened to be sitting in the working directory — to a Google Cloud Storage bucket you never agreed to send anything to. That's not a hypothetical. It's what a security researcher demonstrated with wire-level network traffic captures, and it's the first half of a two-part failure that also produced a remote code execution vulnerability within a day of xAI open-sourcing the tool. For engineering leaders currently evaluating AI coding assistants for team-wide rollout, this incident is worth studying in detail, because it touches nearly every trust assumption those evaluations tend to rely on.
What the researcher actually found
On July 10, 2026, a security researcher published network traffic evidence showing that Grok Build — xAI's coding-agent CLI — was silently uploading complete Git repositories to a Google Cloud Storage bucket named grok-code-session-traces. This wasn't a case of the tool sending back the specific files it had read or modified during a session. The capture showed uploads of entire working directories, including data with no plausible connection to an AI coding session: full commit history, .env secrets files, SSH private keys, password-manager databases, and personal documents and photos that happened to be present in the same directory tree the tool was pointed at.
Two details push this from "concerning telemetry" into something closer to a bulk-collection story. First, the upload behavior was reportedly independent of what the agent actually used. Whether the AI touched a given file during a session or never referenced it at all, it went out the door anyway — the collection wasn't scoped to relevance, it was scoped to "everything reachable from the working directory." Second, and more damning, the uploads reportedly continued even after users disabled the tool's "Improve the model" privacy toggle — the exact setting a user would reasonably expect to govern this behavior. A control that visibly exists in the settings menu but doesn't actually stop the underlying data flow isn't a bug in the ordinary sense. It's a broken trust boundary between what the product claims to do and what it does.
The 27,800x ratio is the real story
The single number that should stop any security team mid-sentence is this: analysis of the traffic found that the exfiltration transferred roughly 27,800 times more data than the actual model conversation and session traffic combined. Put differently, for every byte of data plausibly tied to the AI interaction itself — the prompts, the responses, the reasoning trace — roughly 27,800 bytes of unrelated material left the machine.
That ratio matters because it forecloses the most charitable explanation available for this kind of incident. Overly broad telemetry is a common and often forgivable mistake — a debug flag left on, a logging scope that wasn't narrowed before shipping, a session trace that accidentally includes more file content than intended. Those mistakes tend to produce modest overcollection: some extra context, a few adjacent files, maybe an entire directory when only one file was needed. They do not tend to produce a 27,800x multiplier. A ratio that large is far more consistent with a system that was built to harvest entire codebases as a matter of design, with the "session trace" framing functioning as cover for what the data flow actually was. Whether or not that was xAI's explicit intent, it's the only technically plausible read of a number that size, and it's the detail that should reframe how buyers evaluate the rest of the incident.
Open-sourcing exposed a second, worse problem within a day
xAI's initial response to the mounting scrutiny was to open-source Grok Build under the Apache 2.0 license on July 15, 2026. Transparency through source availability is generally a reasonable move after a trust failure — it lets outside researchers verify the tool's behavior directly instead of relying on the vendor's account of what it does. In this case, it worked exactly as intended, just not in xAI's favor.
One day later, on July 16, a researcher auditing the newly published source code identified two separate attack chains that enabled arbitrary code execution with zero user interaction. Both worked by abusing project-level configuration files to bypass Grok Build's trust mechanism — the safeguard meant to distinguish trusted projects from untrusted ones before letting the agent execute anything on the developer's behalf. Critically, triggering the compromise reportedly didn't require running a command, approving an agent action, or doing anything an engineer would recognize as risky. Simply opening a malicious project directory in the tool was enough. For a coding assistant that engineers are encouraged to point at arbitrary repositories — including third-party code, cloned dependencies, and unfamiliar client projects — a zero-interaction RCE triggered by directory-open is about as bad as the threat model gets.
The sequence matters as much as the individual flaws. A silent, high-volume data exfiltration issue became public on July 10. xAI's response, five days later, was to open the source. The very next day, the newly visible code yielded a code-execution vulnerability that had presumably existed in the closed-source version all along — it just hadn't been found yet. Open-sourcing didn't introduce the flaw; it revealed a flaw that had already been shipping to users, and it did so almost immediately once real scrutiny was possible.
xAI's response and what's still unknown
xAI's disclosed remediation was to disable the upload feature server-side and introduce a new configuration flag, disable_codebase_upload, giving users an explicit switch to prevent the behavior going forward. That's a meaningful technical fix for the exfiltration path, and disabling the feature at the server level rather than waiting for a client update meant it took effect immediately rather than requiring users to upgrade.
What it doesn't address is everything that already happened before July 10. As of the reporting available, xAI has not disclosed how many users were affected by the silent uploads, has not clarified its data-retention policy for material already sitting in the grok-code-session-traces bucket, and has not confirmed whether previously harvested repositories, secrets, or personal files have been deleted. For any engineering organization that had Grok Build installed on developer machines before the fix, the practical implication is that a fix going forward does not retroactively account for what left the network already. Any .env files, SSH keys, or credentials that were uploaded prior to July 10 should be treated as compromised and rotated, regardless of what xAI eventually discloses about retention.
Why privacy toggles that don't work are worse than not having one
It's worth dwelling on why the "Improve the model" toggle failure is arguably the most damaging detail in this whole incident, more so than the raw volume of data collected. A tool that collects too much data by default, with no opt-out at all, is a bad product decision that a security team can at least reason about and mitigate — block the domain, don't deploy the tool, demand a fix. A tool that presents a working-looking control, lets the user believe they've turned data collection off, and continues collecting anyway removes the ability to reason about the system at all. Every other setting, permission, and toggle in that product now has to be independently verified rather than trusted, because the vendor has demonstrated that at least one control doesn't do what its label says. That's the deeper cost of this kind of failure: it doesn't just expose data, it invalidates the mental model a user built around the product's stated behavior.
A vetting framework for AI coding tools
This incident is a useful prompt for building — or tightening — a formal vetting process before any AI coding CLI or agent gets approved for engineering use. A few concrete practices worth adopting:
- Audit actual network traffic, don't rely on documentation. Run the tool in a monitored environment and capture what it actually sends, to which endpoints, and how that compares to what the privacy policy claims. This is precisely how the Grok Build issue was caught — independent traffic analysis, not vendor disclosure.
- Test privacy toggles empirically. Don't assume a setting labeled "disable data collection" or "improve the model: off" actually stops the underlying data flow. Verify it with the same traffic capture used above, before and after toggling.
- Get data-handling commitments in writing, contractually. What gets collected, what's retained, for how long, and under what deletion policy — as explicit contract terms, not just marketing copy or a general privacy policy page.
- Sandbox first, deploy second. Run new AI coding tools in isolated environments with no access to real secrets, credentials, or production repositories until their actual behavior has been independently verified.
- Weigh source availability, but don't treat it as a finish line. Open-source code enables outside audits — that's exactly how the RCE chains were found — but availability alone guarantees nothing about what's already been found or fixed. Assume unaudited open-source AI tooling has unknown vulnerabilities until proven otherwise.
- Ask what happens to data already collected before a fix ships. A patch that stops future collection doesn't answer what happens to everything gathered before it. Push vendors for explicit retention and deletion commitments covering the pre-fix period.
The takeaway for anyone rolling out AI coding tools
Grok Build's failure wasn't a single bug — it was a silent bulk-collection pipeline that a broken privacy toggle couldn't stop, followed by a zero-interaction code execution flaw found within a day of the code becoming visible to outside researchers. Neither half of that story required a sophisticated attacker; the first was found through ordinary network traffic analysis, and the second through a routine code audit once the source was public. That's precisely the point: these are the kinds of checks any security team can run before adoption, not after a researcher does it for you in public. Treat AI coding assistants with the same access-and-verification rigor applied to any tool that touches source code and credentials, because the capability gains they offer don't reduce the need for that scrutiny — if anything, the deeper access these tools require makes it more urgent.