Musk promises purge after Grok Build caught sending entire repos to the cloud

1. Executive summary

xAI's Grok Build CLI (version 0.2.93) was discovered silently uploading users' entire Git repositories — including full commit history and previously deleted secrets — to a Google Cloud Storage bucket operated by xAI, regardless of whether file access was required for the user's prompt. The behaviour was exposed by AI safety researcher "Cereblab" on 2026-07-13 and corroborated by other users reporting full home-directory exfiltration including SSH keys and password manager databases. xAI has since set a server-side flag (disable_codebase_upload: true) to halt whole-repo uploads, and Elon Musk has promised deletion of all previously uploaded data, though this cannot be independently verified. For EMEA financial services, the bottom-line risk is that any developer who ran Grok Build against repositories containing proprietary code, hardcoded credentials, or customer data may have exfiltrated that material to a third-party cloud without consent or knowledge.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 17: ICT-related incident management process	Grok Build exfiltrated entire repositories including Git histories containing deleted secrets to a third-party cloud without user consent — a confirmed data-handling incident.	Financial entities must classify this as an ICT-related incident if developers used Grok Build against repositories containing sensitive or regulated data, and process it through their incident management lifecycle.
DORA Art. 18: classification of ICT-related incidents and cyber threats	The exfiltration of source code, SSH keys, and password manager databases constitutes a cyber threat with potential confidentiality impact.	Incident classification must account for the volume and sensitivity of data uploaded — full repo histories with secrets warrant elevated classification.
DORA Art. 19: reporting of major ICT-related incidents to competent authorities	If exfiltrated repositories contained customer data, proprietary trading algorithms, or regulated systems, the incident may meet major-incident thresholds.	Assess whether the data uploaded to xAI/Google Cloud meets the criteria for major-incident reporting to competent authorities.
DORA Art. 28: ICT third-party risk — general principles	Grok Build is an ICT third-party service (xAI CLI) that transmitted client data to a Google Cloud Storage bucket without adequate disclosure or controls.	Review third-party risk assessments for AI coding tools; verify data-handling practices before deployment in regulated environments.
NIS2 Art. 21(2)(d): supply chain security measures	The incident involves a third-party AI tool (Grok Build / xAI) silently exfiltrating data to cloud infrastructure, highlighting supply-chain risk in developer tooling.	Ensure supply-chain security measures address AI coding assistants and CLI tools that process source code and credentials.
NIS2 Art. 23: incident reporting obligations	Exfiltration of source code and credentials via a third-party tool may trigger NIS2 incident reporting for in-scope essential/important entities.	Assess notification timelines if the incident has significant impact on network and information systems.

3. Technical analysis & attack chain

Confirmed attack chain

A developer installs and runs the Grok Build CLI (version 0.2.93) from xAI/SpaceXAI against a local Git repository.
Upon execution — even with a benign prompt that explicitly instructs the CLI not to open any files (e.g., "reply with OK") — Grok Build packages the entire repository as a Git bundle.
The Git bundle includes the full commit history, including files deleted months prior that still exist in Git history (e.g., hardcoded secrets, API keys, credentials).
The bundle is transmitted without redaction to a Google Cloud Storage bucket used by xAI/SpaceXAI.
The upload occurs regardless of user intent; no file-level access is required to trigger the whole-repo upload.

Technical specifics

Product: Grok Build CLI, developed by SpaceXAI (referred to in some sources as xAI).
Version tested: 0.2.93.
Data path: Local repository → Git bundle → Google Cloud Storage bucket (xAI-operated).
Upload mechanism: The CLI creates a Git bundle of the entire repository (not individual files) and uploads it. Cereblab intercepted one such upload, cloned the Git bundle from the intercepted request, and recovered a file the agent had been explicitly told not to access.
Scope of exfiltration: In one user report, the CLI opened and uploaded the entire user home directory, including SSH keys, password manager databases, and additional sensitive files.
Comparison to peers: Claude Code, Gemini CLI, and Codex open individual files as needed rather than bundling and uploading entire repositories with Git history.
Server-side remediation: xAI developers set disable_codebase_upload to true server-side, which stopped whole-repo uploads globally. This is a silent global flag that applies regardless of user opt-in/opt-out status.
User-facing controls: The /privacy command in the CLI toggles per-session data retention and deletes previously synced data. However, Cereblab notes this is a per-session retention toggle, not the control that stopped the uploads. The /privacy command does not prevent repo uploads — only disable_codebase_upload: true does that.
Zero Data Retention (ZDR): Enterprise customers who enable ZDR are told no trace or code data is retained. API key usage of Grok Build also respects ZDR. Non-enterprise customers do not have ZDR enabled by default.

