Grok Build Uploaded Entire Code Repositories to Google Cloud: What Happened and How to Respond

Introduction

SpaceXAI’s Grok Build coding tool came under scrutiny after a security researcher found that its CLI was uploading entire Git repositories to cloud storage rather than sending only the files required for a coding task.

The uploaded data reportedly included tracked files, full Git history, files the agent had been instructed not to read, and secrets that had been deleted from the current working tree but remained in earlier commits. The destination was a Google Cloud Storage bucket controlled by xAI.

After the findings were published, the upload behavior stopped. The researcher observed that SpaceXAI’s server began returning:

disable_codebase_upload: true

Elon Musk also said previously uploaded user data would be completely deleted. However, independent confirmation that every historical copy has been removed was not publicly available when the incident was reported.

Grok Build Was Sending More Than the Files It Used

The incident began with a controlled network analysis of the Grok Build CLI.

The researcher, publishing under the name Cereblab, reverse-engineered the official binary and monitored its network traffic. In a test designed to reveal the tool’s actual data flow, Grok Build packaged the repository as a Git bundle and uploaded it to a Google Cloud Storage bucket associated with xAI.

This was not limited to the few files needed to answer the prompt.

The captured bundle reportedly contained:

• The entire tracked repository
• Full commit history
• Files the agent had not opened
• Files the agent was explicitly told not to read
• Secrets removed from the current version but still present in Git history
• Other proprietary repository content unrelated to the immediate request

The original AIbase report describes the retention scope as substantially broader than that of comparable AI coding tools such as Claude Code.

In one test reported by Axios, Grok Build uploaded approximately 5.1 GB of data even though the coding task itself required only about 192 KB. That example illustrates the difference between sending task-relevant context and transferring a complete repository archive.

Why Full Git History Is Especially Sensitive

Uploading a current source tree is already a serious security event. Uploading full Git history can be more damaging.

Developers often remove a secret from the latest version of a repository and assume it is gone. In reality, the value may remain accessible in older commits unless the history has been rewritten.

Git history may contain:

• API keys
• Cloud access credentials
• Database passwords
• Private certificates
• Internal service URLs
• Customer identifiers
• Security fixes before public disclosure
• Proprietary code removed from the current branch
• Infrastructure diagrams and deployment scripts
• Personal information from earlier development work

A repository can therefore look clean in the current working tree while still carrying sensitive material inside .git.

This is why instructions such as “do not open this file” are not an adequate protection when the tool separately packages the repository at the Git level. A file-level permission instruction may control what the agent reads during the model conversation, but it does not automatically prevent a separate upload pipeline from bundling repository history.

The Destination Was Google Cloud Storage

Cereblab’s analysis identified the destination as an xAI-controlled Google Cloud Storage bucket.

Using Google Cloud does not mean Google independently decided to collect the repository. Cloud storage providers host infrastructure for customers, and the relevant data controller or service operator in this case was reported to be xAI or SpaceXAI.

The important issue is that repository data left the user’s machine and entered third-party cloud infrastructure.

For enterprise teams, that can trigger questions involving:

• Confidentiality agreements
• Customer-data commitments
• Data residency
• Trade-secret protection
• Software supply-chain rules
• Internal security policies
• GDPR or other privacy requirements
• Industry-specific compliance obligations

Even when the cloud provider itself has strong security controls, an undisclosed or unexpected transfer can violate a company’s own governance requirements.

SpaceXAI Disabled the Repository Upload

After the investigation became public, Cereblab tested the CLI again.

The server returned:

disable_codebase_upload: true

The whole-repository upload no longer triggered.

This appears to have been a server-side change because users did not need to install a new version before the behavior stopped. A remote configuration flag disabled the repository-bundling pipeline.

That distinction matters.

A server-side switch can stop the behavior quickly, but it also shows that the client’s data-handling behavior may depend on remote configuration. Organizations evaluating coding agents should therefore verify actual network traffic and not rely only on a local version number or a static settings screen.

Musk Promised to Delete Previously Uploaded Data

Elon Musk responded publicly by saying that all user data uploaded before the change would be “completely and utterly deleted,” with nothing remaining.

