OAuth Token Exchange for AI Agents

OAuth Token Exchange, standardized by RFC 8693, lets a client present one security token and request another token for a different context. That sounds ideal for AI agents that cross services, but exchange is not a universal credential adapter. Used carelessly, it can turn a narrow token into portable authority or erase the distinction between the agent, the user, and the upstream account.

The central design question is: what authorization fact permits the new token to exist? A valid subject token proves something about its issuer and audience. It does not automatically prove user consent for a new resource or permission to reveal an upstream credential.

What Token Exchange Actually Expresses

An RFC 8693 request can identify a subject token, an optional actor token, a target resource or audience, requested scope, and desired token type.

POST /oauth2/token HTTP/1.1
Host: authorization.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=SUBJECT_TOKEN
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=ACTOR_TOKEN
&actor_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https%3A%2F%2Fapi.example%2Finvoices
&scope=invoices.read

The authorization server still needs policy for the requested resource, scope, subject, actor, and delegation chain. Token exchange defines protocol fields and response semantics; it does not define that policy.

Three Agent Patterns That Look Similar

Downscoping for a child task

An orchestrator has authority for issues.read issues.comment and creates a short-lived token limited to issues.read for a research sub-agent. This is a strong token-exchange use case if the new audience, actor chain, expiry, and no-widening rule are enforced.

Crossing an internal service boundary

An authenticated agent calls a broker, which needs a token for a specific internal API. Exchange can preserve the original subject and current actor while changing audience. The receiving API must validate the resulting token profile and should not accept the original broader token.

Obtaining an upstream provider credential

An agent presents a gateway bearer and asks for a user’s provider token. This is often called “exchange,” but it changes credential domain and custody. A gateway bearer is not necessarily exchangeable under RFC 8693, and returning the provider token expands the client’s authority beyond the gateway’s tool controls.

Axec supports an SDK credential-exchange route for an already redeemed user gateway bearer. It selects one eligible Connection by connector_key or unique provider and returns a usable access credential without refresh-token delivery. This route is not the RFC 8693 grant, does not accept Application or management principals, and remains bounded by the live Grant. Prefer Axec’s proxy or MCP execution path when direct token possession is unnecessary.

Preserve the Full Delegation Chain

A secure exchange policy should evaluate at least:

Do not infer the actor solely from a mutable request header. Preserve actor information cryptographically or resolve it from authenticated client context. Limit delegation depth, reject cycles, and make the final resource server understand the token profile it receives.

How Axec Joins Two OAuth Relationships

Axec’s normal delegated flow does not exchange a user’s upstream token into an agent token. It joins two separate relationships through a Grant:

Application authenticates to Axec
  -> user consents to Connector capabilities
  -> Grant pins exact Application Credential and Connection
  -> Axec issues resource-bound gateway bearer
  -> gateway reloads Grant and executes with selected upstream credential

The client receives authority to invoke approved capabilities. The upstream credential can remain behind the gateway. This preserves revocation, tool filtering, and credential confidentiality better than distributing provider tokens to every agent component.

For autonomous workloads, Axec’s client_credentials flow is separate. It applies only to a static confidential Application’s own gateway and eligible vaulted or no-auth Connectors. It cannot be exchanged into a user’s delegated Connection because no user consent exists.

Practical Recommendations

Prefer execution over credential delivery

Use an MCP tool or narrowly defined HTTPS proxy whenever the client needs a result rather than the token itself. Deliver an access token only when the client must speak a protocol the gateway cannot mediate. Never return an upstream refresh token to an agent.

Downscope every dimension

Constrain audience, resource, scope, capability, credential source, token lifetime, and delegation depth. “Short-lived” is not enough if the token still reaches a broad audience.

Make exchange evidence attributable

Record the authenticated Application, user Grant, selected Connection, requested target, issued token type, and decision reason. Store no token values. Correlate subsequent use where the protocol permits it.

Security Caveats

Token exchange increases the number of issuers, token profiles, and trust relationships that resource servers must validate. A service that accepts both source and exchanged tokens may accidentally make downscoping optional. Audience confusion is especially dangerous when multiple APIs share signing keys.

Do not use exchange to bypass fresh consent when the target resource or capability was not previously approved. Exchange also cannot solve prompt injection: a correctly exchanged token can still be misused within its scope. Combine protocol controls with capability and argument enforcement.

FAQ

Is every “credential exchange” RFC 8693 token exchange?

No. Products use the phrase broadly. Confirm the grant type, token types, and semantics rather than assuming standards compatibility.

Should a child agent receive the parent’s token?

Prefer a narrower, audience-bound token or keep execution behind a broker. Sharing the parent token makes child isolation largely cosmetic.

Can an application token become a user token?

Not without a trusted user-delegation basis. In Axec, application-principal authority cannot access user Connections.

Primary References

• OAuth 2.0 Token Exchange (RFC 8693)
• JSON Web Token Best Current Practices (RFC 8725)
• Resource Indicators for OAuth 2.0 (RFC 8707)