Ten thousand stars and one commit
On 14 July xAI published the source of Grok Build under Apache 2.0, and by this morning the repository had over ten thousand stars. The release followed a wire-level test that found version 0.2.93 of the tool uploading a tracked repository, and its full git history as a bundle, to cloud storage controlled by xAI, including a repository the assistant had been instructed not to read. We covered that finding on 14 July, and the instruction then was to rotate every secret the tool had ever seen. That instruction stands.
Publishing the code looks like the strongest possible answer to a finding like that. It is the move an engineering organisation makes when it believes the record exonerates it, and it is being read that way. So the useful question is not whether xAI was right to publish. It is narrower and more practical: if you now went to that repository to satisfy yourself about what the tool did on your machines, what could you actually establish?
Very little, as it turns out, and the reasons are structural rather than sinister. The repository carries one commit, authored by a bot on 16 July at 05:46 UTC, with the message that it publishes the harness and TUI open-source. One commit means no history. There is no before, no diff, no sequence of changes, nothing to compare. Ten thousand stars on a repository with no history is ten thousand people endorsing a gesture.
What the repository cannot tell you
Start with the single question the finding actually raised: where did the code go? The uploads went to a Google Cloud Storage bucket named in the shipped binary. In the published source that name does not appear. It is read from a compile-time environment variable, resolved when the binary is built. Whoever compiles the release supplies the destination, and the source is silent on what the shipped build was pointed at. The published code cannot answer the question, in either direction.
Then look at the function that did the uploading. It is still there, in the shell crate, and it no longer does anything. It takes its parameters, marks them unused, waits on the channel, throws the result away and returns a failure noting that session state upload is unavailable. The body has been removed while the surroundings stayed: the call sites are intact, the manifest still lists the dependencies, the storage helpers are still compiled in. What you can read is the skeleton of the mechanism with the mechanism taken out.
This is also the second time the fix has been made somewhere you cannot inspect. The original uploads were stopped on 13 July by a server-side flag, not a client release, which was the sharpest part of the first story: the binary your team reviewed and pinned was never the thing deciding what left the machine. Now the code is public and the destination is still a build-time input and the switch is still on the server. The surface that is auditable and the surface that decides have not been brought any closer together.
Four files moved, one did not arrive
There is one more detail, and it needs stating carefully because it is easy to over-read. The strings inside the shipped 0.2.93 binary name a crate called xai-data-collector, containing five source files: the storage client, the cloud storage layer, the queue, a circuit breaker observer, and a file access tracker. The published repository contains no crate by that name. The same set of files lives in a crate called xai-file-utils, and four of the five correspond. The fifth, the file access tracker, is not in the published source at all.
What that does and does not establish is the whole point. It does not establish intent. Renaming a crate from something that describes collecting data to something that describes handling files is exactly what a team does during a release tidy-up, and dropping a module that is no longer wired to anything is ordinary housekeeping. There is no evidence of concealment here and we are not alleging any. It is also worth noting the asymmetry in the evidence itself: the binary side rests on a third party's string extraction, while the source side can be verified by anyone who clones the repository.
What it does establish is that the release cannot function as a record. The component whose name most directly describes tracking a user's file access is absent, its siblings are present under a different name, and there is no commit history in which either fact can be examined. Innocent explanations and guilty ones produce an identical repository. That is the problem with treating a publication as a proof: it only works if the artefact can distinguish between the two, and this one cannot.
The claim that was never made
Give the researcher credit, because the discipline on that side of this story is the reason it holds up. The wire-level analysis was done with an intercepting proxy against a pinned binary, on a throwaway repository seeded with canary files, and it is reproducible: there is a public harness, and anyone can run it. The measurement was stark. A twelve gigabyte repository produced 5.10 gibibytes of upload traffic against 192 kilobytes of actual model conversation, a ratio near twenty-eight thousand to one. The canary file the assistant was told not to read came back out of the captured bundle intact.
And then the researcher wrote down what the test did not prove. That uploading is not training, because only transmission was measured. That one capture at three gigabytes was not preserved. That an earlier conclusion had been wrong, because a process-scoped network reading missed uploads going directly to Google addresses, and that conclusion was retracted. A finding that publishes its own limits and its own retraction is a finding you can use.
Set that against the responses. xAI has said it cares deeply about privacy, respects customer choice, and that for teams using zero data retention no trace or code data is ever retained. Elon Musk said all user data uploaded before now will be completely and utterly deleted, and that zero anything whatsoever will remain. Those may well be true. None of them is checkable, and the deletion is not verifiable from the outside. The pattern across this entire episode is consistent: the claims that can be tested came from the person with the proxy, and the claims that cannot came from the vendor.
Three questions before you call it fixed
The generalisable lesson has nothing to do with xAI, and it will be needed again within the month. Open-sourcing has become a standard response to a security finding, and it is a good one when the artefact carries evidence. It is not automatically that. So when a vendor answers a finding about your data by publishing code, put three questions to it before the ticket closes.
Can I see the history? A squashed initial commit is a photograph, not a record. If the repository begins on the day of publication, it cannot show what changed, and the thing under investigation is precisely a change. Does the published artefact correspond to the shipped binary? If any behaviour that matters is set at build time or held on a server, the source is a description of a possibility, not of what ran on your machines. Does the code contain the component the finding named? If the specific thing that was found is not in the repository, its absence is not an answer, whatever caused it.
None of this argues for keeping code closed, and none of it is an accusation. It argues for a distinction your procurement process probably does not draw yet: publication is an act of disclosure, and an audit is a process that produces a conclusion. They are not substitutes, they are not even close relatives, and a vendor that has done the first has not done the second. The teams treating a repository link as case closed are making a category error, and it is the kind of error that is only visible in retrospect, after the next finding.
Read next: No AI Lab Scored Better Than a C+ on Safety | Prefect Bought the Other Orchestrator on Your List
