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.
Related
Sources
- IETF, RFC 8693, OAuth 2.0 Token Exchange — https://www.rfc-editor.org/info/rfc8693/ (accessed 2026-10-03)
- IETF, RFC 6749, The OAuth 2.0 Authorization Framework — https://www.rfc-editor.org/rfc/rfc6749 (accessed 2026-10-03)
- IETF, draft-oauth-ai-agents-on-behalf-of-user-02 — https://datatracker.ietf.org/doc/html/draft-oauth-ai-agents-on-behalf-of-user-02 (accessed 2026-10-03)
- IETF, draft-klrc-aiagent-auth-00 — https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-00.html (accessed 2026-10-03)