AI agent identity: keeping the user's authority from request to action

The user signed in. The system acted as someone else.

A regional finance analyst at a multinational manufacturer opens a customer account that belongs to the company's European legal entity. She may request credits up to EUR 25,000 for that entity. She may not approve or post them.

An agent gathers the contract, recent service incidents and prior credits, and proposes an EUR 18,400 credit. Deterministic checks confirm the amount, currency and remaining annual allowance. A manager with the right authority reviews the exact proposal and approves it.

The credit then waits for the nightly finance window. During the wait, the analyst moves to another region and loses her authority over the European entity. Company policy says the requester must still be entitled when the credit is posted, even after a manager approves.

When the work resumes, the queued message holds only an execution ID, a customer ID, the amount and an approval ID. A background worker signs in with a global service credential that can post credits for every legal entity. The finance API checks that credential, validates the payload and posts the credit. Every component reports success.

Nothing was hacked, no credential leaked and no model hallucinated. The architecture quietly swapped the narrow authority of the business request for the broad authority of whichever worker resumed it. This is the most common identity failure in agent systems, and it's invisible to every component that took part.

It's also common. IBM found that 97% of organizations that reported an AI-related breach lacked proper AI access controls. OWASP lists identity and privilege abuse (ASI03) among the top risks for agentic applications.

Why isn't authentication enough for AI agents?

Authentication is a moment. Authorization is an obligation that lasts as long as the work does. Signing in proves that someone controls a credential. It doesn't settle whether a later action, on a later record, for a later purpose, is still allowed.

Zero-trust guidance makes the same point: access is decided per resource and per request, never granted because a subject signed in once or came through an approved app. Attribute-based access control frames each decision as subject, action, resource and environment, and the decision is only as good as those attributes are current.

Agents multiply the boundaries where that proposition can change. The person who started the request may differ from the person who approved it, the service that executes it, the agent that proposed it and the system that commits it. And a durable workflow can wait long enough for roles, policies and records to change underneath it.

Identity is a stack, not a user ID

Most systems pass identity along as a username or subject claim attached to logs. That's enough to correlate events. It isn't enough to decide anything. A governed runtime needs to answer several distinct questions at each step:

Where does identity get lost in an agent workflow?

Rarely in one place. It erodes through a series of reasonable local shortcuts, each made by a team that kept only what its own component needed.

Don't forward the user's token

The tempting shortcut is to pass the user's original access token through every service. It looks like identity propagation, but it creates new problems:

• The token was issued for the interface, not for the downstream resource.
• Its scopes are usually broader than the current step needs.
• It can outlive the business purpose, or be copied into queues and logs and replayed.

OAuth guidance addresses each of these: audience restriction, token exchange for delegation (RFC 8693), fine-grained authorization details (RFC 9396) and sender-constrained tokens. The pattern that follows separates what the authority means from the credential that proves it at one boundary:

1. Validate the user or upstream assertion on the way in: issuer, audience, assurance and expiry.
2. Create a durable authority context from verified facts and references to current attributes.
3. At each consequential boundary, work out the minimum authority this action needs.
4. Exchange or mint a short-lived, audience-specific credential where the target supports it.
5. Authenticate the workload separately, so the target knows which software is calling.
6. Authorize the whole combination: subject, delegation, workload, tenant, resource, action, purpose and current policy.
7. Record the decision and the outcome, never the reusable secret.

Three actors, never one principal

A consequential action involves at least three actors. Collapsing them into one is how authority gets lost.

A workload can be strongly authenticated and still lack the authority to take an action for a particular person. An authorized person may be unable to call the target API directly. The runtime has to represent the relationship, not pick one identity and drop the others.

Delegation should only ever narrow

Delegation isn't a transfer of every privilege. Each hop should keep the origin and narrow authority to what the next step, record, purpose and current policy allow. In practice, what the next step may do is the intersection of:

