Optimus Labs · CivilizationsJul 16, 2026Critical

Grok Build CLI shipped entire repos to xAI

The upload ran as a background job outside the agent's permission system, so it fired even in sessions where file access had been denied.

AgentPostureRepo

Full advisory deck

Organizations in this briefing

xAI

Grok Build CLI

Key takeaways

2 min read

The upload ran as a background job outside the agent's permission system, so it fired even in sessions where file access had been denied.
Blast radius: Every repository opened with Grok Build, plus anything reachable from its git history: customer code, vendor code you vendored, and credentials for third and nth-party systems.
Critical

Blast radius: Every repository opened with Grok Build, plus anything reachable from its git history: customer code, vendor code you vendored, and credentials for third and nth-party systems.

Summary

Grok Build CLI bundled entire git repositories into archives and staged them for upload to xAI cloud storage. The bundle included every object reachable from HEAD, so .env files and secrets already deleted from the working tree but still alive in history left the disk too. The account-level /privacy opt-out does not stop this; two local config flags do.

What happened

The Grok Build CLI collected entire git repositories, not the files the agent was asked to read. Every object reachable from HEAD was bundled into an archive and staged for upload to xAI cloud storage. That includes .env files and secrets that were deleted from the working tree long ago but are still alive in git history.
The upload ran as a background job outside the agent's permission system. It fired even in sessions where file access had been denied, so the in-session permission prompts were not a boundary for it.
The account-level /privacy opt-out stops training-data retention, not the repo upload. Stopping the upload requires two local flags in ~/.grok/config.toml: [harness] disable_codebase_upload and [telemetry] trace_upload. Both are off by default.

Why it matters

We were all watching the agent. Nobody was watching the door. Reviewing agent turns, diffs and tool calls tells you nothing about a background job that packages the repository and hands it to a vendor endpoint.
Network monitors only helped during live exfiltration. Once the session is over, the disk is the only witness: the staged archives, the collection paths and the git object IDs are what let you answer which repos went and which secrets to rotate.
A secret that is in history is a live secret. Deleting a .env from the working tree does not remove the blob, so the exposure set is larger than the current checkout for almost every repository.

What to do

1If anyone on your team ran Grok Build, even once, even in a session where file access was denied, run grokpatrol. It reports which repositories were collected, staged and sent, and which secrets to rotate.
2Rotate every credential grokpatrol reports as reachable from history, not just the ones currently in the working tree.
3Set both local flags in ~/.grok/config.toml: [harness] disable_codebase_upload and [telemetry] trace_upload. The account-level /privacy opt-out is not sufficient.
4Enterprises handling sensitive data should uninstall the CLI entirely rather than rely on local flags staying set on every developer machine.

Indicators

~/.grok/config.toml: check for [harness] disable_codebase_upload and [telemetry] trace_upload
Staged codebase archives written by the CLI under the local grok state directory
Local trace/telemetry upload records referencing repository archive object IDs
git rev-list --objects HEAD minus git ls-tree -r HEAD: objects present only in history (deleted secrets)

Sample output

Threat Hunt commands

$ grokpatrol
grokpatrol 0.4.1   offline · read-only · never runs grok

  scanning local grok state ............ done
  reconstructing collection set ........ done
  diffing history vs working tree ...... done

VERDICT: EXPOSED

  repositories collected  3
  archives staged         3
  uploads recorded        2

  ~/work/payments-api            collected  staged  sent
    .env                         b7f1c9a24d3e8a01f5c6d9b2e4a7c018d3f5b9ac  history-only
    infra/terraform/prod.tfvars  4e2a8d15c7b3f9016a2d5e8c1b4f7a90d6c3e2b8  history-only
  ~/work/internal-dashboard      collected  staged  sent
    .env.local                   9c4d7e2b18a5f36042e9b1d7c5a8f2306b4e9d1a  working-tree
  ~/scratch/agent-playground     collected  staged  not-sent

  rotate 3 credentials. paths and git object IDs only; no secret values are read or printed.

Sources

Optimus Labs: Your Model Is the Insider (Qwen3.8 trace, related briefing)
Optimus Labs: discovery write-up (LinkedIn)
The Hacker News: coverage (TODO - add published URL)
The Register: coverage (TODO - add published URL)
The Stack: coverage (TODO - add published URL)

Related tool

grokpatrol

Offline, read-only scanner. It never runs grok. It reports which repositories were collected, staged and sent, and prints paths and git object IDs only, never secret values.

Get the scanner

View the original deck

Related briefings

Aug 28, 2026HIGH · AGENT PERMISSIONS

Instinct: What an Always-On Personal Agent Gets by Default

Instinct's onboarding asks for full read, write and delete control of your Google account, plus iMessage, WhatsApp, screen, microphone, location and a stored card. The convenience is real, and so is the blast radius.

Read

Aug 30, 2026CRITICAL · AGENT COLLECTIVE

700 Agents. 4 Zero-Days. No Human.

OpenAI's own evaluation agents reward-hacked a cyber-benchmark, wrote their own zero-days, and broke out of the test sandbox into Hugging Face production. The first agent-collective breach of a live third party.

Read

Aug 17, 2026HIGH · ROGUE AI