![Grok Build Sent 5.1 GiB for a 192 KB Task [2026]](https://shattered.io/wp-content/uploads/2026/11/grok-build-5-1-gib-upload-192-kb-task-spacexsi-leak-report-2026-gen.webp)
Grok Build, the terminal coding agent from SpaceXSI, is back at the center of the security debate. Ars Technica reported under the headline “Grok Build coding agent leaks oodles of confidential info, some belonging to SpaceXSI,” and the story has pushed AI coding agents to the top of this week’s security agenda.
The numbers behind the controversy are specific. A reported test on a 12 GB Git repository sent about 192 KB to the model and roughly 5.1 GiB to a cloud-storage endpoint. The upload reportedly included the full Git history and secrets that developers had deleted from earlier commits. SpaceX Super Intelligence says it turned off default data retention on July 12 and that zero data retention (ZDR) has been respected since launch.
This analysis separates what is confirmed from what is still a claim. It builds on our earlier look at Transcend’s policy checks for two Grok tools, and it places the episode next to other agent failures we have tracked this year. One caveat up front: the Ars Technica headline wording is not established by the official sources we reviewed, so we treat it as that outlet’s reporting and not as settled fact.
Don't miss new tech stories on Google
Add Shattered once in the Google app and our stories show up in your news suggestions.
What Grok Build Is and Who Runs It #
Grok Build is the official name of the product, and the official announcement page describes it as a terminal-based AI coding agent. A tool like this runs inside a developer’s shell. It reads project files, proposes edits, runs commands and sends context to a hosted model. That access is the whole point of the product, and it is also what makes any data-handling mistake expensive.
The company announced Grok Build as an early beta for SuperGrok and X Premium Plus subscribers on May 25, 2026. That means the first wave of users came from consumer and prosumer subscription tiers, not from enterprise contracts with negotiated data terms. Individual developers rarely have a security team reviewing what a new CLI does on their laptop, so the beta audience matters for how this story lands.
Naming is a small mess. The documentation site calls the company SpaceXSI, the open-source repository uses SpaceXAI, and the official retention post came from SpaceX Super Intelligence. Reporting summarized by our research identifies version 0.2.93 of the open-source repository. We use the names exactly as the sources give them, and we flag the inconsistency instead of smoothing it over.
The 12 GB Test: 192 KB to the Model, 5.1 GiB to Storage #
The sharpest data point in the whole story is the gap between what the model needed and what left the machine. In a reported test, a 12 GB Git repository produced about 192 KB of traffic to the model and about 5.1 GiB to a cloud-storage endpoint. By our own arithmetic on those two figures, the storage transfer ran roughly 28,000 times larger than the model traffic. That ratio is ours, not a figure from any outlet.
| Data point | Value | Basis |
|---|---|---|
| Repository size in the test | 12 GB | Reported test |
| Sent to the model | About 192 KB | Reported test |
| Sent to cloud-storage endpoint | About 5.1 GiB | Reported test |
| Extra content in the upload | Full Git history, deleted secrets from earlier commits | Reported test |
| Prompt used | Reply “OK,” do not open files | Reported test |
| Repository version cited | 0.2.93 | Reporting summarized in our research |
| Early beta announced | May 25, 2026 | Official announcement |
| Default retention disabled | July 12 | SpaceX Super Intelligence post |
The upload (about 5.1 GiB) came in smaller than the repository itself (12 GB). The report does not explain why. Compression or packing of Git objects is one plausible reason, but nobody in our sources confirms it, so treat that as a guess and not a finding. What matters for risk is the content category, not the byte count. A Git history carries every version of every file a team ever committed.
The trivial prompt makes the result harder to dismiss. The same report says the repository went up even when the instruction was only to reply “OK” and not to open files. If that holds, the transfer did not follow the task. It followed something the client does on its own, which is exactly the behavior security teams worry about with any agent that holds broad filesystem access.
Git Repository Upload and the Deleted-Secrets Problem #
A Git repository upload is a different animal from a file upload. A single file shows the current state of one document. A repository shows the full life of a project, including mistakes that someone already fixed. Developers routinely commit an API key, notice, delete it in the next commit and move on. The key survives in history until someone rewrites it and rotates the credential.
Why Git history raises the stakes
The reported upload included secrets deleted from earlier commits. That detail turns a privacy complaint into a credential-exposure problem. A team that believes a leaked token is long gone may still have a live token sitting in a stored copy of its history. Any security review of a coding agent should ask whether the tool reads history, not only the working tree.
We saw the same pattern from a different direction in our report on 1,379 secrets exposed through Claude Code settings files on GitHub. In that case the material surfaced in public GitHub repositories. In the Grok Build report the reported path runs from the user’s machine to a vendor-managed cloud endpoint. The destination differs, but the root problem is the same: secrets live in places developers forget about.
The “reply OK” detail
Testers use a do-nothing prompt to isolate behavior. If a tool uploads data when the user asks for nothing, then the upload is not a side effect of a task. It is a standing behavior of the client. That is why this single detail drew attention in the reporting. It suggests the model prompt and the data pipeline were separate channels, and the user could only steer the first one.
What SpaceXSI Says: Retention, ZDR and the Upload Toggle #
The official response is specific on dates and cautious on blame. In its post, SpaceX Super Intelligence said that during the early beta, data retention was enabled by default for users who were not on zero data retention. It said default retention was disabled for all Grok Build users starting July 12, and that it would delete coding data it had retained earlier. It also said ZDR had been respected since launch and that users could switch off data upload in the CLI.
The company’s own words, as quoted in Simon Willison’s July 15 write-up, run as follows. On the policy change: “We disabled default retention for all Grok Build users starting on July 12th.” On cleanup: “Additionally, we are deleting all coding data that was previously retained, ensuring every user’s preferences are respected.”
On the toggle, a privacy-test write-up on eslamhamed.com quotes SpaceXSI as saying, “When data upload was disabled, this choice was respected.” And on its overall position after open-sourcing the client, the company said, “With all retained data deleted, retention default off, and an open-source harness, we are offering complete user privacy.”
Read carefully, these statements cover three separate things: what the company stores, what the user can switch off, and what the code publicly shows. They do not say that nothing was transmitted before the changes. A fair reading is that the company concedes a default-on retention window during early beta, fixed it on July 12, and stands behind the claim that opt-outs worked. Whether the transfers in the 12 GB test happened inside or outside that window is not something our sources settle.
One more point on wording. Data retention and data upload are different events. A system can upload data to a bucket and delete it a day later, or it can upload nothing and still log metadata. The company’s answers mostly address retention. The Ars Technica story, by its headline, concerns what left the machine in the first place. Those two framings talk past each other, and readers should keep them apart.
Confirmed vs Unconfirmed: Sorting the Claims #
Fast-moving security stories attract confident summaries that outrun the evidence. The table below sorts every major claim by how well our sources support it. Where a claim rests on one outlet’s headline, we say so.
| Claim | Status | Source type |
|---|---|---|
| Product is named Grok Build, a terminal-based AI coding agent | Confirmed | Official materials |
| Early beta for SuperGrok and X Premium Plus began May 25, 2026 | Confirmed | Announcement |
| 12 GB repo test sent about 192 KB to the model and about 5.1 GiB to cloud storage | Confirmed as reported | Reporting summarized in research |
| Upload included full Git history and deleted secrets | Confirmed as reported | Same report |
| Default retention disabled for all users from July 12 | Confirmed | SpaceX Super Intelligence post |
| ZDR respected since launch, upload can be disabled in the CLI | Company claim | SpaceX Super Intelligence post |
| Grok Build “leaks oodles” of confidential information | Unconfirmed by official sources | Ars Technica headline |
| The leaked information belonged to SpaceXSI | Not clearly established | Ars Technica headline |
| Elon Musk personally promised deletion | Not independently verified | Single-source mentions |
The pattern is clear. The mechanical facts (sizes, dates, policy changes) are well supported. The characterization of what was exposed and whose it was rests on the Ars Technica headline and on details we could not match to a primary document. We expect more of that to firm up as the outlet’s reporting and any company follow-up land.
The SpaceXSI Naming Question and the Ownership Claim #
The headline’s most eye-catching phrase is that some of the exposed information belonged to SpaceXSI itself. That would be a striking detail, because it would mean the vendor’s own material passed through its own tool. Our sources do not clearly establish it. We therefore report it as what Ars Technica says, and we hold off on describing what the material contained or how it got there.
The naming drift adds friction. Documentation says SpaceXSI, the repository says SpaceXAI, and the retention post names SpaceX Super Intelligence. For an auditor trying to map a data flow to a legal entity, three names on three official surfaces complicate everything from contract language to breach notification. A privacy question that sounds simple becomes a records question: which entity holds the uploaded data, and under whose terms?
If employees at SpaceXSI did use Grok Build on internal repositories, the case would also work as a rare dogfooding failure. Vendors that ship agents to customers usually run them internally first. A tool that moves internal source material to a cloud endpoint during that internal use tells you little about intent, but it tells you plenty about how hard this problem is to see from inside. Again, this stays a hypothetical until a primary source confirms it.
Market Impact: What Enterprise Buyers Do Next #
We have no sourced revenue, user-count or stock figures tied to this episode, and we will not guess at them. The market effect shows up in procurement behavior instead. Security teams that approve developer tools now have a concrete example to cite in reviews: a CLI that, in a reported test, moved far more data than its task required, in a repository the user did not ask it to inspect.
Kaamel’s guide to AI coding agent privacy due diligence frames the same problem as one for vendor reviews and internal governance, with the central point that a settings toggle is not evidence by itself. That view fits this case. A company can truthfully say a preference is honored and still leave buyers asking for traffic captures, data-flow diagrams and contractual retention limits.
Vendors also face a trust problem that outlives the technical fix. Our report on Fireworks AI’s second hack in weeks and its 10,000-plus customers shows how incidents can stack up for an AI supplier within weeks. Grok Build’s open-source release helps here, because outside engineers can read the client and test it. Open code does not erase a past default, though, and buyers will want proof that deletion actually happened.
The takeaway for teams shopping for agents: treat data-flow evidence as a purchase requirement, not a nice-to-have. For wider context on where this sits among breaches, ransomware and tooling stories, see our security coverage hub.
Competitive Comparison: Four Ways AI Tooling Leaks Data #
It helps to compare Grok Build with other AI-tooling incidents we have covered. The Ars Technica piece carries a section headed “A fatal flaw… shared by most other AI platforms,” which signals that the outlet sees the problem as wider than one product. We cannot verify that claim for other vendors here, so the table below sticks to failure modes from our own reporting and labels each one.
| Case | Where data left | Who controls the fix | Status |
|---|---|---|---|
| Grok Build upload report | User machine to vendor cloud storage | Vendor (client code and defaults) | Retention default off since July 12 |
| Claude Code settings file secrets | User machine to public GitHub | User (what gets committed) | 1,379 secrets found by our earlier report |
| Fireworks AI breaches | Vendor systems to attackers | Vendor (infrastructure) | Hit twice in weeks, 10,000+ customers |
| Prompt injection against agents | Agent context to attacker-chosen target | Shared (tool design and user setup) | Testable with a detector harness |
| Memory and summary features | Assistant to stored memory summaries | Vendor plus user settings | 4 requirements, 4 controls in our guide |
The key differentiator is who holds the lever. In the Claude Code settings case, the fix is a user habit. In the Fireworks case, only the vendor can harden its infrastructure. Grok Build, in the reported scenario, sits in a third spot: the user runs the client, but the vendor’s defaults decided where the data went. That is why SpaceXSI’s July 12 change to defaults matters more than any user-side tip.
For teams that want to test their own agents, our walkthrough on scoring a prompt injection detector in 12 steps covers one of the other rows. And our piece on Gemini’s memory summary and its four controls covers the controls users get over an assistant’s stored memory.
Historical Context: The Coding Agent as a Privileged Insider #
Developer tools have long run with broad local access. Package managers, build systems and editor plugins all read source trees and often touch credentials. What changed with AI agents is that these tools now send large amounts of context off the machine by design, because the model lives in a data center. The question shifted from whether the tool reads your files to what it ships out and where that data rests.
The Grok Build timeline is short. The early beta opened to SuperGrok and X Premium Plus subscribers on May 25, 2026. SpaceX Super Intelligence says default retention was enabled for non-ZDR users during that beta period. Default retention was switched off for all users starting July 12, and the company said earlier retained coding data would be deleted. The Ars Technica report followed in November.
That sequence mirrors a familiar cycle in security. A product ships quickly with permissive defaults. Researchers test the traffic. The vendor tightens defaults and publishes a statement. Then a second round of reporting asks whether the first fix covered everything. Early betas for developer tools tend to favor data collection because vendors want usage data to improve the product, and the cost lands on the users who opted in first.
Open-sourcing the client, which the company cited in its privacy statement, shifts the burden. Anyone can now read what the CLI uploads and when. That is a meaningful transparency step, and it should make independent verification of the 12 GB result easier than it would be for a closed binary. It does not retroactively change what earlier builds did.
What Developers Should Do Today #
Teams that used Grok Build during the early beta should assume a repository they opened with it may have been uploaded, then work backward. The point is not panic. It is cheap hygiene that pays off whatever the final facts turn out to be. Start by finding out how much history your repositories carry and which files were deleted at some point.
git count-objects -vH
git log --all --diff-filter=D --name-only --pretty=format: | sort -u | grep -Ei '\.(env|pem|key)$|id_rsa|credentials'
gitleaks detect --source . --log-opts="--all"
Any credential that shows up in that scan counts as exposed, even if it was removed from the current tree. Rotate it. Rewriting history helps future clones but does nothing for copies that already left your control.
If you still run an AI coding agent
- Turn off data upload in the CLI settings where the tool offers it, and confirm the change with a traffic capture instead of trusting the toggle.
- Run agents inside a container or a throwaway virtual machine that holds only the project you intend to expose.
- Keep home directories, SSH keys and password-manager files out of the agent’s reach.
- Block outbound traffic to anything except the model endpoint you approved.
- Ask vendors in writing what is uploaded, where it rests, how long it stays and how deletion is proven.
- Prefer clients you can read. Open code lets your security team verify behavior across versions.
Organizations should also ask whether subscribers on consumer plans use these agents on work repositories. The early beta went to SuperGrok and X Premium Plus subscribers, so some of those accounts may sit outside any corporate agreement. A short internal notice asking staff to report which agents they used on company code is cheap and often reveals more than a network scan does.
Five Predictions for AI Coding Agent Security #
These are our forecasts, not reported facts. We make them to give readers something to test against events.
- Security questionnaires will add upload-scope questions. Expect buyers to ask whether an agent reads Git history, what leaves the machine, and how deletion is verified. Within two quarters these questions will look standard.
- Upload-off will become the shipping default. The July 12 retention change points that way. Vendors that keep upload on by default will face harder sales conversations with regulated customers.
- Independent audits of open-source agent clients will multiply. With the Grok Build client public, researchers can diff versions and publish traffic analyses. Other vendors will feel pressure to open their clients or accept third-party tests.
- Vendors will publish egress allowlists and data-flow diagrams. A clear list of endpoints and data categories lets customers block everything else at the firewall. Vendors that refuse will lose security-conscious buyers.
- Naming and entity clarity will become a compliance topic. When one product appears under three corporate names, legal teams will demand a single named data controller in contracts and privacy notices.
The common thread is verification. Statements about privacy no longer carry weight alone, and the market is moving toward evidence that a customer can check without asking permission.
What Remains Unknown #
Several questions stay open, and honest coverage means naming them. We do not know the full scope of what the Ars Technica reporting found beyond its headline. We do not know how many users ran the affected builds or how many repositories were uploaded. We have no confirmed account of what the stored data was used for, who accessed it, or how deletion was verified.
We also cannot say whether the 12 GB test reflects the current open-source client or only earlier behavior. The retention post says default retention is off as of July 12, which would change what happens to uploaded data, but it does not by itself say what the client transmits today. Anyone relying on this tool should test the version they run.
Finally, the Musk question. Some mentions credit Elon Musk with a personal promise to delete user data. We could not independently verify that, so we left it out of the confirmed column. We will update this article if SpaceXSI or Ars Technica publish a primary record.
Frequently Asked Questions #
What is Grok Build?
Grok Build is a terminal-based AI coding agent, according to official materials. It entered early beta for SuperGrok and X Premium Plus subscribers on May 25, 2026.
Did Grok Build upload a whole Git repository?
A reported test on a 12 GB repository sent about 192 KB to the model and about 5.1 GiB to a cloud-storage endpoint. The upload reportedly included the full Git history and secrets deleted from earlier commits. Treat it as a reported result until a primary record confirms the details.
Did it upload even when the prompt asked for nothing?
The same report says the repository went up even when the instruction was only to reply “OK” and not open files. That detail suggests the transfer did not depend on the task.
What changed on July 12?
SpaceX Super Intelligence said default retention was disabled for all Grok Build users starting July 12. It added that coding data retained earlier would be deleted, and that retention had been enabled by default for non-ZDR users during the early beta.
Does zero data retention mean nothing was uploaded?
No. Retention and upload are separate events. The company says ZDR has been respected since launch and that users can disable data upload in the CLI, but those statements do not by themselves describe what the client transmitted in every case.
Is it confirmed that the leaked data belonged to SpaceXSI?
No. The claim appears in the Ars Technica headline, but the official sources we reviewed do not clearly establish it, and neither do they confirm the “leaks oodles” wording.
Which name is correct: SpaceXSI or SpaceXAI?
Both appear in official materials. The documentation site uses SpaceXSI, the open-source repository uses SpaceXAI, and the retention post came from SpaceX Super Intelligence. We use each name where its source does.
What should I do if I used Grok Build on a private repository?
Scan the full Git history for secrets, rotate anything you find and ask the vendor in writing what was retained and how deletion was verified. Then run any agent in an isolated environment with restricted outbound traffic.