Skip to content
AI Security Wire

Published

- 5 min read

By

Grok Build Uploaded Your Whole Git Repo: xAI Secrets Leak Explained

Grok Build xAI data exfiltration developer tools Git API keys credentials privacy AI coding assistant supply chain
img of Grok Build Uploaded Your Whole Git Repo: xAI Secrets Leak Explained

An independent researcher intercepted the network traffic of xAI’s Grok Build coding assistant last week and found something that wasn’t in the documentation: the tool was uploading entire Git repositories to cloud storage, not just the files it actually opened.

The scale of the discrepancy is what made the finding hard to ignore. The researcher, publishing as cereblab, captured a session in which model traffic to the /v1/responses endpoint consumed 192 KB. The parallel upload to xAI’s Google Cloud Storage bucket at /v1/storage consumed 5.10 GB. A 27,800-to-one ratio between what Grok used and what Grok sent.

What Was Actually Being Transmitted

Grok Build 0.2.93 packaged the entire tracked Git repository as a bundle and shipped it to a bucket named grok-code-session-traces. The bundle wasn’t scoped to what the model accessed. It covered everything: tracked files, untracked files that were staged, and the full commit history.

That last part matters. Git commit history includes files that were committed and later deleted, which means credentials removed from a repository months ago were still present in the bundle. If a developer had pushed an .env file, realised the mistake, and deleted it, the commit history kept a copy. Grok Build uploaded that copy along with everything else.

Cereblab planted a canary file, src/_probe/never_read_canary.txt, that Grok was never directed to open. It appeared in the storage upload. The test confirmed the behaviour wasn’t limited to files Grok accessed in a session: the tool swept up the entire working tree.

When Grok did read files, their contents appeared unredacted in both the live response stream and the session archive. The researcher’s test environment included planted .env files with fake API_KEY and DB_PASSWORD values. Both transmitted verbatim, no redaction.

xAI’s Response and What It Left Open

xAI moved fast on the technical fix. On July 13, the server returned disable_codebase_upload: true and trace_upload_enabled: false for the same 0.2.93 binary, stopping the uploads server-side without a client update. Within 24 hours, xAI open-sourced Grok Build under Apache 2.0.

The communication around the incident was handled primarily through posts on X rather than a security advisory, a changelog entry, or a formal disclosure. That choice is worth noting: a security advisory creates a traceable record and gives affected users clear remediation steps. A social media post doesn’t. For developers trying to understand whether their code was exposed and what to do about it, xAI’s communication left several questions without clear answers.

Among the things still not disclosed: why repository uploads were enabled by default, how long uploaded data was retained before the server-side flag was applied, how many users were affected, and whether repository contents were processed for model training. Elon Musk’s stated commitment to deleting previously uploaded data covers the storage, not necessarily all downstream uses. The upload code also remains present in the 0.2.93 binary; the server-side flag controls whether it fires, but the behaviour lives client-side.

The “Improve the model” setting in Grok Build’s preferences doesn’t govern code transmission. It governs data retention. That’s a meaningful distinction that wasn’t clearly communicated to users who thought disabling the training preference opted them out of data collection.

The Broader Pattern for AI Developer Tools

The Grok Build case is part of a pattern that has been building since 2024. AI coding assistants need access to your codebase to be useful. The question is whether the access is scoped to what the tool needs, disclosed to the developer, and governed by controls that actually work.

Several prior cases established similar concerns. GitHub Copilot’s telemetry practices prompted questions about what code snippets were transmitted during suggestion generation. Cursor’s data handling policies required multiple revisions after user scrutiny. The common thread is that developers granted broad local access to AI tools without a clear picture of what data left their machine and where it went.

Grok Build’s particular problem was the scope mismatch: a tool positioned as a local coding assistant was, by default, operating more like a remote code sync service. The session traces that went to cloud storage were comprehensive enough that xAI, or anyone with access to that bucket, would have had a complete picture of every repository a user worked with.

The researcher’s methodology, planting canary files to detect covert transmission, is worth noting as a testing practice. It’s straightforward to implement and provides concrete evidence of what a tool is and isn’t sending. For organisations with sensitive codebases, running similar canary tests against new AI developer tooling before broad adoption is a reasonable precaution.

What Developers Should Do

If you used Grok Build before July 13, treat any secret in your repository’s tracked history as potentially exposed. The remediation list:

Rotate API keys, database passwords, and service credentials that appear in any tracked file, including files committed and deleted in the past. Run a secret scanning tool against your Git history (git log --all --full-history -- *env* *secret* is a starting point, but a dedicated tool like truffleHog or git-secrets is more thorough). Run /privacy in the Grok Build CLI to request deletion of previously synced data. If your repository is shared infrastructure for a team, treat this as a team-level rotation exercise, not just a personal one.

The incident is a reminder that local-seeming developer tools warrant the same network traffic scrutiny as any other enterprise software. What a tool accesses on your machine is one question. What leaves your machine is a different one.

References

Frequently Asked Questions

What specific types of data did Grok Build upload without disclosure?
Grok Build version 0.2.93 uploaded the entire tracked Git repository as a bundle, including files the model never opened, deleted files still present in commit history, and the full commit log. When Grok read any tracked file, its complete contents appeared unredacted in both the live model-turn channel and in a session archive. In the researcher's test, planted .env files containing fake API keys and database passwords were transmitted with zero redaction safeguards.
Was my code used to train Grok models?
xAI has not confirmed or denied whether uploaded repository contents were used for model training. Elon Musk stated that previously uploaded user data would be deleted, but xAI has not published any explanation of the storage duration, what processing the data underwent before deletion, or whether data uploaded before the July 13 server-side fix has actually been purged. Standard data retention caveats apply: code transmitted over the network may have already been processed, indexed, or used in ways that make deletion claims difficult to verify.
What should developers do if they used Grok Build before July 13, 2026?
Rotate any secrets that were present in your repository: API keys, database passwords, SSH keys committed by accident, service account credentials. Review your .git history for credentials that were committed and later removed (these were still present in the bundle Grok Build uploaded). If your repository includes secrets in any tracked file, not just .env, treat those credentials as potentially compromised. Audit which xAI storage logs can be accessed and run the /privacy command in the Grok Build CLI to request deletion of previously synced data.