Every coding agent on your laptop is a process that reads your filesystem with your credentials and uploads whatever the vendor decided you consented to. You knew that. You installed it anyway. This week the arrangement got a public autopsy. Three days after a researcher demonstrated Grok Build siphoning SSH keys and repository contents up to xAI's cloud, xAI dropped the agent's source code on GitHub under an Apache 2.0 license. DevOps.com wrote it up on July 20. The code is now inspectable. The trust model is a different question.
What actually shipped
The published tree is Grok Build's terminal-based coding agent, over a million lines of Rust: the agent loop, the file-editing plumbing, the shell-execution layer, the terminal UI, the extension surface. Apache 2.0 means you can fork it, embed it, and audit it. That last one is the point.
xAI's contributing file, per the DevOps.com writeup, says external pull requests are not accepted. So this is a source-transparency release, not a community-governed project. Read: you can see what runs, you cannot help decide what runs next.
Why the release exists
Before the code drop, a researcher going by Cereblab ran mitmproxy against Grok Build CLI 0.2.93. Pointed at a 12GB test repository, the client uploaded 5.1GB in 73 chunks to a Google Cloud bucket called grok-code-session-traces. In the haul: files the agent had never opened during the session, SSH keys, and .env files with credentials in what DevOps.com described as plain, unredacted form. A separate user reported the agent pulling in SSH keys, a password manager database, personal documents and photos. Uploads happened regardless of the CLI's Improve the model privacy toggle.
xAI disabled the upload endpoint without a security advisory or a changelog note. Elon Musk posted that previously uploaded data would be "completely and utterly deleted." No count of affected users. No retention window. No verification path for anyone asking whether their bytes ever left the bucket.
Then the source landed. Which brings us to the CI/CD part.
What CI/CD teams should actually do with this
If you had Grok Build anywhere in your workflow, a preview job that hands PR diffs to the agent, a nightly refactor bot, an on-call script that shells out to it, treat the disclosure as the cutoff date for compromise assessment. Every runner that executed the CLI before then had its filesystem in scope. That includes any long-lived credential the runner had cached: SSH keys, cloud tokens, service-account JSON, .netrc, .env files. Rotate first, ask questions later.
The source drop is useful for one thing you cannot do with a closed binary: diff. You can now read what the current agent actually collects, what endpoints it talks to, and which knobs the on-disk privacy toggle really controls. If your platform team has the appetite, wire a network egress deny-all around the CLI in your runner image and let the tests fail loudly on any host the audit says the agent has no business calling.
The trust boundary that just moved
Coding agents are not IDEs. They run with user credentials, they read arbitrary paths, and they exfiltrate on the vendor's schedule under labels like session traces and telemetry. The primitive that got Grok Build here is the same one that will get the next one: a client-side privacy toggle is a suggestion, not a boundary. The only enforceable place to stop egress is on the network, from a process running as something other than the user whose keys are on disk.
Other agents dodge parts of this in various ways. Some run the model server-side and pull code up rather than sitting on your keys. Some ship with content redaction that at least scrubs obvious secrets before they leave. Some (most, honestly) rely on the same client-side toggle Grok Build did, and hope nobody points mitmproxy at them.
Now you can point it at Grok Build's source instead. Progress, of a kind. Whether it is enough progress is a call for you and whichever incident-response channel is currently paged.
Top comments (0)