Grok slurping secrets from private repos, xAI scrambles to fix it
Fix controls what xAI keeps, not what is transmitted.
Image by Cybernews
- Grok Build reportedly bundled entire repos – including untouched files and full commit history – just to answer a debugging question.
- One test found 5.1 GiB uploaded from an 11.2 GiB repo when the AI only needed 192 KiB, suggesting far more data left the machine than expected.
- Turning /privacy off doesn't stop the uploads – it only controls whether xAI retains session data afterward, not whether your code gets sent in the first place.
- Anyone who's run Grok Build on a repo with real secrets in it may want to rotate API keys, tokens, and DB passwords as a precaution.
Key Takeaways by nexos.ai, reviewed by Cybernews staff.
SpaceXAI's AI coding assistant Grok Build has come under fire after an independent researcher discovered it was uploading a developer’s entire Git repository – including unaccessed files and full commit history – when it was asked to analyze or debug code.
The findings, first published by security researcher Cereblab on July 12th, have reignited concerns over how AI coding assistants handle sensitive developer data and whether users fully understand what information leaves their machines when using cloud-based coding tools.
What Grok Build uploaded
AI coding assistants such as Grok Build and Claude Code help developers explain code, identify bugs, and generate new software.
To do this, they usually send relevant snippets of source code to remote servers for analysis.
However, production repositories often contain much more than application code, including API keys, database credentials, internal documentation, unreleased features and other secrets.
Cereblab said their testing of Grok Build version 0.2.93 found the software uploaded a Git bundle containing the entire repository, even when it was instructed not to read the project files. The researcher published a wire analysis on GitHub and urged other developers to try it out.
The researcher also claimed that the upload included files the AI had never opened, as well as the repository’s Git history.
In one test, they found that Grok Build transferred at least 5.1GB from an 11.2GB repository before logging was stopped, even though only about 192KB was needed for the AI task.
Cereblab’s findings showed that disabling Grok's "use for improving the model" setting did not stop the uploads.
For comparison, the researcher later wire-captured Claude Code, Codex, and Gemini the same way. His findings:
“All 3 stay local, only sending files they actually open, and my planted 'never-read’ file never left the machine.”
The researcher warned any developers who had used Grok Build to immediately rotate API keys, access tokens, or database passwords that may have been stored in their repositories.
What actually stopped the uploads
Hours after the findings gained traction online, xAI introduced a new /privacy command for Grok Build, allowing users to opt out of data retention and delete previously synced data.
The company said customers using Zero Data Retention (ZDR) were unaffected, since that configuration never retains code or trace data in the first place.
However, follow-up testing by Cereblab showed the new /privacy command wasn't actually responsible for stopping the uploads. Instead, a separate server-side flag (disable_codebase_upload: true) was the actual fix.
Stay updated with our latest stories and follow us on social media
Be the first to discover new stories, ideas, and updates from our team.
According to the researcher, /privacy only controls whether xAI retains session data after the fact – it doesn't stop that data from being transmitted to the company's servers in the first place.
"The point is that /privacy is a per-session retention toggle, not the switch that fixes things," the researcher said.
The researcher asserts that developers shouldn't have to opt out after every session just to keep their own code off someone else's servers: "The right default is off."
Developer backlash
The incident drew outrage from developers on X. CyberSatoshi (@XBToshi), whose posts helped amplify the issue, accused Grok Build of "treating local dev environments like an open buffet for training data."
Other devs reported checking Grok’s local logs after instructions were shared online, while many argued the situation highlighted a broader issue with coding assistants – users usually know code is sent to the cloud, but not exactly how much data is transmitted or retained.
Several reminded users of the value of using sandboxed development environments that isolate AI tools from sensitive repositories.
Strong password generator
Grok is currently being used by the US Government, and has been granted access to the Pentagon's classified networks.
It's not the first time coding assistants have been exposed for mishandling developer data.
Last month, Microsoft researchers discovered a vulnerability in Anthropic's Claude Code GitHub Action that could expose CI/CD workflow secrets, potentially allowing attackers to steal sensitive credentials through prompt injection attacks.
