Agent mandate or OAuth token? The difference
OAuth tokens and agent mandates are often confused because both allow something. A token opens a door; a mandate says what is allowed behind the door on whose behalf. In practice, both are often needed.
Leutrim Miftaraj, Founder, Innopulse Consulting GmbH
Published
Key points
- OAuth governs access to an interface, a mandate the individual action on someone's behalf.
- A mandate can be verified independently of the authorization server and revoked through a status list.
- Actions with consequences usually need both: access through OAuth and authority through a mandate.
What this is about
An OAuth access token allows a client to access a resource on behalf of a user: read a calendar, create orders, initiate payments. Which kinds of access are allowed is governed by scopes, or more finely by Rich Authorization Requests. The token applies at the authorization server and the connected interfaces.
An agent mandate, by contrast, describes the instruction: who acts for whom, which actions are allowed, up to which amount, with which counterparties, for how long. It is signed and can be verified by any party, including one that has never seen the authorization server.
The comparison
| Feature | OAuth access token | Agent mandate |
|---|---|---|
| Purpose | Access to a resource | Authority for actions on someone's behalf |
| Verified by | The provider's resource server | Any verifying party with the issuer's key |
| Limits | Scopes, with RAR concrete details | Action types, amounts, counterparties, validity |
| Lifetime | Minutes to hours | Days to months, revocable |
| Revocation | At the authorization server | Through a status list, verifiable offline |
| Proof afterwards | The provider's log | Independently recomputable with decision and receipt |
When to use what
- OAuth only: the agent reads data or carries out actions without significant consequences, and only the provider itself needs to trace the access.
- OAuth and mandate: the agent triggers actions with consequences, such as payments or orders, and third parties such as merchants, banks or auditors must be able to verify later whether they were allowed.
- Mandate only: the agent presents its instruction to a counterpart with which there is no shared authorization server, such as an unfamiliar merchant.
How the two work together
In many architectures, the agent signs in to an interface with OAuth and additionally presents its mandate for an action. A gateway checks before execution whether the action lies within the mandate, signs a decision and records the result in a receipt. Access stays with the provider, and the proof of authority becomes portable.
Whoever uses RAR can match the authorization_details against the mandate's limits. A token whose details go beyond the mandate is a warning sign.
The role of KYA
KYA does not verify OAuth tokens. It verifies mandates, decisions and receipts and answers the question OAuth leaves open: was exactly this action allowed on someone's behalf? The result is a certificate every side can recompute.
Common misconceptions
- “A fine-grained scope is the same as a mandate.” Even the finest scope names no principal and cannot be verified outside the authorization server.
- “Whoever has a token was authorized.” A token shows access, not whether the specific action was within the instruction. With manipulated agents in particular, the two diverge.
- “A mandate replaces sign-in.” No. Access to an interface remains a matter for OAuth; the mandate is added for actions with consequences.
Decision guide in three questions
- Does the action have consequences for money, contracts or rights? Then a mandate is needed in addition.
- Must someone outside your system verify the action later? Then the evidence must be portable.
- Should a single authority be revocable without blocking access? Then it belongs in a mandate with a status list.
Frequently asked questions
Is an OAuth token an authorization for an AI agent?
Only in the sense of access. It allows access to a resource but describes neither the principal nor the limits of a single action in a way third parties can verify.
Do I need a mandate if I already use OAuth?
For actions with consequences that third parties should trace later, yes. For pure read access within one provider, OAuth is often enough.
Can RAR and a mandate contain the same limits?
Yes. It makes sense to set the limits in the mandate and derive the authorization_details from them, so access and authority match.
Who verifies a mandate?
Any party that knows the issuer's key: merchants, banks, authorities or auditors. KYA verifies mandates locally in the browser or in one's own system.
Can a mandate be embedded in an OAuth token?
In principle, details of a mandate can be carried into a token. The token remains bound to the authorization server, however; the portable, independently verifiable evidence is the signed mandate itself.
What about OpenID Connect?
OpenID Connect adds user sign-in to OAuth and provides identity details. Like OAuth, it says nothing about an agent's authority for a single action.
Sources
- OAuth 2.1 (IETF-Entwurf): https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
- RFC 9396: Rich Authorization Requests: https://www.rfc-editor.org/rfc/rfc9396
- SD-JWT VC (IETF): https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/