Grok Build CLI leaked repos. Here's the identity gap.

xAI told Grok Build CLI users nothing left their machine. A wire-capture proved that was false — 5.1GB moved off a test repo, unredacted secrets included, into a Google Cloud Storage bucket no matter what the privacy toggle said.

That's not really a story about xAI being uniquely careless. It's a story about a gap the whole industry is standing in. n8n audited 75 capabilities that agent-development tools are supposed to have solved by now, and agent identity — who the agent is, separate from who's running it — came back "half-solved" across the board.[1] Grok Build CLI didn't have a security bug so much as it never had an identity to misbehave under. Here's what a properly built one actually looks like under the hood, where the pieces already exist, and where the industry — by its own admission — still doesn't have an answer.

Your agent is wearing your identity, not its own

Run most coding agents today and you'll find them operating with your API key, your shell session, your filesystem access. There's no separate account for "the agent" — it's just you, at machine speed, with fewer second thoughts.

That's the default failure mode Grok Build CLI fell into. On an 11.2GB test repo, the tool shipped git history, unredacted credentials, and files it never even read to a bucket named grok-code-session-traces — 5.1GB transmitted against roughly 192KB the model actually needed for inference.[2] Nobody caught it at the source because there was nothing at the source distinguishing "the agent's legitimate read" from "the agent's illegitimate upload." One identity, one bucket of trust, no seam to inspect.

n8n's audit puts words to the exact shape of the problem: "Agents have clearly slipped between the cracks of human and non-human identities... there is no way to keep track of agents, their actions, and their owners."[1] The most advanced fix live right now is Google's Gemini Enterprise Agent Platform, which issues each agent a cryptographic identity built on the SPIFFE standard — and even that draws criticism over how Kubernetes handles agent replicas.[1] The floor is being poured. It isn't finished.

What a real agent identity actually looks like

Identity, mechanically, means three things: a name that isn't a human's, a credential that isn't a shared secret, and a log that can tell the two apart.

Vercel Agent is a clean worked example. It runs as its own principal — vercel-agent, not whoever triggered it — so every action in the audit trail is attributable to the agent by name, not folded into a person's history.[3]

Source: Vercel — Vercel Agent

That sounds small. It's the entire difference between "someone rolled back prod at 11 PM" and "I rolled back prod at 11 PM, and here's proof it wasn't me fat-fingering a deploy."

Scoped, short-lived permissions — the part that actually matters day to day

Naming the agent is table stakes. What you actually care about is what it can do, and for how long.

Vercel's model is plan-to-permission: the agent proposes a plan, requests access scoped specifically to that plan, a human approves it, and the credential exists only for the life of that plan — then it drops back to read-only.[3] AWS shipped the infrastructure version of the same idea this month: its MCP Server now authenticates agents over OAuth through your existing IAM policies, with token introspection, revocation APIs, and CloudTrail audit events wired in — no bolt-on auth system to stand up and forget to maintain.[4]

The shape of a properly scoped credential looks something like this — not any one vendor's literal schema, but the pattern all of the above converge on:

{
  "principal": "agent:deploy-bot",
  "scope": ["deploy:rollback"],
  "resource": "project:checkout-service",
  "issued_at": "2026-07-13T22:58:00Z",
  "expires_at": "2026-07-13T23:13:00Z",
  "approved_by": "operator:bryan"
}

Fifteen minutes, one resource, one action, one named human who signed off. Compare that to "here's my API key" — an unscoped, undated, unattributed grant that's good until somebody remembers to rotate it.

Sandboxing: the agent's code never touches production directly

Scoped credentials answer what the agent can reach. Sandboxing answers where its code actually runs while it's figuring that out.

Vercel runs generated code inside an ephemeral Firecracker microVM — isolated enough that a bad script can't touch anything live, but real enough that it still runs against the actual project's build and linter, so the test signal means something.[3] That's the missing layer Grok Build CLI didn't have: no sandbox boundary between "the agent is reading my repo to help" and "the agent is reading my repo, period." Once there's no boundary, "it read files it never even needed" isn't a bug report — it's the design.

Here's the full mechanic, end to end:

