Delegation is the explicit, scoped transfer of authority from a principal to an agent — the agent may do specific things, for a limited time, on the principal’s behalf, and no more.
Why it matters
Delegation is what separates an agent from a rogue process. It answers: on whose authority, and within what bounds? Without it, an agent’s actions cannot be distinguished from unauthorised use of a credential.
The standards lineage is OAuth:
- OAuth 2.0 (RFC 6749) is the original delegated-authorization framework: a client obtains a scoped access token to act for a user.
- Token exchange (RFC 8693) formalises delegation and impersonation, letting a service obtain a token for a different subject or scope.
- IETF work for AI agents extends OAuth for the agent case, carrying the agent’s identity through the consent step and into the token, so the resource server can see both the principal and the specific agent acting for it.
Delegation vs impersonation
- Delegation keeps both identities visible: the principal and the agent. Actions are attributable to both.
- Impersonation makes the agent look like the principal. It is sometimes necessary for legacy systems but loses the distinction KYA depends on.
Prefer delegation. If you must impersonate, log it and scope it tightly.
What a delegation record should express
- The principal granting authority.
- The agent receiving it.
- The permitted actions, resources, amount limits, and data scope.
- A validity window and expiry.
- How it is revoked.
How it works in practice
RFC 8693 defines a token-exchange flow in which a service presents a token and receives a new token for a different subject or scope, with a dedicated section on delegation versus impersonation semantics. That is what makes a delegation chain auditable: each hop carries who is acting and on whose behalf, rather than collapsing both into one credential.
Delegation also frames the OpenID Foundation’s warning about autonomous agents: current frameworks were built for simpler flows, not for recursive delegation chains or cross-domain trust propagation. Keeping each link explicit is the practical defence. See What is Know Your Agent? and the verification guide, with worked tokens in the code examples.
Related terms
Sources
- IETF, RFC 8693, OAuth 2.0 Token Exchange (accessed 2026-10-03)
- IETF, RFC 6749, The OAuth 2.0 Authorization Framework (accessed 2026-10-03)
- IETF, draft-oauth-ai-agents-on-behalf-of-user-02 (accessed 2026-10-03)
- IETF, draft-klrc-aiagent-auth-00, AI Agent Authentication and Authorization (accessed 2026-10-03)
- OpenID Foundation, Identity Management for Agentic AI (accessed 2026-10-03)
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.