Does RFC 8693 authorize an agent's prompt?

RFC 8693 defines how a client requests and receives another security token. The authorization server decides if the exchange is allowed and what token to issue. The AI gateway separately decides if the authenticated prompt, route, data class, and model destination comply with policy. The standard has no model-behavior rules.

Is the actor token required for delegation?

The actor_token parameter is optional in the base request syntax, but RFC 8693's delegation model uses actor information to distinguish the acting party from the subject. A request containing only a subject token can produce impersonation semantics. Document the authorization server's profile and verify the issued token preserves the actor needed for the audit trail.

Should the exchanged token go to the LLM provider?

Present it to the resource named by its audience or resource restriction. In this architecture, that resource is the AI gateway. The gateway can authenticate to the provider with a separate provider credential after policy permits the request. Sending an enterprise delegation token to an unrelated provider creates an audience failure and unnecessary disclosure.

Does an act claim prove every earlier hop was authorized?

The act claim identifies the current actor, and nested claims can retain prior actors as history. RFC 8693 says prior actors in nested act claims are informational for access-control policy. Verification still depends on issuer trust, token validation, authorization-server policy, and the deployment's exchange records.

RFC 8693 Agent Delegation: Token Exchange at the LLM Request Boundary

RFC 8693 gives an OAuth client a precise exchange: present a security token to an authorization server and request a new token suited to a downstream service. In an agent deployment, that downstream service can be an AI gateway handling authenticated HTTP requests to an LLM. The exchange can retain the user as the subject and identify the agent as the actor. It can also narrow the token to the gateway's resource or audience.

I want to separate that useful identity evidence from the claims the standard never makes. RFC 8693 defines token exchange. Your authorization server and gateway policy still own the decisions around it. The application and model provider also own those decisions.

TL;DR

RFC 8693 defines an OAuth 2.0 token exchange protocol, including subject and actor fields. It also defines target and scope fields. A separate field describes the issued token.
An agent can exchange an upstream user token plus its actor credential for a short-lived token intended for an AI gateway.
The gateway verifies that token on the authenticated HTTP model request, then applies its own prompt and route policy. Separate policy covers data and model use.
RFC 8693 supplies delegation evidence. It sets no rules for LLM reasoning or output safety. It also does not govern tool choice or business authorization.

RFC 8693 defines the token exchange boundary

The IETF published RFC 8693, OAuth 2.0 Token Exchange, in January 2020. It defines an HTTP and JSON Security Token Service protocol built on the OAuth 2.0 token endpoint. The client sends an HTTP POST with the token-exchange grant type, and the authorization server returns a token response after validation and policy checks.

The RFC limits its scope to this request-and-response protocol. Token syntax and trust models remain deployment concerns. Signing and encryption choices do too. The eventual use of the issued token also remains a deployment concern. That boundary deserves a yellow sticky note on the architecture diagram. RFC 8693 cannot tell an agent which model to call or decide if a prompt contains source code. It also cannot judge if a generated answer is safe to release.

The standard can provide authenticated evidence about the represented and acting parties. It can also show where the issued token is meant to be used. A separate policy decision consumes that evidence.

Subject and actor preserve two identities

RFC 8693 distinguishes delegation from impersonation. Under delegation, the actor keeps its own identity while representing another principal. This is the right semantic shape for an agent acting for a user because an audit record should retain both parties.

The required subject_token is the token for the party on whose behalf the exchange is requested. In a user-driven agent session, that token commonly belongs to the authenticated user. The optional actor_token is the token for the acting party, such as the agent workload. When the authorization server issues a composite token, the JWT act claim can identify the current actor. Nested act claims can preserve earlier actors as informational history.

RFC 8693 leaves issuance of a composite token to authorization-server policy and configuration. Supplying both input tokens creates a request for delegation semantics; it does not force the server to mint a particular claim set. The deployment profile must document the resulting subject, actor, issuer, audience, scope, and lifetime.

A trusted issuer can bind those identities cryptographically. The AI agent identity pattern needs that evidence rather than a user ID in a custom header that the agent can rewrite.

The authenticated HTTP flow has two separate requests

The clean deployment has one token request and one protected model request. Treating them as separate hops prevents the model endpoint and the OAuth token endpoint from becoming one vague box on a slide.

