Delegated Authority (On-Behalf-Of)
An authorization model where an AI agent acts *for* a user without *impersonating* them — the agent's identity and the user's identity travel together as separate claims rather than the agent simply presenting the user's token. Implemented with OAuth Token Exchange (RFC 8693) (OAuth 2.0 Token Exchange, RFC 8693): the issued token carries the user in the `sub` (subject) claim and the agent nested in the `act` (actor) claim, with optional `may_act` declaring which actors a subject has authorized. The OpenID Foundation's October 2025 whitepaper on agentic AI names the move from impersonation to delegation as foundational, because delegation preserves accountability (audit logs show both parties), enables targeted revocation (kill the agent, keep the user), and makes 'a machine did this, unattended' an expressible fact.
Example
Instead of the agent calling the CRM as Alice (indistinguishable from Alice), it presents a delegated token: `sub=alice`, `act={sub: agent:sdr-bot}`. Salesforce logs the write as 'agent:sdr-bot on behalf of alice.' When the bot is compromised, security revokes the actor identity; Alice's own login keeps working.
Frequently asked questions
- What's the difference between delegation and impersonation?
- Impersonation replaces the caller's identity — downstream systems see only the user and can't tell a machine acted. Delegation adds the agent as a distinct actor alongside the user, so accountability and revocability are preserved. RFC 8693's `act` claim is the standard way to express delegation; impersonation is what happens by default when you hand an agent a raw user token.