Researchers analyzing Grok Build CLI, xAI’s AI coding assistant, found a potential data privacy issue. A detailed technical writeup describes how the tool may silently upload a user’s complete Git repository to cloud servers in the background. That upload reportedly covers more than the current code. It also includes files the tool never read and the complete Git commit history.
Upload Behavior Unrelated to File Access
The behavior does not appear linked to which files the agent actually reads. Users who explicitly told Grok Build not to read any files saw the same result. The tool still generated a Git bundle in the background. It then uploaded the entire repository without an explicit user request.
If the test results are accurate, the implications are significant. Grok Build may routinely send far more data than users intend to share for any given task.
How the Researchers Tested It
To conduct their analysis, the researchers used Grok Build CLI version 0.2.93. Researchers monitored network traffic with packet capture tools. They also planted uniquely tagged files and simulated API keys in a test repository. Next, they issued a simple instruction telling Grok Build to reply only with “OK.” The tool was told not to read or open any files.
Despite that instruction, network traffic showed data flowing to a remote server. The researchers recovered a Git bundle from the captured packets. From that bundle, they successfully cloned the complete repository. It contained the test files, files never requested, and the full Git commit history.
The researchers repeated the test using additional independent repositories. Consistent results across multiple tests suggest this is not an anomaly. Rather, the upload scope may routinely include the entire repository state.
5.1 GB Uploaded from a 12 GB Repo
To gauge the scale of data transfer, the researchers created a roughly 12 GB test repository filled with random data. During the test, the model context API endpoint transferred only 192 KB. However, the storage upload endpoint sent approximately 5.1 GB. The researchers stopped capturing traffic before the session ended. They cannot confirm whether the full 12 GB was uploaded. However, they confirmed Grok Build is capable of uploading multiple gigabytes continuously.
The upload destination is Google Cloud Platform storage. Grok Build uses Google Cloud APIs for this process. Notably, the upload endpoint is not part of xAI’s own backend infrastructure.
Sensitive Fields Sent Without Redaction
The researchers also tested how Grok Build handles sensitive data. Their test repository contained a .env file with fields representing API keys and database passwords. When Grok Build read that file, the sensitive content appeared directly in the model request. Those fields also appeared in the uploaded session state data. The tool made no attempt to detect or redact sensitive field names. Content containing API KEY or PASSWORD fields was sent to the backend without filtering.
Why Git History Makes This Worse
These findings raise a concern beyond the code itself. Git repositories often contain information developers believed they had deleted. Past commits may hold previously exposed API keys, internal server addresses, database configs, unreleased feature code, and internal documents. As long as the Git history has not been purged, that data remains in a full Git bundle.
Disabling the “Improve Grok” Setting Does Not Stop Uploads
The researchers also tested the “Improve Grok” account setting. Disabling it did not stop the repository uploads. The researchers suggest that setting most likely controls data use for model training or product improvement. It does not appear to control whether code is sent to the server at all.
Currently, no evidence suggests xAI uses uploaded code to train models or that employees access, sell, or share user code. The central concern is the scope and transparency of the upload itself.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.