SpaceXAI also said that privacy choices would be respected and that customers covered by zero-data-retention arrangements would not have trace or code data retained.

These are important commitments, but several questions remained open at the time of reporting:

• How many users were affected?
• Which Grok Build versions performed the upload?
• When did the behavior begin?
• How long was repository data retained?
• Was any data accessed internally?
• Did backups or replicated copies exist?
• How can users verify deletion?
• Will affected organizations receive individual notifications?
• Will SpaceXAI publish a formal incident report?

Deletion reduces future exposure, but it does not automatically resolve every security concern. If a repository contained active credentials, users should assume those values may have left the local environment and rotate them.

Why the /privacy Command Was Not the Real Fix

SpaceXAI initially pointed users to the Grok Build CLI command:

/privacy

Official Grok Build documentation describes /privacy as a command that shows or changes privacy and data-retention status.

The security researcher found that this setting controlled retention behavior rather than the underlying transfer of the complete repository bundle. In other words, the command could affect what SpaceXAI retained after receiving data, but it was not the server-side mechanism that stopped the repository from leaving the machine.

Cereblab’s conclusion was clear:

• /privacy was a per-session retention control.
• The repository upload stopped only after disable_codebase_upload was enabled.
• Retention and transmission are separate security questions.

This is one of the most important lessons from the incident.

Upload and Retention Are Different Controls

Control Question	Meaning
Does data leave the device?	Transmission or upload control
Is received data stored?	Retention control
How long is it stored?	Retention-period policy
Is it used for model training?	Training-use policy
Can the user delete it?	Deletion control
Can the user verify deletion?	Audit and assurance control

A service may promise not to retain data and still transmit it for real-time processing. That may be acceptable under a clearly documented enterprise arrangement, but it is not the same as keeping the data local.

Users should not interpret “zero data retention” as “zero data transfer” unless the product explicitly makes that guarantee.

What xAI’s Official Privacy Documentation Says

xAI’s API security documentation describes Zero Data Retention as an enterprise feature.

When ZDR is enabled for an API team, xAI says prompts, completions, and associated metadata are processed in real time but are not persisted to its servers. The documentation also says API responses include an x-zero-data-retention header so applications can check whether ZDR is active.

For standard API use without ZDR, xAI says requests and responses may be stored temporarily for up to 30 days for abuse and misuse auditing.

These API policies are useful, but organizations should not automatically assume that every Grok product, CLI trace, file-transfer channel, or consumer account follows the same data lifecycle.

Before using Grok Build with private repositories, verify:

1. Which account or workspace is active
2. Whether the organization has a contractual ZDR arrangement
3. Which data channels the agreement covers
4. Whether code bundles, session traces, prompts, and tool outputs are treated separately
5. What local and remote settings are active
6. Whether the current binary performs any additional uploads
7. How deletion requests are verified

Security Risks Identified by Researchers

Independent security researcher Dr. Lukasz Olejnik described the scale of data retention as excessive.

The potentially exposed information could include:

• Proprietary source code
• Details about security vulnerabilities
• Personal data
• Internal infrastructure information
• Access credentials
• Customer-specific implementation details

The risk is not limited to intentional misuse.

Large code archives can also be exposed through:

• Misconfigured cloud storage
• Excessive employee access
• Compromised service accounts
• Backup retention
• Logging pipelines
• Legal requests
• Cross-border transfers
• Security incidents affecting the vendor

The principle of data minimization exists to reduce this attack surface. A coding assistant should receive the minimum information required to perform the requested task.

Uploading an entire repository by default is difficult to reconcile with that principle when only a small number of files are needed.

What Developers Should Do Now

Teams that used Grok Build before the upload was disabled should respond as they would to any potential source-code exposure.

1. Identify Affected Repositories

Review where Grok Build was run.

Record:

• Repository name
• Date and time
• Grok Build version
• Account or API key used
• Branches present
• Whether the repository was private
• Whether sensitive history existed

Do not limit the review to files the agent appeared to open.

2. Audit Git History for Secrets

Use your organization’s approved secret-scanning tools to inspect the full history, not only the current branch contents.

Look for:

• Cloud keys
• API tokens
• Database credentials
• SSH keys
• Signing keys
• Private certificates
• Internal URLs with embedded credentials
• Customer credentials
• Temporary development secrets

