Use cases
Identity for AI agents: delegation, scoping and sender-constrained tokens
How to give an AI agent access to APIs without handing it a user's password or a long-lived key: delegation, narrow scopes, short tokens and DPoP.
The short answer
An AI agent acting for a user should never hold the user's password or a broad, long-lived API key. Give it its own client identity, obtain tokens that record it is acting on the user's behalf (RFC 8693 delegation with an act claim), keep those tokens narrowly scoped and short-lived, and sender-constrain them with DPoP so a token copied out of the agent's context cannot be replayed.
Sources last reviewed .
Why agents change the risk
Agents act autonomously, call many tools, and can be manipulated by the content they read (prompt injection). A credential in an agent is exposed to more inputs than a credential in an ordinary service, so the token it holds should be worth as little as possible to anyone else.
The pattern
- Register the agent as its own client, not as the user.
- When the user delegates, exchange the user's token for a delegated token naming the agent as actor, scoped to the specific tools and audience.
- Bind the token to a key held by the agent runtime with DPoP.
- Keep lifetimes short and require a new delegation for new scopes.
- Log subject and actor on every call, so actions are attributable to 'agent X for user Y'.
In Authreads
How this applies to Authreads
Machine and agent identity using DPoP (RFC 9449) and Token Exchange (RFC 8693) is Available in Authreads.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.