Permission Is Not Control: Why an Authorized Agent Is Still an Insider

In July 2026, an AI coding assistant uploaded a developer’s entire Git repository to its vendor’s cloud. The agent held valid credentials. It acted within the user’s own permissions. It broke no rule the permission system could name. That is the problem worth a security architect’s attention. A legitimately authorized agent can behave like an insider stealing secrets, and every identity control the enterprise owns reports success while it happens. Permission confirms that an Actor may act. It does not confirm that the action should occur. Closing that gap is an architecture decision, and it lives at the action layer, not the identity layer.

---

Identity layer: establishes who the Actor is and what it may access, through authentication and scoped identity. Action layer: governs what the Actor may do at runtime, per action, regardless of standing permission. Control plane: the out-of-agent policy point that authorizes each action before it executes, issues task-scoped tokens, and logs every decision. Blast-radius containment: the sandbox boundary that bounds damage when an authorized action turns out to be harmful.

The identity layer answers who. The control plane bounds what, one action at a time. Containment limits the damage when the first two are satisfied and the action is still wrong.

---

A properly authorized agent exfiltrated an entire codebase without breaking a rule

Grok Build version 0.2.93 ran under a normal consumer login, a browser sign-in to X and SuperGrok rather than an API key.¹ Asked to help with code, it bundled the whole tracked repository, full commit history included, and uploaded it to an xAI-controlled Google Cloud Storage bucket named grok-code-session-traces. The wire capture is unambiguous. The storage endpoint moved 5.10 GiB from a 12GB repository while the model-turn channel moved 192KB, a ratio near 27,800 to 1.¹ The task needed almost none of what left the machine.

This was not one researcher’s single observation. Cereblab published a self-runnable reproduction harness with canary secrets, and named third parties ran it. One contributor extended the deny-bypass to a later version through the git object store, and another developer confirmed the vendor’s server-side fix on his own account. xAI corroborated the finding rather than disputing it. The company shipped a server-side flag that stopped the transmission, and Elon Musk acknowledged the report with a single word, “True.”² The exposure was not limited to one credential type either. xAI’s own remediation carved out only Zero Data Retention teams and API-key use as unaffected, which places every other configuration inside the blast radius.³

Permission confirms an Actor may act, not that the action should occur

The durable lesson is older than the incident. A permission check verifies that an Actor holds legitimate authority for a scope. It cannot verify that a given action within that scope is intended or safe. An Actor that passes every identity and authorization control can still cause insider-scale harm.

Security has a name for this shape. The confused deputy problem describes a program with legitimate authority tricked into misusing it, and it has re-emerged as a top-severity AIgentic threat.⁴ The most dangerous version is a benign, over-permissioned agent that faithfully executes a malicious instruction injected through data it was trusted to read. Grok Build is a sharper case, because no attacker was required. The exfiltration was the shipped default. The distinction matters for design. An injected-instruction attack and an exfiltration-by-default both defeat the permission model, and neither is stopped by tightening credentials.

Grok’s controls governed the read layer while the exfiltration used a separate transmission layer

The wire capture exposes the mechanism, and the mechanism generalizes. A permission “deny” in Grok Build stops the agent from reading a file into the chat. It does not stop the whole-repository git-bundle upload.¹ A file explicitly marked never-read still shipped. The only way to keep a tracked file out of the bundle was to gitignore it. The control the user was told to use governed one layer while the harm occurred on another.

Read this as a property of agent systems, not a single vendor’s bug. When the labeled control and the damaging action sit on different layers, satisfying the control tells you nothing about the action. That is the general failure the Grok capture makes concrete.

The inheritance chain makes this the default condition, not an edge case

One incident is an anecdote. The inheritance chain is the pattern. When an agent borrows a human or service credential, it inherits reach no policy re-examines at the moment of action. VentureBeat’s June 2026 Pulse Research found that 69% of enterprises run agents with credential sharing in at least one deployment, and only 32% give every agent its own scoped identity.⁵ The Cloud Security Alliance describes a non-human identity governance vacuum: more than 16% of organizations do not track the creation of new AI-related identities at all, and fewer than one in four have documented, formally adopted policies for creating or removing them.⁶

