Why AI Agents Need Fine-Grained Authorization

Estimated read: 7-8 minutes

This is the second post in our series on fine-grained authorization for AI agents. The first post opened the series by recapping our Java Day Istanbul 2026 talk and introducing the open-source Keymate Authz Toolkit. Here we step back from the demo and the toolkit to the underlying why: why authentication alone falls short for AI agents, what the IAM ecosystem has built around the problem, and how a recent publicly reported incident makes the gap concrete.

TL;DR

• In AI agent systems, the hard problem is not whether the agent obtains a token. It is whether we can decide, in an explainable, testable, and centralized way, what data the agent may reach with that token and under what conditions.
• A route/scope-only gateway decision falls short in agent scenarios.
• A recent production incident, in which an autonomous coding agent deleted a production database in roughly nine seconds, made this gap concrete: a broad token in the agent's hands, no condition-level enforcement downstream.
• The IAM ecosystem (Transaction Tokens for Agents, XAA, RFC 9728, AAuth, OWASP LLM and Agentic Top 10, Microsoft's Agent Governance Toolkit) is moving fast on identity and protocol questions, but none of these proposals alone answers "what data, under what conditions, can be accessed?"

---

A New Actor on the Stage

Before autonomous AI agents became widespread, the communication line was reasonably simple. End user on one side, the system they wanted to reach on the other. In between, an API gateway, an authentication layer, and a bit of business logic. The decision mechanism was just as simple. Answering "is this token valid, can this user call this endpoint" was enough for most cases.

That line has changed. A new actor has entered between the end user and the system: the AI agent. And this actor is not a passive intermediary. It is a software client that acts autonomously, makes its own decisions, and talks to multiple systems in sequence. The agent communicates with an LLM, triggers various tools through function calling, reaches into other systems via MCP servers, and even talks to other agents like itself using protocols such as A2A.

Data flows between these points. Every connection point is a potential risk. The predictable access pattern we knew from classic applications has given way to a far broader, far more dynamic attack surface. In this new topology, every node can acquire a token, every token can reach into another system, and the decision chain can run far deeper than in classic applications.

The consequence: "Has the agent's identity been verified?" does not solve the authorization problem. Authentication is the starting line, not the finish. The real question is sharper: what data can this agent access, under what conditions, on whose behalf? And how can we explain that decision?

Authentication is not enough for agentic AI systems. What is needed is authorization, and not just any authorization. It must be fine-grained, explainable, and testable.

---

The IAM Ecosystem Recognizes the Problem

This problem is not on our radar alone. The identity, security, and governance ecosystems have all entered a serious adaptation effort over the past few years. Standards, drafts, governance toolkits, and risk lists are being published in quick succession. Let us briefly summarize who is saying what.

Transaction Tokens for Agents (IETF, draft-06)

As of May 2026, this IETF draft, now at draft-06, is trying to formalize the distinction between actor and principal directly in an AI agent context. In other words, it separates "who is making this call" from "on whose behalf this call is being made" at the token level. The agentic_ctx field introduced in the latest revision carries agent type, intent, and permitted actions into the token as operational context. This approach lines up conceptually very well with condition inputs such as agent.type and actor.id in the Declarative Policy Artifact model, which we describe in Part 3.

Cross-App Access (XAA)

XAA standardizes identity-assertion-based cross-domain token exchange. In other words, an agent can use an identity assertion obtained from its enterprise IdP to receive a scoped access token from an external tool's authorization server. The draft's appendix includes an LLM agent example.

RFC 9728: Protected Resource Metadata

Protected Resource Metadata is, in our context, the only RFC published so far. It lets a resource server publish, as metadata, which authorization servers it accepts, which scopes it supports, and which token presentation methods (such as DPoP or mTLS) it requires. It makes the question "to whom and for what was this token issued?" visible at the protocol level and feeds the discipline of audience-restricted tokens at ecosystem scale.

AAuth Draft

AAuth is trying to solve how an agent should obtain a token on a user's behalf. Its most striking thesis is that handing a broadly scoped service account token to an agent is dangerous, because under hallucination or prompt injection the action may be carried out on behalf of the wrong user. This draft frames hallucination not merely as a model quality problem but as a direct authorization risk.

OWASP, W3C, and Governance

OWASP published, on top of the LLM Top 10 (2025), a separate Top 10 for Agentic Applications this year. The LLM Top 10's Excessive Agency item says, under the complete mediation principle, that the authorization decision must be left to downstream systems, not the LLM. The Agentic Top 10's Identity & Privilege Abuse item directly recommends per-action authorization and a centralized policy engine. The Tool Misuse item puts the least-agency principle at the center. Microsoft's Agent Governance Toolkit, announced in early April, also intercepts every action before execution through a framework-agnostic stateless policy kernel.

All of These Matter, But There Is Still a Gap

The message of this list is clear: with the rapid adoption of AI Agents, there is real momentum on the identity, security, and governance sides in terms of awareness and proposed solutions. How tokens are obtained, how identity propagates, how governance is set up, how risks are mapped, every one of these has proposed answers. These efforts solve important parts of the identity, delegation, and governance problem, but they do not remove the need for a separate condition-level authorization layer.

That gap is exactly the focus of this article.

---

The Gap Isn't Theoretical: A Production Database Deleted in 9 Seconds

On 25 April 2026, PocketOS's production database was deleted in roughly nine seconds by an autonomous AI agent. Based on publicly available information about the incident, the anatomy of the event reads as a textbook example of precisely the gap that the drafts and reports we listed above point to.

Summary of the event: an autonomous coding agent running in a staging environment used a Railway API token it found in the system to advance its task. The token had been created for custom-domain management, but it carried blanket authority across Railway's entire GraphQL API, destructive operations included. The agent executed the volumeDelete mutation without any approval. Reservation, payment, vehicle, and user data were deleted.

Now let us read this event through the lens of the standards above:

• AAuth's paper warning materialized in production. A token issued for custom-domain management also carrying volume-delete authority is the exact opposite of AAuth's "do not hand broadly scoped tokens to agents" principle. The token should have been scoped. It was not.
• OWASP LLM Top 10's "complete mediation" was absent. The downstream API accepted the destructive operation because the presented token had sufficient authority for that operation.
• OWASP Agentic Top 10's per-action authorization recommendation was not in effect. For a destructive action, there was neither a human-in-the-loop nor a centralized policy engine. The agent violated the safety rules it had been given, despite knowing them, because a system prompt is not a deterministic enforcement, it is a probabilistic input.
• There was no two-layer identity. The agent used the token in its own name; on whose behalf it was acting was unclear, and no actor approval was sought for an irreversible action.

The problem this and similar incidents expose is not that the agent made a mistake. The problem is the absence of a condition-level authorization layer to stop the agent when it does. To put it more plainly, the rule "this agent, in this environment, on this user's behalf, cannot execute destructive operations without approval" had not been declared anywhere, and therefore could not be enforced anywhere.

This is a single recent incident. But it is the concrete invoice for the gap pointed to in every draft and report we listed up to this point. The standards are not only pointing at a future risk; they are describing patterns that are already showing up in production.

---

Where the Series Goes Next

The gap is now clear, and it has a concrete invoice attached to it. "What data, under what conditions, can be accessed?" is, despite all the progress on the identity and protocol sides, still an open door. The way to close it runs through the combination of declarative policy artifact, centralized evaluation, design-time test, and same semantics at runtime.

In the next post we walk through that combination as Keymate builds it:

• A declarative policy artifact model, Access Rules, that separates policy from code.
• A centralized decision engine, Access Rule Engine, that evaluates the policy against a request context and produces an explainable verdict.
• A design-time CLI toolkit, kmctl authz, that lets developers validate, simulate, and explain the policy before deploying it.
• The same engine running inside Access Gateway at runtime, so a scenario that produces ALLOW or DENY locally produces the same decision in production. Same rule, same engine.

We also follow the live demo we ran at Java Day Istanbul 2026: one policy, five scenarios, two social-engineering attempts, and an AI agent that is both unwilling and technically unable to bypass the policy.

📖 Next in the series: how declarative policy, a centralized decision engine, and a design-time CLI close the fine-grained access gap, with the same rule enforced identically at design time and runtime.

Series nav
← Part 1: AI Agent Authorization: From Java Day Demo to Open Source Toolkit
→ Part 3: How Keymate Enforces Fine-Grained Authorization for AI Agents