Delegated authority: how an agent proves it may act for you

An agent proves it may act for you by presenting a credential that the verifier can check. The credential should come from an issuer the verifier trusts, name you as the principal, name the agent allowed to use it, limit what it allows, expire soon, and be revocable. The verifier checks each of those before acting and keeps a record.

A2A provides the moment to ask for such a credential, the TASK_STATE_AUTH_REQUIRED task state, and deliberately stops there. The credential itself comes from other standards: OAuth 2.0 tokens with narrow scope and short lifetimes, OAuth Token Exchange (RFC 8693) for chains of agents, W3C Verifiable Credentials for portable claims, and, for payments, AP2 mandates.

The problem

Three parties are involved: the principal (a person or company), the agent acting for them, and the verifier (the business asked to do something). The verifier needs answers to five questions:

1. Who authorized this?
2. Which agent may use the authorization?
3. What exactly does it allow, and up to what limit?
4. Is it still valid?
5. What can we show later if someone disputes it?

The shortcut is impersonation: give the agent the person’s password or session so it looks like the person. RFC 8693 draws the line clearly. Under impersonation the actor is indistinguishable from the subject. Under delegation the actor keeps its own identity and acts as the subject’s representative (section 1.1). Impersonation hides the agent from the verifier, hands it every right the person has, and leaves no record that software acted. The FIDO Alliance’s April 2026 announcement of its agent standards work names this problem: today’s models can require users to share credentials with agents.

What A2A defines

A2A separates two kinds of authorization.

Request authentication (sections 7.3 to 7.5). The Agent Card declares schemes, the client obtains credentials out of band, and the server authenticates every request and applies its own policy. That policy may consider the skill requested, the action, data access rules and OAuth scopes.

In-task authorization (section 7.6). When an agent needs more authority mid-task, it tracks the work as a Task, moves it to TASK_STATE_AUTH_REQUIRED, and explains what it needs in the status message.

Illustrative task from a subscription provider’s agent, in A2A v1.0 shapes:

{
  "id": "task-5e21",
  "contextId": "ctx-77ab",
  "status": {
    "state": "TASK_STATE_AUTH_REQUIRED",
    "message": {
      "messageId": "msg-9c02",
      "taskId": "task-5e21",
      "contextId": "ctx-77ab",
      "role": "ROLE_AGENT",
      "parts": [
        { "text": "Cancelling subscription SUB-3310 needs approval from the account holder." }
      ]
    }
  }
}

The rules around this state matter:

• Credentials arrive out of band by default, over a secure channel. In-band exchange needs prior agreement or an extension (sections 7.6.1 and 7.6.3).
• A client that is itself an agent may pass the request upstream by putting its own task into the same state, which forms a chain (section 7.6.2).
• Credentials passed in-band SHOULD be bound to the agent that asked, so other agents in the chain cannot use them, and SHOULD be encrypted if sensitive (section 7.6.3).
• A2A does not define the scope, representation, validity or revocation of the credential. A credential obtained in this state must not be assumed to cover later messages on the task unless the implementation, issuer or extension says so (section 7.6.4). That subsection is on the specification’s main branch and was added after the v1.0.1 release.

A2A tells you when to ask. The rest of this guide is about what to hand over.

OAuth building blocks

OAuth 2.0 already covers most of what a delegated credential needs. RFC 9700, the OAuth security best current practice published in January 2025, collects the relevant rules.

Narrow scope and audience

RFC 9700 says access tokens SHOULD carry the minimum privileges needed, SHOULD be audience-restricted to one resource server or a small set, and SHOULD be restricted to specific resources and actions (section 2.3). The resource parameter from RFC 8707 names where a token will be used. Rich Authorization Requests (RFC 9396) replace coarse scope strings with typed authorization_details objects.

Illustrative authorization_details for a single cancellation:

[
  {
    "type": "subscription_change",
    "locations": ["https://api.provider.example/"],
    "actions": ["cancel"],
    "identifier": "SUB-3310"
  }
]

A token issued with this request cannot cancel a different subscription or change a payment method, even if someone manipulates the agent into trying.

Binding the token to the agent

A bearer token works for whoever holds it. RFC 9700 says servers SHOULD use sender-constrained access tokens (section 2.2.1), through mutual TLS certificate binding (RFC 8705) or DPoP (RFC 9449). With DPoP the agent proves possession of a private key on each request, and the token only works alongside that proof. This is the OAuth version of A2A’s advice to bind credentials to the requesting agent.

Short lifetimes

RFC 8693 suggests limiting delegated rights with the scope claim and a limited token lifetime (section 5). A token that expires in minutes limits the damage if it leaks and reduces your dependence on revocation.

Token exchange and the actor claim

RFC 8693 lets a client trade one token for another at an authorization server. The request uses the grant type urn:ietf:params:oauth:grant-type:token-exchange, a subject_token for the party being represented, an optional actor_token for the party that will act, and optional resource, audience and scope parameters to narrow the result.

When the new token is a JWT, delegation appears in the act claim (section 4.1). Illustrative claims for a token that lets an assistant’s billing agent act for a customer, after the assistant’s concierge agent handed the task over:

{
  "iss": "https://auth.provider.example",
  "aud": "https://api.provider.example/",
  "sub": "customer-88121",
  "scope": "subscription:cancel",
  "exp": 1790000600,
  "act": {
    "sub": "https://agents.assistant.example/billing",
    "act": {
      "sub": "https://agents.assistant.example/concierge"
    }
  }
}

The outermost act names the current actor. Nested act claims record earlier actors as a history trail, and RFC 8693 says access decisions use only the top-level claims and the current actor. A related may_act claim states in advance which party may become the actor (section 4.4), so an authorization server can check it before issuing the exchanged token.