Containment moves the wrong way as scale rises. In the same survey, sandbox isolation is the least-adopted control at 30%, and it falls from 35% at mid-size firms to 20% at organizations over 1,000 employees, even as the incident rate climbs from 49% to 63%.⁵ The posture data compounds the risk. Enterprises rate their agent tooling 4.2 out of 5 while 54% have already had an incident or near-incident, and only 35% believe their defenses lead the attackers.⁵ High confidence sits next to unmanaged exposure. OWASP’s taxonomy names the category directly, ranking Identity & Privilege Abuse among the top AIgentic risks (ASI03).⁷ The scale of this inheritance chain is the subject of Governing Non-Human Identity at Machine Pace.

Identity controls and prompt filters cannot bound a legitimately credentialed Actor

Two controls dominate current deployments, and neither addresses the failure. Scoped identity answers who the agent is and what it may access. It is necessary, and it does nothing once the agent holds a legitimate credential and acts badly within scope. Provider filters evaluate prompts and outputs. They inspect apparent intent, not the actions the agent takes against real systems. An exfiltration on a transmission layer never reaches the prompt filter’s field of view.

The conclusion follows without persuasion. An agent is untrusted code even when it presents valid credentials, and untrusted code is bounded by what it is permitted to do, not by who it claims to be. That principle is developed in Treat Your AI Agents Like You Treat Untrusted Code. The identity layer verifies the claim. Something else has to bound the action.

Authorization has to move to the action layer through a control plane

The architecture decision is to authorize actions, not just identities, and to do it at runtime. Static, design-time least privilege breaks down because an agent decides at execution time which tool to call and which data to read. The durable pattern is runtime authorization: workload identity, intent-based authorization, and just-in-time task-scoped tokens with short lifetimes, issued through the OAuth 2.0 Token Exchange on-behalf-of flow.⁸ The agent proves what it is, requests only the access the current task needs, then loses that access when the task completes.

Two design choices carry this. The control plane sits outside the agent, so a compromised or misbehaving agent cannot disable its own oversight, an architecture examined in The Semantic Proxy Pattern. The sandbox sets a harm ceiling, so an authorized action that turns out to be wrong is contained rather than fleet-wide, the ceiling argued in Define the Harm Ceiling Before the Agent Runs. The regulatory stakes are concrete. EU AI Act Article 12 requires high-risk systems to keep automatic logs sufficient for traceability, enforceable from 2 August 2026.⁹ An unattributable agent action undermines the incident-reporting duties NIS2 Article 23 places on essential and important entities, and the materiality assessment the SEC’s Form 8-K Item 1.05 requires of public companies.¹⁰¹¹

Standards are converging on verifiable delegation, yet the control has to exist before they arrive

The direction of travel is clear. The competing IETF Agent Identity Protocol (AIP) Internet-Drafts, the OpenID Foundation’s October 2025 whitepaper on identity management for AIgentic systems, and NIST SP 800-207 zero trust all point from opaque impersonation toward explicit, verifiable delegation.¹²¹³¹⁴ None is a ratified, deployable standard today; the AIP work remains a set of individual Internet-Drafts that expire in 2026.

The pattern in the standards bodies mirrors the pattern in the products. Where identity serves the incumbents, it moves: the IETF has chartered a Web Bot Auth working group, its architecture authored out of Cloudflare, to let a bot cryptographically prove which bot it is.¹⁵ The layer that would bound what an agent may do has no working group at all, only competing individual drafts. The industry is standardizing permission at speed and leaving control to expire as an Internet-Draft.

The enterprise deploying agents this quarter cannot wait for the ratified version.

So the question returns to the architect, in the register that matters. When one of your agents acts this afternoon, can you bound what it does before it does it, or can you only explain afterward what it did and whose credential it held? The first answer is a control plane you build now. The second is the position 69% of enterprises are standing in today.⁵

Frequently asked questions

What is action-layer authorization?

Action-layer authorization decides whether a specific action is permitted at the moment the agent attempts it, rather than granting a standing permission at design time. It complements the identity layer, which establishes who the agent is. The identity layer answers whether the Actor may access a resource. The action layer answers whether this action, right now, should proceed.

Does giving every agent a scoped identity solve this?

No. Scoped identity is necessary and insufficient. It limits what an agent may access, which reduces blast radius, however it does nothing once the agent holds a legitimate credential and takes a harmful action inside its scope. Grok Build acted within a valid user session and still exfiltrated the repository. Identity answers who; it does not bound what.

