When an AI agent acts on a user's behalf, something has to authenticate to the downstream systems the agent touches. The question is what — and the answer is less settled than the vendor demos suggest.
Delegated agent authorization is the mechanism by which an agent inherits a constrained subset of a user's permissions, presents credentials to downstream systems, and acts within a defined scope without requiring the user to be present for each action. The agent doesn't log in as itself, and it doesn't log in as the user in any straightforward sense. It presents a token that asserts the user's identity and the agent's permitted scope simultaneously — a credential that says, in effect, "this user authorized this agent to do this specific class of things." What the downstream system does with that assertion, and whether it checks the agent's identity at all, is where the interesting problems live.
Three questions are in play every time an agent makes a call: Who is authenticated? What token is presented? How was consent captured? The first is genuinely unsettled. The second has an emerging answer. The third is where OAuth's assumptions start to crack.
- Delegated agent authorization: A mechanism by which an AI agent inherits a scoped subset of a user's permissions, presents credentials to downstream systems on the user's behalf, and operates within a defined authorization boundary established at session start — without requiring the user to be present for each individual action.
How the Token Mechanism Works
The user authenticates normally — MFA, PIV card, whatever the agency requires. At that point, they're presented with a consent screen that looks familiar: a list of scopes the agent is requesting permission to exercise. Read access to the vendor catalog. Write access to draft purchase orders. Read access to budget line items. The user approves. This is the consent event, and it's the only one that will happen in this workflow.
The authorization server mints a token. Not the user's full access token — a constrained token, scoped to exactly what the agent was granted, with a short TTL. Fifteen minutes is a reasonable working number; the right answer depends on the workflow, but the principle is the same. This token is what the agent presents to every downstream system it touches during the run.
The token carries an assertion of the user's identity (the sub claim, the user's identifier), the granted scopes, the issuer, the expiration time, and — in implementations that have thought carefully about this — an actor claim. The actor claim is where the agent's identity appears. RFC 8693, the OAuth 2.0 Token Exchange spec, defines a mechanism for expressing "this token was issued to user X but is being exercised by actor Y." The act claim carries the agent's identifier. Whether the downstream system validates that claim, whether the agent's identifier is registered anywhere meaningful, and whether the issuer has actually bound the agent's identity to anything verifiable — all of that varies by implementation.
When the token expires mid-workflow, the agent has options. If the authorization server issued a refresh token alongside the access token, the agent can re-mint without user interaction. If not, the workflow stalls until someone re-authenticates. In a 50-step procurement loop, designing around token expiration isn't an afterthought — it's a core architectural decision that has to be made before the agent goes anywhere near a production system.
The consent model is the part that requires the most careful explanation to a buyer who's been thinking about OAuth for years. In a standard OAuth flow, the user is present at the authorization endpoint. They see the scopes. They click approve. They understand, at least in principle, what they're authorizing. In an agent loop, the user approved a set of scopes at session start and then left the room. The agent is now on step 23 of a workflow, about to write a record to a financial system, and the user has no idea that specific action is happening right now. The consent is real — the user did approve it — but it's a blanket authorization, not a signature on each action.
- Token mechanism: A short-lived, scoped access token — minted at session start, constrained to the agent's granted permissions, and presented to each downstream system the agent touches — is the primary credential in delegated agent authorization. Token lifetime and refresh strategy are architectural decisions with direct operational consequences.
Okta Concept Mapping
The closest IDAM analog to delegated agent authorization is the OAuth 2.0 on-behalf-of pattern — a delegated token flow where a service acts with a user's identity and permissions rather than its own. The structural similarity is real: scoped token, trusted issuer, downstream system validates against the authorization server's public keys. Your existing intuition about token validation, scope enforcement, and short TTLs applies here.
Where it stops applying: OAuth's on-behalf-of pattern assumes the delegating service is a known, registered application with its own client credentials — not an agent that may have been instantiated minutes ago, may be running as one of dozens of concurrent instances, and may be making decisions about which downstream systems to call based on runtime context the user never explicitly reviewed. The consent model assumes a human at the keyboard who can evaluate the scope list. The agent model assumes a human who evaluated a scope list once and is now trusting the agent to stay within it. Those are different things, and the spec doesn't fully account for the difference.
A Federal Procurement Workflow
A contracting officer at a civilian agency initiates an agent to execute a routine purchase request — office equipment, under the micro-purchase threshold, from a GSA Schedule vendor. The workflow has five steps: query the approved vendor catalog, verify budget availability against the current fiscal year allocation, draft the purchase order, route it through the agency's approval queue, and log the completed transaction in the financial management system.
Five downstream systems. One consent event.
The officer authenticates at session start, reviews the scope list the agent is requesting, and approves. The authorization server mints a token: read access to the vendor catalog API, read access to the budget system, write access to the procurement drafting tool, write access to the approval routing system, write access to the financial log. The agent begins.
Steps one and two complete in under a minute. The agent queries the catalog, finds three qualifying vendors, checks the budget line — sufficient funds available. It drafts the purchase order and submits it to the approval queue. This is step three. The approval queue is automated for micro-purchases, so the routing completes in seconds. Step four done.
Step five — logging the transaction — happens 18 minutes after session start. The token's TTL was 15 minutes. The agent attempts to write to the financial management system and receives a 401.
Now what? If the authorization server issued a refresh token, the agent re-mints silently and completes the log entry. The officer never knew there was a problem. If no refresh token was issued — because the agency's security policy prohibits long-lived refresh tokens for agent sessions, which is a reasonable policy — the workflow is incomplete, the financial log has no record of the transaction, and someone has to figure out what happened.
This plays out in the first production deployment of an agent in a real agency environment, and it plays out because the token lifecycle design was done by people thinking about human sessions, not agent workflows. Human sessions have a user who can re-authenticate. Agent workflows have a loop that needs to complete.
The buyer who asks "what happens when the token expires mid-task?" is asking a good question. The answer should be specific, not reassuring.
- Practical implication: In multi-step agent workflows, token lifetime and refresh strategy are not implementation details — they're design decisions that determine whether the workflow completes reliably. The federal procurement scenario surfaces this directly: a 15-minute TTL on a workflow that takes 18 minutes produces a failed write and an incomplete audit trail.
The Authentication Question, Honestly
When the financial management system receives the agent's token, what is it actually authenticating?
In most current implementations, the answer is: the user. The token's sub claim identifies the contracting officer. The financial system validates the token against the authorization server's JWKS endpoint, confirms the signature, checks the scopes, and grants access. The agent's identity, if it appears at all, is in an act claim that the financial system may or may not be configured to check. In practice, most downstream systems aren't checking it yet, because the tooling to register agent identities and validate actor claims at scale doesn't exist in most agency environments.
This creates a real gap. The financial system thinks it's talking to the contracting officer. It's actually talking to an agent that the contracting officer authorized. If the agent has been compromised, or if it's operating outside its intended scope, the financial system has no mechanism to detect that — because it's not looking at the agent at all.
The pattern emerging in more careful implementations is dual authentication: the token asserts the user's identity and the agent's identity, and the downstream system is expected to validate both. The user's identity is validated the normal way. The agent's identity is validated against a registry of known, authorized agents — which requires that the agent was registered somewhere in the first place, which is 3.1's problem, not this article's. Arriving at the "both" answer requires infrastructure that most agencies are still building.
For a buyer conversation, the token mechanism is real and it works, in the sense that agents can act on users' behalf with scoped credentials and short TTLs. Whether the downstream system is authenticating the agent as a distinct principal — not just the user whose identity the agent is borrowing — depends on how much of the supporting infrastructure exists. In most deployments right now, the answer is: not really.
That's not a reason to stop. It's a reason to know what you're actually deploying versus what the architecture diagram implies you're deploying.
- The unsettled question: Current delegated agent authorization implementations typically authenticate the user whose identity the agent is acting under, with the agent's own identity appearing as an optional actor claim that downstream systems may or may not validate. Dual authentication — validating both the user and the agent as distinct principals — requires agent identity infrastructure that most environments are still building.