Did the Grok Build investigation prove real API keys were stolen?

The researcher used fake canary secrets and demonstrated transmission of tracked files and Git history. That establishes an exposure path, not theft or misuse of real customer credentials. The researcher subsequently reported that xAI disabled repository uploads server-side.

Does seekrit run hide secrets from a coding agent?

No. seekrit run injects plaintext into the launched process, which can read it. For an agent that executes untrusted code, keep the real keys and SEEKRIT_TOKEN in an isolated seekrit-proxy and give the agent only placeholders, with network controls enforcing its route out.

Grok Build's repository uploads: keep credentials out of what agents can copy

Incidents22 September 2026

An agent can obey an instruction about which files to read while the application around it copies the repository anyway. That is the uncomfortable finding in Cereblab's July 2026 investigation of Grok Build.

In a wire-level analysis of version 0.2.93, the researcher recovered tracked files and Git history from an uploaded bundle, including a file the agent had been told not to open. A separate path sent a read secrets file, containing fake canary values, in model requests and session state.

Those details set the limits of the finding. The test demonstrated an exposure path using fake secrets; it did not establish theft of real customer keys, training on the uploaded data, or the treatment of Git-ignored files. The researcher's subsequent update reports that xAI disabled repository uploads server-side on July 13 and that the disabled behavior was reconfirmed on July 22. This is an analysis of that incident, not a claim that today's Grok Build still uploads repositories that way.

The lasting lesson is about where credentials live. A permission prompt in the chat interface does not describe every process that can copy the workspace.

A repository is a poor place to keep an active key

Putting a secret in .env gives every process with access to that file a copy. Committing it gives Git another copy. Deleting the file in a later commit leaves the earlier version in reachable history. An agent, backup tool, support bundle, or indexing service can encounter any of those copies.

The first change is to stop creating them. Keep values in Seekrit and commit only configuration that names the application and environment, plus an example file listing the variable names the application expects. Use the dashboard to enter values rather than placing them in an agent conversation or a command likely to enter shell history.

For a trusted application, runtime injection removes the need for a persistent dotenv file:

# Run in a trusted application runtime with Seekrit authentication configured.
seekrit run --app storefront --env development -- node server.js

This fetches and decrypts secrets for the child process. It does not write the values into the source tree. Keep that runtime separate from an agent sandbox if the agent must not read the application's environment.

Migrating storage does not repair an earlier disclosure. Revoke or rotate any credential previously committed, then clean up history and other copies as appropriate. A key removed from Git but still accepted by its issuer is still a working key.

Runtime injection has a limit

Running seekrit run -- around a coding agent would give that agent plaintext credentials. It can read its own environment, launch a child that prints it, or include it in a diagnostic report. The file disappeared; the readable value did not.

For an agent that runs untrusted code, use seekrit-proxy outside its execution boundary. The proxy holds the real keys and the Seekrit service token. The agent receives a placeholder such as {{seekrit:OPENAI_API_KEY}} and a route to the proxy.

Agent sandbox                   Trusted proxy                API provider
placeholder + request    →      check allowed operation  →   request + real key
no vault credential             resolve and substitute

The placeholder can appear in a transcript or repository without becoming a reusable provider credential. The proxy permits substitution only for configured upstreams and secrets; method and path restrictions narrow the operations it can authorize.

This is an architecture for an agent's API calls, not a claim of a drop-in replacement for Grok Build's consumer-login or upload protocols. Use the proxy guide to check the integration for the client you actually run.

Keep the broker outside the copy boundary too

The important deployment detail is where SEEKRIT_TOKEN lives. A service token contains decryption key material. Putting it in the agent's dotenv file merely replaces several exposed keys with one credential that can resolve them.

Give the proxy a dedicated token bound to an environment containing only the keys it needs. Keep its environment, files, configuration, and management interface inaccessible to the agent. Use a separate container or stronger isolation where necessary; another process under the same user is not enough against arbitrary code with access to that user's files.

Enforce the network boundary as well. HTTPS_PROXY is a client setting, not a firewall. An untrusted program can ignore it. The sandbox's network policy must make the broker its permitted route out; in forward mode, explicitly deny unmatched hosts.

What remains exposed

Credential brokering protects the keys it holds. It does not make source code non-sensitive, remove credentials from old commits, or stop a program from uploading data through an operation it is allowed to use. Sending private source as model context still sends private source.

That gives teams two concrete checks before enabling a coding tool: inspect what the tool transmits, and inspect what the tool could read if that behavior changes. Seekrit helps with the second by keeping active credentials outside the workspace and, with an isolated broker, outside the agent's process. Start with the runtime injection guide for trusted applications or the credential broker guide for agent sandboxes.