Delegated authorisation for agents

What is delegated authorisation for agents?

Delegated authorisation is how an agent gets permission to act for a colleague without becoming that colleague. The agent keeps an identity of its own, the person keeps theirs, and the link between them is written down: which actions, for how long, granted by whom.

The OAuth token exchange standard, RFC 8693, is precise about the difference. Impersonation is when one party gets all the rights of another and is, in its wording, indistinguishable from that party. Delegation is when the acting party keeps its own identity and it is explicitly understood that the action is taken by the agent representing the person. Indistinguishable, or explicitly understood.

Whether the agent has a login at all is the question behind agent identity. Delegation is the next one: what that login may do for one named colleague, and until when.

The two shortcuts, and what your log looks like afterwards

The first shortcut hands the agent the person's own login: a copied password, a borrowed session, a token minted from her sign-in. Every action arrives at the other system under her name, and nothing in the request says an agent was involved, because nothing in it can. Six weeks later that colleague is asked to explain a purchase order she never saw.

The second points the agent at the shared integration account. Now nothing looks like her, which sounds like progress until you notice that nothing looks like anyone. Five agents and two nightly jobs on one account produce a column of identical lines, on an account that holds every permission anyone ever needed to attach to it.

Set both beside a delegated agent on a single dimension, what the log can tell you a month later. On the shared account, a line says the account created a purchase order at 09:12, and that is the end of it: not which agent, not for whom, not on whose authority. With a delegation, the same line names the agent, names the colleague it acted for, and points at the grant that allowed it.

What a delegated token carries

Two identities instead of one. RFC 8693 defines an act claim for exactly this: a way within a token to express that delegation has occurred and to name the acting party to whom authority has been delegated. The subject stays the person, the actor is the agent. A companion claim, may_act, says up front which party may become the actor for another, so the authorisation server can refuse a delegation nobody approved.

A short scope list instead of everything the person can reach. Your colleague in logistics can read invoices, change master data and cancel shipments. The agent that books pickup slots needs two of those verbs and none of those nouns. Scopes are where least privilege turns from a principle into a decision somebody has to make.

An end. The token expiry limits how long a leaked copy is worth anything. The grant needs its own end date, which limits how long the arrangement outlives the reason it was made.

The claims that do the work look like this, and the second line is the one a service account can never produce.

{
  "sub": "lieve.dm@example.be",
  "act": { "sub": "agent-logistics-03" },
  "scope": "pickup.read pickup.create",
  "exp": 1788523200
}

Which parts are standardised, and which are still proposals

Published standards. The authorisation code flow with scopes, defined in OAuth 2.0 (RFC 6749) and carried into the OAuth 2.1 draft that consolidates it, is how a person grants an application scoped access without handing over a password. Token exchange (RFC 8693) is published and is where the delegation vocabulary comes from, and so is token revocation (RFC 7009). None of the three were written with AI agents in mind, and all three work for them.

A vendor pattern on top. Microsoft's on-behalf-of flow is the best documented. A service exchanges the token it received for one to call the next service, and Microsoft describes the intent as passing a user's identity and permissions through the request chain. It carries delegated scopes only and never application roles, because roles stay attached to the user and not to the application acting for them. It is not the token exchange grant either, but the JWT bearer grant with a requested_token_use=on_behalf_of parameter of Microsoft's own. Their agent guidance splits the same way: an interactive agent working for a signed-in colleague gets delegated permissions through that flow, an autonomous agent runs on its own identity through client credentials.

Still in draft. The MCP authorisation specification of 28 July 2026 is OAuth 2.1 plus resource indicators, so a token is bound to one server, but it defines no delegation chain. Transaction tokens, which carry user identity across a chain of internal services, are an OAuth working group draft at version 11, dated 30 July 2026. The profile that would settle how the actor is named for agents across organisations is an individual draft from April 2026 with no formal standing. The parts you need to build this today are stable. What is missing is the profile that would make one vendor's agent delegation legible to another vendor's system.

The decisions you make before you hand out a delegation

1. Which scopes. Start from the two or three actions the agent demonstrably performs. Starting from the builder's permissions and trimming later never happens, because by then nobody can say what would break.

2. How long it lasts, and what happens when she is away. Set the end date when you create the grant, because the moment where somebody asks whether this is still needed does not arrive on its own. Two weeks of holiday is fine for booking pickup slots and not fine for approving payments.

3. Whether the person has to be present. A delegation she approves in the moment is the safest and the most annoying. One that keeps working through a refresh token lets the agent run at three in the morning, which is usually why you built it. That second one is a standing authority, so call it that.

4. What she sees when she grants it. A screen listing forty permissions is not consent in any workable sense, because nobody reads forty lines and none of them say which ones this agent will use. Two or three scopes in plain language plus an end date is a decision a person can genuinely make.

Withdrawing one agent's access without disabling the person

The requirement is narrow. You have to be able to take one agent's access away without touching the colleague's own account, and to answer who authorised this agent to do this.

RFC 7009 covers the first half. It defines the revocation endpoint, requires support for revoking refresh tokens, recommends it for access tokens, and says revoking a refresh token should invalidate the access tokens issued from the same grant. Revocation therefore lands at the speed of your access token lifetime: an agent holding a one-hour token keeps working for up to an hour after you pull the grant. The day the colleague leaves, her delegations have to go with her account, and something has to name the agents that stop working as a result, or you find out from the process that fails on the Tuesday after.

The second half is bookkeeping, not protocol. Who authorised this is only answerable if the grant exists as an object, with an identifier, a granter, a date, the scopes and an end date. From your platform, ask for one thing: a filter that finds every action one agent took, and every action taken for one person. Entra does that by marking the initiator and the performer of an audit event with an agentType, which tells a running agent apart from an agent's user account, the account type that lets an agent act as a user with user-delegated permissions.

An agent booking a pickup slot, from consent to log line

A wholesaler with forty staff runs an agent that books collection slots with the carrier. Lieve in logistics grants it access once: two scopes, pickup.read and pickup.create, no cancelling and nothing touching invoices, granted on 19 August 2026 for ninety days, so it ends on 17 November. The agent has an identity of its own, agent-logistics-03, and a named owner. Three weeks later the carrier disputes a slot, and this is the line you want to find.

{
  "time": "2026-09-04T09:12:44Z",
  "action": "pickup.create",
  "result": "BK-88214 for 2026-09-05",
  "actor": "agent-logistics-03",
  "on_behalf_of": "lieve.dm@example.be",
  "grant": "c7f3a2, granted 2026-08-19, expires 2026-11-17"
}

What happened, which agent did it, for whom, under which grant. On the shared service account you would have had the first field and a name that tells you nothing. On Lieve's own login you would have had a booking she would swear she never made.

That is also the test before you connect any agent to a system holding money or customer data. Ask which identity it will use. If the answer is a copy of somebody's login, stop there, because you are buying an audit trail that will lie to you. If the answer is the shared integration account, ask what else already runs on it. And if the answer is its own identity with a delegation, ask to see the scope list and the date it ends.