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 judgement 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.
Sources: Okta, Agent SSO announcement, 24 August 2026;
Okta, Cross App Access extends MCP;
draft-ietf-wimse-aims-00 (replaces draft-klrc-aiagent-auth);
draft-araut-oauth-transaction-tokens-for-agents-02;
RFC 9396, OAuth 2.0 Rich Authorization Requests;
Authorization Architectures for Tool-Using AI Agents, arXiv:2609.15906.
Top comments (0)