Grok Build's SSH Key Theft: The Agent Filesystem Audit Teams Need

A researcher ran xAI's Grok Build v0.2.93 through a proxy on July 10, 2026, and caught it uploading entire Git repositories to a Google Cloud Storage bucket named grok-code-session-traces, regardless of what the model was actually reading. SSH keys, .env secrets, and commit history left the machine. xAI published 844,530 lines of Rust under Apache 2.0 three days after the disclosure, but the upload machinery is present in the released binary, gated only by a server-side configuration flag. The open-source release does not close the risk.

What the wire capture actually proved#

Researcher cereblab's wire-level analysis separated two distinct upload channels. Channel A is the model-turn channel: files the agent loaded went to POST /v1/responses, verbatim and unredacted, including .env contents. Channel B is the whole-repository snapshot: a git bundle of every tracked file and the full commit history uploaded to POST /v1/storage, independent of which files the model touched.

The decisive evidence on Channel B was a ratio. On a 12 GB repository of files the agent never read, POST /v1/storage moved 5.10 GiB across 73 chunks of approximately 75 MB each, all returning HTTP 200. The model-turn channel moved 192 KB across the same session. That is a roughly 27,800x ratio. 192 KB cannot carry 5 GB of content the model never loaded. On a separate, smaller repository, cereblab wire-captured the git bundle directly, cloned it, and recovered the verbatim content of a file the agent had been explicitly told not to read , src/_probe/never_read_canary.txt.

A second independent researcher confirmed the binary's SHA-256 (2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c) and found 339 repo_state.upload.enqueued events across four repositories in local logs, including one session where repo_path was the user's entire home directory.

The opt-out that wasn't#

The /privacy toggle inside Grok Build sets codingDataRetentionOptOut. That governs whether xAI uses the data for training. It does not govern whether the upload happens. Cereblab tested this explicitly: after turning "Improve the model" off, xAI's server still returned trace_upload_enabled: true, upload_enabled: true, and session_registry_enabled: true via the /v1/settings endpoint. The git bundle still uploaded. The never-read canary file was still recoverable.

This distinction matters for incident response. Developers who used the privacy opt-out before July 13, 2026 should not assume their code stayed on-device. The opt-out is a retention setting, not a transmission block.

What the open-source release proves and does not prove#

xAI released the Grok Build source on or around July 14–16, 2026, according to multiple sources covering the disclosure. The repository is a squashed monorepo mirror with no commit history, and external contributions are closed. The relevant upload crates are present in the published source: crates/codegen/xai-data-collector/src/gcs.rs, storage_client.rs, file_access_tracker.rs, and xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs. Source availability makes the mechanism inspectable. It does not remove the mechanism from the binary. The upload remains operational, held off by disable_codebase_upload: true in xAI's remote server configuration , a flag xAI can re-enable without shipping a software update.

The defender checklist#

Any team that ran Grok Build before July 13, 2026 in a directory containing a Git repository should start with credential rotation. SSH keys, API tokens, database passwords, and any other secrets tracked in the repository or read by the agent during a session should be considered exposed.

For teams assessing ongoing AI coding tool exposure, the Grok Build incident defines a concrete audit surface that applies beyond this single tool:

Filesystem scope: what paths does the tool read, and does the read scope match what the diff requires? Channel A in this incident , .env files sent verbatim during model turns , is the more familiar risk. Channel B , whole-repository snapshots independent of model reads , is the less discussed one. Both require explicit testing, not vendor assurance.

Egress destination and protocol: cloud coding agents must send context to function. The relevant questions are where it goes, whether it persists, and whether the persistence is documented. The grok-code-session-traces bucket was named in binary strings and in captured metadata.json files, but was not surfaced in the CLI's install or quickstart documentation, per cereblab's analysis.

Toggle semantics: privacy and opt-out controls on AI coding tools are not uniformly defined. "Improve the model," "data retention opt-out," and "upload enabled" are separate flags that may govern different things. Before relying on any toggle, test it with a proxy and a canary value.

Auto-update risk: Grok Build defaults to auto_update = true. A tool whose behavior can change between runs , including re-enabling an upload channel , requires a verification step after each update, not just after install.

For immediate local mitigation on Grok Build specifically, the configuration that independently confirmed researchers found effective is: [harness] disable_codebase_upload = true in ~/.grok/config.toml as a hard veto on Channel B, combined with GROK_TELEMETRY_TRACE_UPLOAD=false and GROK_TELEMETRY_ENABLED=false as environment variables for the session-trace channel.

The procurement question this changes#

The Grok Build disclosure reframes what a security review of an AI coding tool should examine. Code quality and diff accuracy are the metrics vendors emphasize. Filesystem access scope during a session is rarely in the evaluation. It should be the first question, not an afterthought.

Closed-source coding agent binaries have the same filesystem access as the user running them. That access is broader than any specific task requires. The Grok Build source code, now readable, contains a dedicated xai-data-collector crate with file_access_tracker.rs and circuit_breaker_observer.rs as first-class components. This architecture is a design choice. Other closed-source agents may have similar designs, as several commenters on the original gist noted , though wire-level confirmation for other tools has not been published as of this writing.

Hyrax surfaces out-of-scope file reads and credential-adjacent access patterns in agent-generated changes, which is one edge of this problem. The deeper edge is the install-time decision: what does this binary read off disk that never appears in a diff?

This incident is a useful calibration point on that question. The answer, for Grok Build v0.2.93, was: everything tracked in Git, plus the full commit history, plus whatever files the model read during the session, including .env files, sent unredacted to a GCS bucket. The tool is now open source. The upload code is still there.

Hyrax is live at hyrax.dev.