Your agent has a valid token. Should this call still be blocked?

Agent identity is being standardized quickly.

On August 24, Okta made Agent SSO generally available. In Okta's words, when an agent that supports Cross App Access connects to an enterprise application, Okta registers it as a first-class identity in Universal Directory alongside human employees, then issues short-lived, identity-governed tokens in place of stored credentials. The same announcement says Cross App Access is formally incorporated as the official Enterprise-Managed Authorization extension for the Model Context Protocol.

The IETF is moving too, though this is work in progress, not finished standards. An individual draft on AI agent authentication and authorization, dated July 6, has since been replaced by AI Identity Management System (draft-ietf-wimse-aims-00, September 15), now a working-group draft in WIMSE. Separately, the individual draft Transaction Tokens for Agents carries the agent and the principal it acts for through a call chain, including chain-level metadata required for multi-agent flow integrity, so that services can make more granular access control decisions.

And fine-grained authorization is not new: OAuth 2.0 Rich Authorization Requests (RFC 9396, 2023) supports detailed authorization requests and makes the granted details available to resource servers, through token claims or introspection.

This is real progress. Static API keys shared across agents were indefensible.

What the new layer does, and what it hands to you

These mechanisms settle who the agent is, on whose behalf it acts, and what it has been granted, and they carry that context, with constraints, to the service it calls.

What they cannot do on their own is check those constraints against the request that actually arrives, in the state the system is actually in. That check happens in your deployment, at the moment of the call, or it does not happen.

A narrative review of 89 sources posted to arXiv on September 14 (Authorization Architectures for Tool-Using AI Agents) reaches a similar conclusion. The authors find the literature gives little attention to the authorization decision point itself, the moment a tool invocation occurs, and identify runtime enforcement and aggregation bounds as the principal unresolved gaps. That is their finding from the literature they reviewed, not proof that nobody enforces anything. But it points at the right place.

A token can carry the constraints. Your deployment has to enforce them, and prove they held.

Why this matters more for agents

For a human user, the space between "authorized to use the app" and "should perform this action" is filled by the person's judgment and by the application's business rules. An agent changes three things:

• The arguments are generated. A request accompanied by a valid token can contain parameters shaped by a prompt injection in a document the agent read several steps earlier.
• Delegation can widen. Each hop in a multi-agent chain can pass on more authority than its task needs unless something checks it.
• Actions aggregate. Every call can be individually within bounds while the sequence is not.

A concrete version of the third: an agent is permitted to issue refunds below $500, against a delegated budget of $5,000. It submits thirty refunds of $400. Every single call passes the per-refund rule. The total is $12,000.

The moment of execution is where all three must be checked, provided the component doing the checking has trustworthy context and history. A runtime check can see the arguments without seeing that an injection shaped them, and it can only bound the total if it can see what the chain has already done and what it has reserved but not yet completed.

What to verify in your deployment

Vendors do not stop at identity. Okta's own announcement describes its broader Okta for AI Agents offering as one that includes agent-to-agent connections and runtime enforcement. So the question is not whether you must build enforcement yourself. It is whether the enforcement you have, bought or built, covers what your agents actually do: their actions, arguments, delegation limits, and aggregate budgets.

Adopt the new identity layer. Then verify each of these:

• Separate the decision from the enforcement. A policy decision point evaluates each call — this action, these arguments, this principal, this context. A policy enforcement point sits in the execution path and blocks the call when the answer is no. One service can do both, but the enforcement must be on the path the agent cannot route around.
• Keep downstream authority within upstream authority. Each hop may hold at most what the hop above it held, and only what its task needs. It does not have to shrink at every hop. It must never grow.
• Bound the aggregate, including in flight. Track the running total for a delegated chain, and atomically reserve against the budget before a call executes, not after it completes. Otherwise several concurrent requests can each see room in the budget and together exceed it.
• Prove coverage, not just activity. A log of refused calls, with the rule that refused each one, shows that enforcement fired. It does not show that every execution path goes through it. Test for bypass, and correlate decisions with the effects that actually happened downstream.

The question to ask your architecture

Even when an agent presents a valid, short-lived, identity-governed token, authentication is only the first question.

The next question is: when an authenticated agent makes a call it should not make, what stops it, and where is the evidence?

If the answer is "the token," look again at what the token carried, and at whether anything checked it against the call that was actually made.

---

Views are my own.

Sources:

• Okta, Agent SSO announcement, August 24, 2026: okta.com/newsroom
• Okta, Cross App Access extends MCP: okta.com/newsroom
• IETF, draft-ietf-wimse-aims-00: datatracker.ietf.org
• IETF, draft-araut-oauth-transaction-tokens-for-agents-02: datatracker.ietf.org
• RFC 9396, OAuth 2.0 Rich Authorization Requests: rfc-editor.org
• Authorization Architectures for Tool-Using AI Agents, arXiv:2609.15906: arxiv.org