First, the agent authenticates to the authorization server and sends a token-exchange POST. RFC 8693 names the grant type urn:ietf:params:oauth:grant-type:token-exchange. The request carries the user's subject_token and its type. A delegation deployment also supplies the agent's actor_token and matching type. The resource or audience identifies the AI gateway, while scope asks for the authority needed on that route.

Second, the authorization server validates the inputs and applies its policy. A successful response carries the issued credential in access_token. Two required fields describe its representation and usage method, while expires_in is recommended. If the server returns a bearer token, the agent presents it on the later HTTPS request using the Authorization header described by RFC 6750. That official bearer-token specification requires TLS and recommends the Authorization: Bearer method for authenticated resource requests.

The gateway is the OAuth resource server in this mapping. It validates the exchanged token before inspecting or forwarding the model request. The provider-facing LLM call may use a separate provider credential held by the gateway. RFC 8693 does not require OpenAI, Anthropic, Bedrock, or another model endpoint to accept the exchanged enterprise token.

Target and scope should name the gateway route

RFC 8693 lets the client request a token for a resource, an audience, or both. It also permits a service-specific scope. For an AI gateway, use a stable HTTPS resource identifier or a logical audience that resolves to the gateway, rather than minting a broadly reusable token for every internal API.

The authorization server can then issue a token constrained to a named model route, such as an approved summarization service. Keep the requested target set small. The RFC explains that multiple resources combined with multiple scopes create the Cartesian product of requested rights, which widens the request quickly.

A token accepted by every model route is a service account wearing OAuth clothing. Ask for the route and authority needed for the current task. Pair the token with a short lifetime, then reject audience or resource mismatches at the gateway.

OAuth scopes remain service-defined strings under the OAuth 2.0 framework in RFC 6749. They can describe coarse authority such as llm.summarize. The gateway still needs request-time context for the actual decision. Rich Authorization Requests for AI agents covers structured transaction constraints when a scope string carries too little detail.

Gateway policy consumes delegation evidence

After token validation, the gateway can evaluate the verified subject, current actor, client, issuer, target, scope, and expiry alongside request facts the token exchange never sees. Those facts include the model route, prompt data classification, user role, use case, tenant, and organizational policy version.

This is the authenticated HTTP boundary: an identified agent sends a deliberately routed HTTPS model request through the gateway, the gateway verifies the exchanged token, and policy decides whether that request may reach the LLM. The per-decision record should retain stable references for the subject and actor, authorization server, audience or resource, granted scope, model route, policy version, classification result, decision, reason, and timestamp. Raw access tokens belong in neither prompt text nor ordinary audit logs.

The AI agent authorization guide describes that request-time policy layer. RFC 8693 supplies inputs to it. The standard does not prove that the user intended the prompt or that the prompt complies with company policy. It also does not prove that a later tool call is authorized by its target API.

Security review needs the deployment choices

A review should verify the choices RFC 8693 deliberately leaves open. Start with client authentication at the exchange endpoint and the accepted credential types for subjects and actors. Record trusted issuers, signature rules, audience or resource checks, scope policy, output lifetime, encryption requirements, and revocation handling. The RFC warns that an unauthenticated client can let anyone holding a compromised token exchange it into another token.

Revocation needs explicit design. RFC 8693 says an exchange leaves the input tokens valid unless their token semantics say otherwise, and propagation of revocation is implementation-specific. Short output lifetimes reduce exposure, but they do not create revocation propagation by themselves.

Keep privacy in the review as well. The RFC requires encrypted channels for tokens containing sensitive information and recommends including only the minimum necessary data. A stable pseudonymous subject plus a trusted server-side identity lookup may be preferable to placing an employee email address in every token.

Local agent execution, STDIO tool traffic, stolen provider keys, and direct calls that bypass the gateway sit outside this HTTP control point. Host hardening, EDR, secret management, egress controls, and downstream API authorization own those paths. Token exchange evidence is valuable only on traffic that actually presents the token to the intended resource server.

DeepInspect

DeepInspect can be the OAuth resource server and policy enforcement point for authenticated HTTP traffic deliberately routed between agents and LLMs. It can validate the exchanged token, bind verified subject and actor context to the model request, classify prompt data, apply per-route policy, and produce a per-decision audit record before forwarding traffic.

The authorization server owns token exchange, client authentication, issuance policy, and revocation. The agent application owns the upstream user session and token request. Model providers own model behavior, while downstream APIs enforce their own business actions. DeepInspect adds the identity-aware decision at the LLM HTTP boundary.

Book a technical deep dive at deepinspect.ai.