Delegated Authorization for AI Agents Acting on Behalf of Users

An agent acting for a user should receive a short-lived grant for one audience, tenant, task, and set of operations. Downstream services must be able to distinguish the human subject from the agent actor, enforce their own policy, and reject authority the user never granted. Never forward a broad user bearer token through an agent chain.

OAuth token exchange can represent delegation using a subject token and, optionally, an actor token. RFC 8693 standardizes that exchange, but the authorization server's local policy still decides whether to issue a token and what claims or scopes it contains.

Keep three identities distinct

human subject:   user-381 requested a refund preview
client:          support-console initiated the workflow
agent actor:     refund-agent-7 is executing the task
resource server: billing-api enforces the final decision

Do not collapse these into a single sub. Your audit and policy need to answer both “whose authority?” and “which workload acted?” A machine-only maintenance agent may have no human subject; do not manufacture one.

Define the delegation record independently of any token format:

type Delegation = Readonly<{
  humanSubject?: string;
  actor: string;
  clientId: string;
  tenantId: string;
  taskId: string;
  audience: string;
  scopes: readonly string[];
  resourceIds: readonly string[];
  issuedAt: string;
  expiresAt: string;
  parentDelegationId?: string;
}>;

The application type is illustrative. Resource IDs and business limits may live in an authorization service rather than a token to avoid disclosure and oversized credentials.

Start from explicit user intent

The grant should be derived from the authenticated interaction:

User intent: “Prepare a refund preview for invoice I-92.”
Allowed now: read I-92, calculate preview
Not allowed: submit refund, read other invoices, email customer

The model's restatement of intent is not authoritative. A trusted workflow maps the UI action or verified request to a policy template. If the user later approves the exact preview, issue a separate one-use commit grant.

Authorization screens should name the service, operation, resource class, duration, and consequence. Avoid vague scopes such as “Allow this agent to manage your account.” The user must be able to decline without that being interpreted as approval or an error that triggers retries. This interaction records a product authorization decision; whether it satisfies a separate legal-consent requirement depends on the specific use and jurisdiction.

Exchange instead of forwarding

With RFC 8693, the agent or its trusted runtime sends a token-exchange request to the authorization server. Conceptually:

grant_type = urn:ietf:params:oauth:grant-type:token-exchange
subject_token = token representing the user grant
subject_token_type = declared token type
actor_token = token authenticating the agent workload
actor_token_type = declared token type
resource = urn:example:billing-api
scope = invoices:read refunds:preview

The authorization server validates both tokens and delegation policy, then may issue a token for the billing API. Token exchange does not invalidate the input tokens and does not automatically propagate later revocation; RFC 8693 says those behaviors are deployment-specific. Design revocation deliberately.

Do not request several audiences “just in case.” RFC 8693 warns that requested rights effectively combine scopes and target services, increasing breadth and the likelihood a request cannot safely be fulfilled. Prefer one audience per token.

RFC 8707 defines the OAuth resource parameter. The resource server must validate that the issued token is intended for it; a token for the agent gateway must not be accepted by billing.

Attenuate every hop

Suppose a supervisor agent delegates invoice lookup to a specialist:

user → supervisor: invoices:read + refunds:preview on I-92
supervisor → specialist: invoices:read on I-92

The child grant is a subset. It cannot lengthen expiry, add resources, change tenant, add a target service, or acquire commit authority. A policy service—not free-form agent messaging—validates that attenuation and binds the new token to the specialist workload.

Do not allow a downstream agent to reuse its token when calling a third service unless that third audience was explicitly authorized. Exchange again for a narrower token and preserve the actor chain in protected audit data.

For A2A, authentication credentials belong in transport headers, not Messages or Artifacts. The remote agent remains independently responsible for authorization. A skill advertised in an Agent Card is not permission to call it (A2A authentication and authorization).

Enforce policy at the resource server

The billing API validates:

1. issuer and signature or introspection result;
2. audience exactly includes billing;
3. time bounds and revocation state;
4. authenticated actor or sender constraint;
5. required scope;
6. tenant membership;
7. invoice-level authorization;
8. allowed state transition; and
9. approval and idempotency for commits.

A valid delegated token is necessary, not sufficient. refunds:preview does not authorize every invoice or bypass refund rules.

The OAuth Security Best Current Practice recommends privilege-restricted and audience-restricted access tokens and discusses sender constraint to reduce replay (RFC 9700). DPoP can bind a token to a key held by the agent runtime, but DPoP is not client authentication or authorization by itself (RFC 9449).

Bind high-impact authorization to the transaction

For commit operations, scope names are too coarse. Store a transaction approval:

{
  "approvalId": "apr_18d2",
  "subject": "user-381",
  "actor": "refund-agent-7",
  "tenant": "acme",
  "operation": "submit_refund",
  "invoiceId": "I-92",
  "amountMinor": 4200,
  "currency": "USD",
  "previewRevision": 3,
  "expiresAt": "2026-07-18T20:00:00Z"
}

At commit, compare every field against authoritative current state and consume the approval once. If recipient, amount, invoice, actor, or revision changes, ask again. The OWASP Transaction Authorization Cheat Sheet recommends making authorization credentials unique per operation and ensuring the user understands the significant transaction data.

Handle background and offline work explicitly

An agent that continues after the user leaves needs a documented offline grant, not an endlessly cached interactive token. Limit duration, tasks, resources, and maximum effects. Give the user a way to inspect and revoke active delegations.

Refresh tokens increase persistence and theft impact. Store them only in a secrets service, bind them to the correct client where supported, rotate according to authorization-server policy, and revoke the delegation when the task ends. Do not give refresh tokens to the model process.

For scheduled workloads, consider a service identity plus server-side policy referencing the user's standing authorization. This makes revocation and review clearer than a long-lived impersonation token.

Prevent confused-deputy failures

• Do not trust a user ID, tenant, or “approved” flag from tool arguments.
• Do not accept tokens issued for another resource.
• Do not let the agent choose an arbitrary downstream audience.
• Do not convert a user token into a workload token that loses subject attribution.
• Do not use a more privileged service credential merely because token exchange failed.
• Do not let a delegated agent pass your credentials to its own tools.

Fail closed for sensitive actions when authorization infrastructure is unavailable. A read-only degraded path must be explicitly designed and limited to data already authorized.

Test the delegation graph

• The actor is valid but the human lacks resource access.
• The user is valid but the actor is not approved for the workflow.
• A token is replayed at the wrong audience.
• A child asks for broader scopes, resources, duration, or tenant.
• A task continues after delegation revocation.
• Two concurrent calls consume one approval.
• An agent swaps the approved invoice or amount.
• A service token accidentally erases the human attribution.
• Logs expose the subject or actor bearer token.
• Authorization failure triggers an unsafe credential fallback.

Release checklist

• Preserve human subject, client, and agent actor separately.
• Derive grants from verified intent, not model prose.
• Issue one short-lived audience-bound token per downstream service.
• Attenuate scope, resources, duration, and effects at every hop.
• Enforce tenant, object, state, and approval at the resource server.
• Bind commit authorization to exact transaction details.
• Keep tokens out of prompts, Messages, Artifacts, and logs.
• Define offline grants, refresh, revocation, and task-end cleanup.
• Record a protected delegation chain for incident response.
• Test confused-deputy and privilege-amplification paths.