• the authority the parent currently holds
• the capabilities and resources the child declares
• the tenant, entity, purpose and data-classification limits of the request
• current policy and conditions
• any required human approval or separation of duties

If a background worker has broader technical permissions than the requester, those permissions let it carry out a validated decision. They don't let it redefine the decision. Any widening has to be explicit, separately authorized and recorded.

Paused work needs its authority checked again

Queues, timers, callbacks and human waits destroy ambient session context. That's why they expose identity weaknesses that synchronous prototypes never show.

When work resumes, the worker authenticates as itself. The runtime then has to re-establish the business authority from the saved context and ask:

• Is the person who started this still entitled to it?
• Has the delegated authority expired or been revoked?
• Does the approval still apply to this exact proposal?
• Did the record, legal entity, policy or purpose change during the wait?
• Which current credential may be issued for the target?

Retrieval is an authorization boundary too

Identity applies before the model call, not just before the tool call. The context an agent decides with can combine database rows, documents, search results, feature values and earlier decisions, each with its own permission rules.

A tenant filter on the main database isn't enough if a vector index, cache, document store or feature service runs under a broader service identity. A context window is a disclosure boundary. You can't ask a model to ignore information the system wasn't allowed to show it in the first place.

Agents can plan. They can't create authority.

An agent may break down a goal, choose among permitted tools, gather evidence and revise its plan. None of that creates authorization. A tool description is not a permission grant, and a generated plan is not authority.

When an agent asks to use a capability, the request should arrive as a typed proposal. The runtime then checks the resource, action, authority, policy and current state before the call goes through. The same applies to sub-agents: each receives a scoped grant that is never wider than its parent's, and each returns evidence the parent can include in the record.

Approval adds authority. It doesn't erase the origin.

A human approval adds another actor and another source of authority. It shouldn't replace the original requester, tenant, purpose or proposal with a generic approved = true. The approval needs to record the exact proposal, what the reviewer saw, the approver's identity and scope, any conditions, and when it expires. If a material fact changes, the runtime rechecks or asks again. The guide to human-in-the-loop approval, covers this in depth.

Authorize at the point of change

The final API call is where identity becomes business consequence. A valid TLS session, a valid service credential and a well-formed request prove that an authenticated workload sent a valid message. They don't prove that the person behind it was entitled to cause that change, on that record, for that purpose.

Right before a consequential call, the runtime should be able to establish the exact resource and operation; the initiating subject, current actor and workload; the narrowed delegation; the tenant, purpose and current policy; the applicable approval; a stable operation identity for retries; and the confirmation that came back. Where a target system can't express delegated authority, the runtime enforces the decision immediately before the call and uses the narrowest credential available. A broad service account should never be the unexamined proof that a business action was allowed.

Common anti-patterns

Ten rules for AI agent identity

1. Model identity as a stack: requester, current actor, workload, delegation, tenant, resource, action, purpose, assurance and expiry.
2. Separate authentication from authorization. A valid credential doesn't settle the current question.
3. Propagate authority, not one reusable token.
4. Narrow at every delegation. Children get no more than the parent, policy and resource allow.
5. Recheck after every wait. Workers authenticate as themselves and rebuild business authority from saved state.
6. Treat retrieval as authorization. Every context item must be permission-compatible.
7. Treat model and agent output as proposals. Plans and tool choices don't create authority.
8. Bind human approval to the exact proposal.
9. Authorize again at the point of change.
10. Record the authority chain from request to confirmed outcome, without storing reusable secrets.

The result: authority survives the architecture

Agent systems are usually described as a sequence of intelligent decisions. In production they're also a sequence of authority hand-offs: a user becomes a workflow, a workflow becomes a queued message, a message becomes a worker, a worker becomes an API call. Each hand-off is a chance to lose, widen or misattribute authority.

Making those hand-offs explicit lets the runtime keep the origin of intent, authenticate every workload, narrow every delegation, recheck current conditions and prove whose authority stood behind the change that finally happened.