xAI's Grok Build CLI Uploads Entire Repos, Secrets to Google Cloud

Security researchers have discovered a critical privacy flaw in xAI's Grok Build CLI, which by default uploads entire code repositories - including private code, commit histories, and plaintext secrets - to cloud storage. This behavior, documented by network captures, occurred even when privacy settings were disabled. Wire-level analysis showed significant data transfers from repositories, while the AI's tasks only required much smaller amounts of data.

The issue gained attention after researcher cereblab posted packet traces on social media, revealing that the CLI was making POST /v1/storage calls. These calls bundled all tracked and untracked files, including unredacted .env secrets. Corroborating findings confirmed that the tool even uploaded files it was explicitly instructed to ignore, like test files designated as off-limits.

What Data Was Exposed by Grok Build CLI?

An investigation into Grok Build CLI confirmed that each session uploaded the full Git bundle with all branches and commits, untracked working-tree files, and plaintext environment secrets like API keys. The uploads also included canary files that prompts had explicitly excluded from access.

Investigators found that uploads from Grok Build CLI contained several types of sensitive data:
- Full Git Bundle: The entire repository history, including all commits and branches.
- Untracked Files: Any files in the working directory not yet committed to Git.
- Plaintext Secrets: Unredacted environment variables from files like .env, exposing API keys and database passwords.
- Excluded Files: Canary files that were explicitly designated as off-limits in prompts.

Packet captures further revealed a critical detail: the "Improve the model" opt-out setting did not stop the data transmission. It only controlled whether the uploaded data could be used for model training. Server responses continued to show trace_upload_enabled: true until xAI silently disabled the feature on their backend.

xAI's Response and Silent Patch

Following public disclosure of the issue on platforms like Hacker News and X, the data uploads ceased. Subsequent testing confirmed that /v1/storage calls were no longer being made, and a new CLI version introduced a disable_codebase_upload configuration key. However, xAI has not released a public statement regarding the incident. Key questions about the scope of the exposure, the number of affected users, and data deletion from cloud storage remain unanswered. As noted by security researchers, the official release notes made no mention of this significant change in data handling.

How to Protect Your Code: Recommended Actions

Security researchers recommend developers take these immediate steps to mitigate risk:
1. Rotate all credentials. Any secrets, API keys, or passwords present in .env or configuration files within affected repositories should be considered compromised and rotated immediately.
2. Update and verify your configuration. Ensure the disable_codebase_upload: true setting is present and active in your local Grok Build configuration file.
3. Strengthen your .gitignore. Proactively add rules to your .gitignore file to exclude all sensitive files, such as .env*, *.pem, and credentials.json, from any repository accessed by AI tools.
4. Monitor outbound network traffic. Use tools like mitmproxy to inspect outbound connections and confirm that no unexpected data uploads are occurring.

The Wider Implications for AI Development Tools

This incident highlights a significant risk inherent in the growing ecosystem of AI-powered developer tools. Best practices for enterprise adoption include demanding zero-data-retention contracts, mandating strong encryption like TLS 1.3+ for all traffic, and treating AI-generated code with the same scrutiny as any third-party dependency. Experts argue that the Grok Build CLI case serves as a critical reminder: all AI assistants should be treated as untrusted network clients and undergo rigorous security vetting, including packet inspection and threat modeling, before being integrated into development workflows.