Delegation means the agent keeps its own identity and acts on behalf of a user. Impersonation means the agent is treated as the user. RFC 8693 defines both. For agents, delegation is usually the better fit, because logs can show both the user and the agent.
The definitions
RFC 8693 extends OAuth 2.0 with token exchange. A client uses a new grant type at the token endpoint to request security tokens, including impersonation and delegation tokens.
In Section 1.1, impersonation means principal A gets B's rights in a defined context and is indistinguishable from B there. Receivers deal with B and may not know impersonation is happening. Delegation means A keeps its own identity and acts as an agent for B, so its actions are understood as taken on B's behalf.
Why the difference matters for agents
Consider an agent that files a ticket for a user.
- Under impersonation, the ticket system's log says the user filed it. If the agent was manipulated by injected text, the log blames the user.
- Under delegation, the log can show the agent acting for the user. An investigator can tell which actions were human and which were automated.
For audit, incident response and approval workflows, that distinction is the whole point.
How the tokens express it
In a token exchange request, the subject_token identifies the party on whose behalf the token is requested, and the actor_token identifies the party receiving delegated rights. Whether a composite token showing both parties is issued is up to the authorization server.
The act claim, defined in Section 4.1, identifies the current actor in a JWT. Nested act claims can record prior actors, most recent outermost, which is how a delegation chain across several agents can be shown. The RFC says only the top level claims and the current actor should be used for access control, and prior actors are informational.
Practical guidance
- Prefer delegation tokens that carry both identities when an agent acts for a person.
- Use the actor identity to apply agent specific limits, such as a narrower scope than the user holds.
- Base access decisions on the top level subject and current actor only, not on the chain history.
- Record both identities in the audit log.
- Ask whether your identity provider supports the actor claim before you design around it.
The RFC defines the request and response protocol only. It does not define token syntax, security properties or trust models, so you still need to decide those.
Where Safeguard fits
Safeguard includes agent identity so that agents are identified as themselves in the platform. That supports the same goal of keeping automated actions distinguishable from human ones.
Click through it at your own pace, or open it full screen.
Quick check
Does token exchange solve agent authorization by itself?
No. The RFC defines the exchange protocol only. Scopes, trust rules and audit practice are still your decisions.
Sources
Last reviewed: 19 October 2026.