Confidence caveat: The technical findings are single-sourced from the Cereblab report, corroborated by anecdotal user reports on social media. The claim that xAI has deleted all previously uploaded data (Musk's promise) is unverified — The Register states it cannot independently confirm deletion. Attribution of the tool to "SpaceXAI" vs "xAI" is inconsistent across sources; the vendor identity should be treated as xAI/SpaceXAI without further confirmation.

4. Mitigation & containment

P1 — Within 24 hours

Identify all developers who have used Grok Build CLI. Search endpoints for the Grok Build binary or configuration files. Check for any Grok Build installation paths, shell history referencing grok build or grok-build, and package manager entries.
Immediately suspend use of Grok Build CLI across all development environments until the server-side disable_codebase_upload: true flag is confirmed active and additional controls are verified.
Inventory exposed repositories. For each developer who used Grok Build, enumerate all repositories that were open or accessible in the working directory during CLI sessions. Assume the full Git history of each was exfiltrated.
Rotate all secrets in affected repositories. This includes API keys, SSH keys, service-account credentials, database passwords, cloud-provider credentials, and any tokens present in Git history (including previously deleted/rotated secrets that may have been re-exposed). Prioritise secrets with access to production systems, customer data, or financial systems.
Check for home-directory exposure. If any developer ran Grok Build from their home directory or with a broad working path, assume SSH keys (~/.ssh/), password manager databases, .env files, and cloud credentials (~/.aws/, ~/.config/gcloud/, etc.) were exfiltrated. Rotate all such credentials.

P2 — Within 72 hours

Run /privacy in Grok Build CLI on any remaining installations to trigger deletion of previously synced data. Note: this is a per-session retention toggle and may not delete data already stored server-side from prior sessions — treat Musk's deletion promise as unverified.
Conduct Git history audit on all affected repositories. Use git log --all --diff-filter=D to identify deleted files containing secrets. Use tools such as trufflehog, gitleaks, or git-secrets to scan full history for credentials that were exfiltrated.
Review cloud audit logs for anomalous access patterns that may indicate use of exfiltrated credentials.
Disable Grok Build at network level. Block traffic to xAI/SpaceXAI endpoints and the associated Google Cloud Storage bucket at egress proxies and firewalls. Identify the specific GCS bucket URL from proxy logs if available.
Notify your DPO and legal team. If exfiltrated repositories contained personal data (GDPR-relevant), customer data, or regulated financial data, assess breach-notification obligations.

P3 — Within 7 days

Update AI coding tool policy. Prohibit use of Grok Build and any AI coding CLI that uploads entire repositories without granular file-level access controls. Require security review before approval of any AI coding assistant.
Implement DLP controls for developer workstations: monitor and block bulk file uploads from CLI tools to external cloud storage endpoints.
Conduct a third-party risk assessment of any AI coding tool under consideration, specifically reviewing data-upload behaviour, retention policies, and ZDR capabilities. Compare against the standard set by Claude Code, Gemini CLI, and Codex (individual file access only).
Verify disable_codebase_upload status with xAI if continuing to use Grok Build. Request written confirmation that the flag is active and cannot be reverted without customer notification.

5. Indicators of compromise

No indicators of compromise (IP addresses, domains, file hashes, or specific GCS bucket URLs) are available in the source material. The Google Cloud Storage bucket used by xAI is referenced but its URL/identifier is not published.

6. Detection

Insufficient indicators to author detection rules. The source material does not publish specific GCS bucket URLs, file paths, file hashes, command-line arguments, or network indicators that could be used to construct reliable YARA or Sigma rules.

Recommended behavioural detections (based on confirmed tool behaviour, not source-published IOCs)

Monitor developer workstations for any process named grok or grok-build initiating outbound HTTPS connections to storage.googleapis.com (Google Cloud Storage default domain).
Alert on CLI tools that create Git bundles (git bundle create) immediately before initiating outbound network connections.
Use EDR to flag any AI coding assistant that reads files outside the explicitly requested path or accesses ~/.ssh/, password manager databases, or .env files.

7. Sources

The Register — "Musk promises purge after Grok Build caught sending entire repos to the cloud" — https://www.theregister.com/ai-and-ml/2026/07/14/musk-promises-purge-after-grok-build-caught-sending-entire-repos-to-the-cloud/5271123 — 2026-07-14
The Hacker News — "Grok Build Uploads Entire Git Repositories to xAI Storage, Not Just Files It Reads" — https://thehackernews.com/2026/07/grok-build-uploads-entire-git.html — 2026-07-14

8. Adverse Trace position

This is a high-severity data exfiltration incident for any EMEA financial services organisation whose developers used Grok Build CLI (v0.2.93) against repositories containing source code, credentials, or regulated data. The tool's behaviour — uploading entire Git histories including deleted secrets regardless of user intent — represents a significant confidentiality breach with potential regulatory consequences under DORA and NIS2. The server-side fix (disable_codebase_upload: true) stops future uploads but does not address data already exfiltrated; Musk's deletion promise is unverified and should not be relied upon. We are treating the technical findings as single-sourced (Cereblab) with anecdotal corroboration; clients should verify whether Grok Build was used in their environment before enforcing remediation. Adverse Trace will monitor for additional corroboration, publication of IOCs (particularly the GCS bucket identifier), and any regulatory commentary. Clients should immediately inventory Grok Build usage, rotate exposed secrets, and assess breach-notification obligations.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.