An agent receives a new token and everybody relaxes. The old token was for one service. The new token is for another. The plumbing works.
But what authority moved with it?
OAuth token exchange for AI agents is useful because a downstream tool should not have to accept whatever credential happened to enter the workflow. The exchange can produce a token suited to that tool. It does not, by itself, decide whether the acting service is entitled to use the subject’s authority.
That decision needs policy. Otherwise we have built an extremely efficient badge printer.
Start with a small delegation contract
Consider a fictional procurement workflow. Nadia, in the Cedar organisation, asks a procurement-review agent to explain invoice INV-204. The agent calls an invoice-fetcher service. The fetcher needs to read that invoice from the invoice API.
The intended contract is narrow: invoice-fetcher may read INV-204 for Nadia within Cedar. It may not change supplier details, read another tenant’s invoice or become Nadia for every service she can access.
The application records that grant through a trusted path. The authorisation server evaluates it when deciding whether to issue a downstream token. The invoice API enforces the applicable target and operation constraints. Those are proposed responsibilities in this example, not automatic behaviour supplied by an exchange endpoint.
RFC 8693 specifies the token exchange request. It requires a subject token and its type. An actor token is optional in the general protocol, with a corresponding type required when supplied. Whether a particular exchange represents delegation depends on the deployment’s policy and token semantics.
Subject, actor and client are different roles
In our proposed delegated token, Nadia is the subject. Invoice-fetcher is the current actor. The OAuth client requesting the exchange may be a registered broker. Those identifiers can differ legitimately.
The distinction matters when a team uses “client”, “agent” and “user” as synonyms. Authenticating the broker tells the authorisation server which client is requesting issuance. It does not automatically prove that invoice-fetcher may act for Nadia on this invoice.
For a JWT representation, the subject appears at top-level sub. The outer act identifies the current actor. A nested act can preserve a prior actor, such as procurement-reviewer. The identifiers need an unambiguous namespace; a bare name shared by multiple issuers is not a reliable global identity.
The crucial restriction in RFC 8693’s actor claim is easy to overlook: prior nested actors are informational and must not be used in access-control decisions. The token consumer considers the top-level claims and current actor.
A resource server should therefore not walk the chain until it finds a name on an allowlist. A previously authorised agent does not make every later actor authorised. That would turn delegation history into a family discount.
Audience is where, scope is what, and neither is the whole task
The invoice-fetcher asks for a token intended for https://invoices.example with invoices.read. The domain is illustrative. The audience identifies the intended recipient; the scope describes a class of permitted access.
Resource indicators let a client explicitly identify the protected resource it wants to access. They help the authorisation server issue a token for the right destination. They do not automatically express which invoice inside that service Nadia may read.
Our example still needs a trusted association with Cedar and INV-204. The application can enforce that through a supported constrained-token profile, a server-side grant lookup or another documented mechanism. Adding a custom claim has no effect unless the receiving service understands and enforces it.
OAuth’s current security guidance recommends narrowly restricted privileges and audience. For this workflow, one downstream service per exchange is a straightforward design choice. It is not a universal rule that every conforming exchange must request exactly one audience.
Multiple targets deserve particular care. An exchange request can ask for its scopes across all requested target services. Combining a long audience list and a long scope list may request much more than the developer intended. “We will tidy that up later” is how a read-only demonstration discovers a second career.
Define what the issuer is allowed to issue
For Cedar, the authorisation server should evaluate the authenticated client, validated subject and actor credentials, allowed actor-subject relationship, requested destination and requested privilege. It also needs the applicable grant and tenant context from trusted sources.
These checks are an example policy, not a universal provider configuration. The important test is that valid credentials are insufficient when their proposed relationship is invalid.
Try requesting supplier.write with the same valid inputs. Try an invoice token for a different tenant. Try an unapproved actor while keeping Nadia as the subject. Each request should meet a specific rejection rule under this contract.
Do not combine the subject’s permissions and actor’s permissions into a convenient union. An agent’s broad service access should not enlarge Nadia’s grant merely because both credentials passed authentication. If the system supports service-authorised work as well, make that a separate, explicit authority mode.
The resource server must finish the check
Issuance is not the last boundary. The invoice API must validate the credential it receives and apply its authorisation rules to the actual request.
For systems using the JWT access token profile, validation includes the expected token type, issuer, signature, audience and expiry. Reading a decoded JSON payload is not that validation. Nor should an agent client depend on peeking inside access tokens; the agreed server-side profile determines how the resource service consumes them.
After validation, the API checks the current actor and the relevant grant against the requested invoice and operation. If a broker issues a correctly signed but overly broad token, a downstream constraint can still matter. If the destination ignores the constraint, a beautifully detailed token will not enforce it by itself.
The agent identity record helps explain which actor belongs to which deployment. The audit trail records which checks and effects actually occurred. Neither should substitute for the API’s decision.
Do not assume the exchange keeps a live connection
An exchanged token is not automatically a live subscription to its inputs. RFC 8693 does not generally guarantee that revoking or renewing an input token changes the issued token. Deployment-specific mechanisms may provide tighter behaviour.
Decide the output lifetime and how current grants are checked. Document the delay and failure behaviour your system actually supports. For paused workflows, restoring a checkpoint is not fresh permission.
Token exchange earns its place when it makes the downstream authority more precise and reviewable. The question after an exchange should be concrete: which current actor may do what, for which subject, at which service, under which enforceable constraint?
If the answer is only “we got a 200”, the transport layer has had a good day. The authorisation design is still waiting for its turn.