Was the Grok Build incident a confused deputy attack?

Not in the classic sense. A confused deputy is a legitimately authorized program tricked by adversarial input into misusing its authority. Grok Build required no attacker: the whole-repository upload was the shipped default, and the permission “deny” governed only the read layer. It is better understood as layer decoupling, where the control the user sets and the action that causes harm sit on different layers.

What single control most reduces blast radius when authorization fails?

Sandbox isolation. It is the one control that limits damage after prevention fails, and it is the least adopted in the current data, at 30% and falling as organizations grow.⁵ Isolation sets a harm ceiling: a compromised or misbehaving agent is contained to its sandbox rather than reaching the whole deployment. It is the containment layer the two prevention layers depend on.

Footnotes

1. Cereblab, wire-level analysis and reproduction harness for Grok Build CLI 0.2.93. https://github.com/cereblab/grok-build-exfil-repro and https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547 ↩ ↩² ↩³

2. Elon Musk, post on X, 13 July 2026. https://x.com/elonmusk/status/2076739687658496209. Server-side disable_codebase_upload fix reported by The Register. ↩

3. xAI (@SpaceXAI), post on X: “For teams using zero data retention, no trace and code data is ever retained. All API key use of Grok Build also respects ZDR. If ZDR is disabled, the /privacy command is available in the CLI.” https://x.com/SpaceXAI/status/2076692402442846289. The carve-out was published as part of remediation, after cereblab’s capture (¹) established that the upload fired regardless of credential. ↩

4. Cloud Security Alliance, Confused Deputy Attacks on Autonomous AI Agents. https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-confused-deputy-prompt-injection/ ↩

5. VentureBeat Pulse Research, June 2026 wave, n=107. https://venturebeat.com/security/shared-api-keys-expose-ai-agent-fleets-venturebeat-research ↩ ↩² ↩³ ↩⁴ ↩⁵

6. Cloud Security Alliance, “The State of Non-Human Identity and AI Security,” 26 January 2026. https://cloudsecurityalliance.org/artifacts/state-of-nhi-and-ai-security-survey-report ↩

7. OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications,” ASI03 Identity & Privilege Abuse. Released 9 December 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/ ↩

8. OAuth 2.0 Token Exchange, RFC 8693. https://datatracker.ietf.org/doc/html/rfc8693 ↩

9. EU AI Act, Regulation (EU) 2024/1689, Article 12 (Record-keeping). High-risk obligations apply from 2 August 2026. https://eur-lex.europa.eu/eli/reg/2024/1689/oj ↩

10. NIS2, Directive (EU) 2022/2555, Article 23 (Reporting obligations): 24-hour early warning, 72-hour notification, one-month final report. Transposition deadline 17 October 2024. https://eur-lex.europa.eu/eli/dir/2022/2555/oj ↩

11. U.S. SEC, “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure,” final rule, Release Nos. 33-11216; 34-97989 (adopted 26 July 2023; effective 5 September 2023). Federal Register: 88 FR 51896, 4 August 2023. https://www.federalregister.gov/documents/2023/08/04/2023-16194/cybersecurity-risk-management-strategy-governance-and-incident-disclosure. Form 8-K Item 1.05 requires disclosure of a material cybersecurity incident within four business days of the materiality determination. ↩

12. OpenID Foundation, Identity Management for Agentic AI, October 2025. https://openid.net/new-whitepaper-tackles-ai-agent-identity-challenges/ ↩

13. NIST SP 800-207, Zero Trust Architecture. https://csrc.nist.gov/pubs/sp/800/207/final ↩

14. IETF Agent Identity Protocol (AIP): a cluster of competing individual Internet-Drafts, none adopted as an RFC. The most-iterated is draft-singla-agent-identity-protocol (rev 03, “Decentralized Identity and Delegation for AI Agents”); others include draft-prakash-aip-00 and draft-aip-agent-identity-protocol-00. All are individual Internet-Drafts expiring in 2026. https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/ ↩

15. IETF Web Bot Auth (webbotauth) working group, active since 2025 (formed by IESG action 23 October 2025, following a BOF at IETF 123 in July 2025); chairs David Schinazi and Rifaat Shekh-Yusef. Its architecture work, led by Cloudflare, applies HTTP Message Signatures (RFC 9421) to automated clients. https://datatracker.ietf.org/wg/webbotauth/about/ ↩