sequenceDiagram
  participant Op as Operator
  participant Agent as Agent (own identity)
  participant IAM as OAuth / IAM
  participant Sandbox as microVM sandbox
  participant Log as Audit log

  Agent->>IAM: Propose plan, request scoped access
  IAM->>Op: Ask for approval (plan-specific)
  Op->>IAM: Approve
  IAM->>Agent: Issue short-lived, scoped credential
  Agent->>Sandbox: Execute plan in isolated microVM
  Sandbox->>Log: Record every action under agent's own identity
  IAM->>Agent: Credential expires, drop to read-only

Give an agent your API key and you haven't set up an identity. You've made two people share one badge.

What's still not solved

Identity, scoping, and sandboxing are the parts vendors are actively shipping. Two categories n8n flagged are still open industry-wide, and worth knowing about before you assume your stack is covered.[1]

Execution durability — can the agent's task survive a crash and resume at the same checkpoint instead of quietly duplicating work or silently dropping it? Most tools don't guarantee it yet.

Concurrency management — does one agent's runaway task starve another session's? Real fixes need kernel-level resource quotas (cgroups), not application-level politeness.

Intent monitoring is the strangest gap. The obvious fix — have an LLM watch the agent for drift — inherits the same failure mode it's supposed to catch. The alternative, non-LLM classifiers with hard-coded task boundaries, actually works, but it means designing the boundaries before you ship, not bolting on a monitor after something goes wrong.[1] Most teams skip that step because it's unglamorous and doesn't demo well.

What this means for operators

You don't need the industry to finish solving durability and drift before you act. The parts that exist — identity, scoped credentials, sandboxing, audit trails — are things you can demand from any vendor touching your repo or your production systems today. Ask the same five questions and you'll know within a minute whether you're looking at real agent identity or a login wearing a costume:

| Question | What a real answer looks like | What Grok Build CLI actually did | |---|---|---| | Does the agent run under its own identity, separate from mine? | Named service principal, attributable in logs | Inherited local shell access, no separation | | Can I scope what it touches, per task? | Short-lived, plan-scoped credentials | Full repo read regardless of task | | Does its code run in a sandbox before touching real files? | Ephemeral microVM or container | Direct filesystem access | | Does the privacy toggle actually change behavior? | Verified against a wire capture, not just documented | 5.1GB moved with the toggle switched off | | Can I audit exactly what it sent, and where? | Structured, CloudTrail-style logs | Only discoverable via third-party wire capture |

Run any AI coding tool you're evaluating through that table before it touches a real repo. It's the same audit discipline I run through with clients before we wire agentic automation into a live system — the tool is never the risk on its own; the risk is granting it access nobody scoped, logged, or thought to ask about. It's why the $1.25M migration I ran for Palmer's had every AI-touched record logged and validated, not just extracted — when money's involved, "the agent handled it" isn't an audit trail. I wrote about the same failure mode from a different vendor a few weeks back — this isn't a one-company problem, it's a category that's still being built while everyone's already using it.

Identity, scoping, and sandboxing aren't nice-to-haves you bolt on after a breach. They're the minimum bar for letting anything non-human near your codebase — and as of this month, they're finally things you can buy instead of build yourself.

Sources

[1] n8n — Agent identity, reliable execution, and intent are only half-solved — https://blog.n8n.io/agent-identity-reliable-execution-and-intent-are-only-half-way-solved/ [2] GIGAZINE — Grok Build CLI sends your data despite the opt-out — https://gigazine.net/gsc_news/en/20260713-grok-build-sending-data/ [3] Vercel — Vercel Agent — https://vercel.com/blog/vercel-agent [4] AWS — OAuth support for AWS MCP Server — https://aws.amazon.com/about-aws/whats-new/2026/07/oauth-aws-mcp-server/

The short version

• Grok Build CLI shipped 5.1GB of a test repo to a Google bucket with the "improve the model" toggle switched off — the opt-out didn't opt anything out.
• n8n's audit of 75 agent-tooling capabilities found agent identity "half-solved" industry-wide — most agents still run on borrowed human credentials, not their own.
• Real identity means three things: a name that isn't a human's (Vercel's vercel-agent principal), scoped short-lived credentials (plan-to-permission, OAuth through IAM), and a sandbox the agent's code can't escape (Firecracker microVMs).
• Durability, concurrency, and drift detection are still open industry-wide — don't assume your stack has them just because identity and scoping do.
• Ask any AI tool vendor the five-question table above before it touches a real repo or production system.