Token exchange fits A2A chains. Each hop can exchange the token it received for a narrower one aimed at the next agent, so no downstream agent holds more than its step needs. The OWASP Top 10 for LLM Applications 2026 gives the same advice for multi-agent workflows under LLM03 Excessive Agency: carry the original user’s context and authorization scope across chained calls, instead of relying on the calling agent’s own permissions.

Verifiable credentials

The W3C Verifiable Credentials Data Model v2.0 became a W3C Recommendation on 15 May 2025. It defines an issuer that asserts claims, a holder that stores credentials and presents them, and a verifier that receives them. A credential can carry a validity window (validFrom, validUntil) and a credentialStatus entry that tells a verifier where to check whether it has been revoked or suspended. Bitstring Status List v1.0, a Recommendation published the same day, defines one such status mechanism.

Verifiable credentials suit delegation when the verifier has no direct relationship with the principal’s identity provider: the credential travels with the agent and is checked against the issuer’s key. The specification is clear about the limit. It says verifiable credentials identify subjects and are not an appropriate authorization tool without an accompanying authorization framework (section 5.9). A credential stating “this agent acts for Jane” still needs a policy that says what Jane’s agent may do.

AP2 mandates: delegation for payments

The Agent Payments Protocol (AP2) is a delegation scheme built for one domain: purchases. Version 0.2, released on 28 April 2026, rests on a general Agent Authorization model with two steps:

1. Mandate delegation. The agent drafts mandate content. The user reviews and approves it on a Trusted Surface, an interface the specification says MUST be non-agentic. The resulting signed mandate goes back to the agent.
2. Action authorization. A verifier asks for proof, the agent presents a mandate, and the verifier checks it and returns a signed receipt.

AP2 defines two mandate types, each an SD-JWT. The Checkout Mandate is verified by the merchant and bound by hash to a checkout the merchant signed. The Payment Mandate is verified by the credential provider, the network and the payment processor. When the user is present, they approve the final (“closed”) mandates directly. When they are not, they approve “open” mandates that carry constraints and the agent’s public key in a cnf claim. The agent later signs closed mandates that must satisfy every constraint, such as an amount range, a budget, allowed payees or an execution date. Unknown constraint types fail verification, and the specification recommends setting expiry as short as the task allows.

Two gaps are worth knowing. AP2 v0.2 puts delegation of a mandate from one shopping agent to another out of scope. It also defines no way for the user to revoke a mandate. It limits reuse instead: an agent must not present a further open mandate without a rejection receipt for the previous one. Google is donating AP2 to the FIDO Alliance, whose Payments Technical Working Group is developing agent commerce specifications. Agent payments covers AP2 end to end.

Revocation

A principal must be able to withdraw authority, and the verifier must notice. The mechanisms differ by credential type:

Credential	How a verifier learns it was withdrawn
OAuth access or refresh token	Revoked at the authorization server (RFC 7009); resource servers check with token introspection (RFC 7662) or rely on short expiry
Verifiable credential	The issuer updates the status entry that credentialStatus points to
AP2 mandate	Expiry and single-use rules; no revocation mechanism in v0.2
Credential obtained through TASK_STATE_AUTH_REQUIRED	Not defined by A2A; your implementation or extension must define it

Self-contained tokens such as JWTs verify without a network call. That is fast, but a revoked token stays usable until it expires unless the resource server introspects it. Choose lifetimes with that in mind. A2A section 13.4 says agents SHOULD implement credential revocation mechanisms.

Audit

Delegation is only as defensible as the record it leaves. At the verifier, log the principal, the acting agent and any earlier actors, the credential’s identifier and issuer, the exact action and parameters, and the result. A2A section 13.4 asks for audit trails of sensitive operations and says logs must not include credentials or personal data unless required and protected. AP2 goes further for payments: its mandates and receipts together serve as evidence of what the user and each party saw.

Comparing the options

Mechanism	Names the principal	Binds the agent	Scope	Expiry	Revocation	Status
OAuth access token	sub	With DPoP or mTLS binding	Scopes, authorization_details	exp	RFC 7009, introspection	IETF RFCs
Token exchange	sub	act, plus sender binding	Narrowed at each hop	exp	As for OAuth	RFC 8693 (January 2020)
Verifiable credential	credentialSubject	Depends on the securing mechanism	Whatever the claims say; needs a policy layer	validUntil	credentialStatus	W3C Recommendation (May 2025)
AP2 mandate	User signature or a trusted user credential	cnf key in open mandates	Checkout and payment constraints	exp	Not defined in v0.2	v0.2, being donated to FIDO

Putting it together

Illustrative. A customer asks their assistant to cancel a streaming subscription.

1. The assistant’s agent sends SendMessage to the provider’s A2A endpoint, authenticated with the client credentials the provider issued to the assistant platform.
2. The provider’s agent needs the account holder’s consent. It moves the task to TASK_STATE_AUTH_REQUIRED and explains why.
3. The assistant opens the provider’s own consent page. The customer signs in there and approves one action: cancel SUB-3310.
4. The provider’s authorization server issues the assistant’s agent a DPoP-bound token with sub set to the customer, authorization_details for that one cancellation, an audience of the subscription API, and a ten-minute lifetime.
5. The assistant’s agent sends a follow-up message on the same task, presenting the new token and a DPoP proof in the request headers.
6. The provider’s agent checks the token against the exact operation, cancels, logs the principal, client, token identifier and result, and completes the task.

The token cannot be used for anything else and expires shortly. No password changed hands, and both the customer and the agent appear in the record.

Emissar’s Mandate module is a proposal for the credential that A2A leaves undefined: scoped to specific actions and limits, bound to the requesting agent, revocable, and carried as an A2A extension. Its status is Spec in progress.