A secret that was deleted from the latest commit may still require rotation.

3. Rotate Potentially Exposed Credentials

If a credential existed anywhere in the tracked repository history during the affected period, revoke or rotate it.

Do not wait for proof that someone accessed the uploaded copy. Credential rotation is usually cheaper than investigating a later compromise.

Prioritize credentials that provide:

• Production access
• Administrative permissions
• Customer-data access
• Cloud control-plane access
• Package-publishing rights
• CI/CD permissions

4. Review Logs for Suspicious Use

Check cloud, source-control, CI/CD, database, and internal-service logs for unusual activity after the repository was used with Grok Build.

Look for:

• New login locations
• Unexpected token use
• Unrecognized API calls
• Permission changes
• New service accounts
• Repository clones
• Package publication
• Infrastructure changes

Absence of suspicious activity does not prove the data was never exposed, but it can help assess immediate risk.

5. Update Grok Build and Inspect Configuration

Use the current Grok Build release and review the active configuration.

Official documentation provides:

grok inspect

This command helps confirm which configuration sources are being loaded.

The CLI also provides:

/privacy

Use it to review retention status, but remember that the command should not be treated as proof that no data leaves the device.

6. Contact SpaceXAI for Account-Specific Confirmation

Enterprise users should request written answers covering:

• Whether their account was affected
• Which repositories or objects were stored
• Upload timestamps
• Retention periods
• Deletion status
• Backup handling
• Whether data was accessed
• Whether a formal incident notice will be issued

A public deletion promise is helpful, but regulated organizations may need account-specific evidence.

7. Review Legal and Customer Obligations

If the repository contained customer code, personal data, regulated information, or content covered by an NDA, involve the appropriate internal teams.

Depending on the context, this may include:

• Security
• Legal
• Privacy
• Compliance
• Customer-success leadership
• Cyber insurance
• Incident response

Do not make a breach-notification decision based only on a news article. Use the facts of the organization’s own exposure and applicable law.

How Teams Can Safely Evaluate AI Coding Tools

The incident highlights a broader problem across AI development tools.

Coding agents often request extensive access because they need to search large repositories, run commands, read documentation, and modify files. That power creates a large privacy boundary.

Before approving a coding assistant, teams should evaluate five areas.

1. Data Discovery

Document every category of data the tool can collect:

• Prompt text
• Source files
• Git history
• Terminal output
• Environment variables
• Tool results
• Session traces
• Uploaded files
• Diagnostics
• Telemetry

2. Network Inspection

Test what actually leaves the machine.

Vendor documentation is necessary, but network behavior is the strongest evidence of actual transmission.

Use an isolated test repository containing harmless canary values, then inspect:

• Domains contacted
• Upload sizes
• Request timing
• Storage endpoints
• Whether ignored files are included
• Whether history is bundled
• Behavior under privacy settings

3. Least-Privilege Access

Do not run the tool from a directory that contains unrelated projects.

Prefer:

• Temporary worktrees
• Narrow repository access
• Sandboxed environments
• Short-lived credentials
• Read-only mode for evaluation
• Network restrictions where practical

4. Contractual Controls

For enterprise deployment, confirm:

• Data-processing terms
• Training-use policy
• Retention period
• ZDR eligibility
• Subprocessors
• Data location
• Breach-notification commitments
• Deletion verification
• Audit rights

5. Continuous Revalidation

A tool’s behavior can change after an automatic update or remote configuration change.

Re-test after:

• CLI updates
• Major product releases
• New privacy settings
• Changes to enterprise terms
• Changes to network endpoints
• Vendor incidents
• New data connectors

Security approval should not be permanent when the product is changing rapidly.

Broader Lessons for AI Coding Agents

“Do Not Read” Is Not the Same as “Do Not Upload”

Agent instructions operate at the model or tool-use layer. A separate telemetry or synchronization component may not interpret those instructions.

Privacy controls need to exist in the data pipeline itself.

Data Minimization Must Be Verifiable

A vendor can say it sends only necessary context, but enterprise users need evidence.

Useful assurances include:

