Investigations reveal that Grok Build transmitted confidential information without concealing it, including uploading unread files and Git history.

Cereblab, a company that investigates AI security, analyzed SpaceXAI's (formerly xAI) AI coding support tool 'Grok Build' and reported that authentication information and other sensitive data were sent to SpaceXAI without being redacted, and that entire repositories, including files that the AI had not opened and the Git commit history, were also uploaded.

What xAI Grok Build CLI actually sends to xAI - a wire-level analysis (grok 0.2.93) · GitHub

https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547

Grok Build is a coding agent that reads source code and provides program descriptions and bug fixes. When you ask a cloud-based AI coding assistance tool to 'investigate the cause of an error,' the code needed for analysis is usually sent to the server. On the other hand, development repositories may contain API keys, database passwords, and pre-release features, and if the scope of transmission is not clearly defined, it could lead to information leakage.

Cereblab set up fake tracking data instead of real authentication information and recorded communications for Grok Build version 0.2.93 using a consumer account. Analysis revealed that the API keys and passwords read by Grok were included unprocessed in the communications used for inference, and the same strings were also recorded in other communications that stored session information.

Furthermore, even when instructed to 'just say OK without reading the files,' Grok Build uploaded a 'Git bundle' containing the entire Git repository. It has been reported that the submitted data allowed Grok Build to recover strings and commit history from files it had not read.

In an experiment using a repository of approximately 11.2 GiB , at least 5.10 GiB in total was sent before the communication log was stopped. Since the amount of data used for AI inference in the same experiment was approximately 192 KiB, cereblab concluded that a large amount of data was being sent in addition to the information the model actually read.

The submitted data was stored in a bucket called 'grok-code-session-traces' on Google Cloud Storage. Furthermore, disabling the 'Use for model improvement' setting in Grok did not stop the repository upload.

If you have already used Grok Build, you need to check whether the repository you were working on contained API keys, access tokens, database passwords, etc., and if any valid credentials are found, you need to revoke or reissue them. If you plan to use Grok Build in the future, you should consider measures such as 'preparing a working repository that excludes confidential information and customer data, and removing the credentials from source code and Git management, and passing them as environment variables from a secrets management service or similar.'