Delegated authorization for AI agents

Delegated authorization for AI agents lets an agent act on someone's behalf using authority that person granted for a specific task. The grant is limited in scope, ends on its own and can be withdrawn. Instead of a broad credential to a backend system, the agent carries a token that says it may do these things, for this person, until this time.

Most useful agent actions happen on someone's account. Changing a booking or updating payment details is something a customer can do to their own data, not something an agent should be able to do to anyone's. Delegation keeps the agent's reach tied to the person it's serving, and it's the main structural defense against the confused deputy problem.

How delegated authorization works

Most implementations build on OAuth 2.0. The user signs in to an authorization server and approves a set of permissions for a specific agent. The server then issues the agent an access token.

That token carries a few key facts. It names the user, identifies the agent, lists the permitted operations and states which system it's valid for. The backend checks all of them before it acts. If the token lacks the right permission, the request fails, whatever the model was trying to do.

An IETF draft on AI agent authentication and authorization describes this structure. It says agents should request only the minimum scopes a task needs, that tokens should be short-lived and restricted to one audience, and that agent credentials must carry an explicit expiration. It remains a draft, not a finished standard.

Delegation versus impersonation

The core mechanism for narrowing a token is OAuth 2.0 Token Exchange, published in January 2020 as RFC 8693. A client hands over the user's token and asks for a new, narrower one for a particular system and scope.

The RFC separates two outcomes. With impersonation, the agent becomes indistinguishable from the user within the token's rights. With delegation, the agent keeps its own identity and the new token records it in an actor claim, written as act. The RFC also defines may_act, which states in advance who is allowed to act for the user.

For agents, delegation is the one that matters. A token that names the customer as the subject and a specific agent as the actor tells both the backend and the logs who an action was for and who carried it out. Exchange can also repeat down a chain, so a subagent calling one tool gets a token for that tool alone.

Why a shared service account isn't enough

Many teams start with a single service account or API key that the agent uses for every conversation. It's simple, and it works. But the agent's real authority becomes everything any customer might ever need.

Whether an action is right for the current customer is then left to the model's judgment instead of the authorization server. A prompt injection or a misidentified caller gets the whole credential to work with. Delegated tokens move that decision back into infrastructure, where a request against another customer's account simply fails.

Delegation also does a different job from tool-call guardrails. Guardrails look at a single action and decide whether it seems acceptable. Delegation sets the outer boundary of what any action can reach. Teams need both, and neither replaces the other.

Common gaps in delegated authorization

Consent is the first weak spot. The IETF draft is clear that a user clicking approve inside an agent's interface isn't authorization on its own. That confirmation has to be bound to a grant the authorization server actually issued, and plenty of implementations blur the two.

Lifetime is the second. Agents often keep working after the user's session ends, which pushes teams toward long-lived refresh tokens. Those quietly undo the time limit that made delegation safer in the first place.

Scope design is the third. Many APIs only offer coarse permissions, so the narrowest available token may still allow far more than the task needs. A token meant for checking order status shouldn't also allow refunds just because both live in the same API.

What delegated authorization means for customer service

In support, the customer is rarely an OAuth user of every system the agent touches. The delegation has to start from an identity verified through authentication earlier in the conversation. If that step is weak, everything built on top of it is weak too.

The question gets sharper when the other party is software. In agentic commerce, a shopper's AI agent may contact support to change or cancel an order. Support teams need a policy for what that agent can do alone, what needs the customer's confirmation and what has to go to the account holder directly.

Logging pays off here. Because each token names both the customer and the agent, every action can be traced to a specific agent acting for a specific person under a specific grant. That's the record a disputed charge or a compliance review will ask for.

For a deeper dive, download Decagon's guide to agentic AI for customer experience.