• Published data-flow diagrams
• Configurable local controls
• Network allowlists
• Audit logs
• Clear storage destinations
• Independent security testing
• Contractual limits

Server-Side Fixes Need Transparency

Remote configuration made it possible to stop the upload quickly. It also means users may not know when important behavior changes.

A mature response should include:

• A security advisory
• Affected versions
• Start and end dates
• Technical root cause
• Data categories involved
• Remediation details
• Deletion status
• Guidance for customers

Deleting Stored Data Does Not Rotate Secrets

Even if SpaceXAI deletes every stored copy, any credential included in an uploaded repository should be treated according to its exposure risk.

Deletion protects future access to the vendor’s copy. It does not change the credential itself.

常见问题

What did Grok Build upload?

Cereblab’s wire-level analysis found that the CLI uploaded an entire tracked Git repository as a bundle, including commit history and files unrelated to the immediate coding task. That history could include secrets removed from the current working tree.

Where was the repository uploaded?

The captured traffic showed uploads to a Google Cloud Storage bucket controlled by xAI. Google Cloud was the infrastructure provider; the relevant product and data-handling decisions were attributed to SpaceXAI.

Has SpaceXAI stopped the upload?

The researcher later observed the server returning disable_codebase_upload: true, after which the whole-repository upload no longer triggered. The change appeared to be server-side.

Does the /privacy command prevent repository uploads?

The command controls privacy and retention settings, but Cereblab reported that it was not the mechanism that stopped the full-repository upload. Users should distinguish between preventing transmission and limiting retention after transmission.

Did Elon Musk promise to delete the uploaded data?

Yes. Musk publicly said all previously uploaded user data would be completely deleted. Independent verification of the full deletion was not publicly available at the time of reporting.

Should developers rotate secrets?

If a secret existed in the tracked repository or its Git history while Grok Build was used, rotation is a prudent response. Deletion of the vendor’s stored copy does not guarantee that a credential was never exposed or accessed.

What is Zero Data Retention?

xAI describes ZDR as an enterprise API feature that processes inputs and outputs without persisting them. It does not necessarily mean that data never leaves the local device, and organizations should verify which Grok Build data channels are covered.

Is Grok Build safe to use now?

The reported whole-repository upload has been disabled, but each organization must evaluate the current version, settings, account terms, network behavior, and repository sensitivity. A server-side fix does not replace internal security review.

相关工具

• Grok Build: SpaceXAI’s coding agent for interactive terminal, headless, and ACP workflows.
• Grok Build CLI Reference: Official command-line reference for Grok Build.
• Grok Build Settings: Official documentation for local, project, managed, and enterprise configuration.
• Grok Build Enterprise Deployments: Official guidance for enterprise security controls, configuration, and data lifecycle.
• Gitleaks: An open-source tool for detecting secrets in Git repositories and history.
• TruffleHog: A secret scanner that checks repositories, cloud storage, and other data sources for exposed credentials.

Related Links

• Cereblab Wire-Level Analysis: The primary technical investigation of Grok Build’s repository and trace uploads.
• Cereblab Incident Summary: The researcher’s summary and update confirming the server-side upload disablement.
• xAI API Security FAQ: Official information about API retention, Zero Data Retention, and verification headers.
• Grok Build Modes and Commands: Official documentation for CLI commands, including /privacy.
• Grok Build Enterprise Documentation: Official deployment and security information for organizations.
• The Verge Report: Independent reporting on the upload behavior, shutdown, and deletion promise.
• The Register Technical Report: Additional reporting on the investigation and SpaceXAI’s response.

Summary

Grok Build was found uploading entire tracked Git repositories and their histories to an xAI-controlled Google Cloud Storage bucket, even when only a small amount of code was required for the task.

SpaceXAI disabled the repository upload through a server-side disable_codebase_upload flag, and Elon Musk promised that previously uploaded data would be deleted. The /privacy command addressed retention settings but was not the control that stopped repository transmission.

Developers who used the affected CLI should identify repositories, scan full Git history, rotate potentially exposed credentials, review logs, and request account-specific deletion information where necessary.

The central lesson is simple: an AI coding tool’s privacy must be verified at the data-transfer layer, not inferred from prompts, retention labels, or a settings screen.