Rich Authorization Requests for AI Agents: Carry the Grant into Policy

OAuth scopes often collapse an agent's authority into a label such as payments.write. RFC 9396 adds authorization_details, a structured way to request and grant specific authorization data. An agent can receive limits for an action and resource, together with location and transaction limits, instead of carrying one broad string into every call.

The useful security step comes after issuance. The application must bind that verified grant to the authenticated model request and the action the agent is planning. A JSON object in a token is evidence only when policy checks it.

TL;DR

• RFC 9396 defines structured authorization details for OAuth authorization requests and tokens.
• Validate the detail type and resource. Check the action and limits, then the issuer and audience. Confirm expiry before use.
• Carry the granted detail into the policy decision for the authenticated LLM route.
• Consent and token issuance remain outside the AI gateway. Downstream business-API enforcement does too.

RFC 9396 adds a typed grant

RFC 9396 defines Rich Authorization Requests and the authorization_details parameter. Each detail has a type and can include fields defined for that authorization-data type. RFC 8707 defines resource indicators that let a client identify the protected resource for which access is requested.

For an agent, define types around actual business authority. A payment detail might identify the action and account, along with the currency and maximum amount. It might also name the payee class and expiry. A support detail might identify the tenant and ticket queue, along with permitted operations and an escalation condition.

Avoid free-text policy fields. Use documented types and stable identifiers. Add enumerated actions and machine-checked limits. Version the schema and reject unknown required fields. A pale green token viewer showing amount: 5000 is not enough unless the policy knows the currency and resource as well as the operation.

Validate the grant before model use

Verify the token signature and issuer, followed by audience and expiry. Check the subject and client, then the resource and authorization details. Confirm that the authorization server and detail type are approved for the use case. Bind the grant to the user or workload that initiated the agent session.

The AI agent authorization guide covers delegation more broadly. RAR supplies one structured input. It does not prove that the planned action matches the user's intent or that the target API will accept it.

Store a normalized authorization context with the session: detail type and version, resource, actions, constraints, grant identifier, subject, issuer, expiry, and verification result. Keep the raw token under the approved secret-handling design rather than copying it into prompts or logs.

Carry constraints into the LLM request policy

When the agent sends context to an LLM, include a signed reference to the verified authorization context. Policy can evaluate the authenticated identity, role, use case, model destination, data class, and granted action limits before forwarding the request.

For example, a purchase agent with authority for one supplier and a $2,000 ceiling should use a model route approved for that workflow. A request that asks the model to plan a $7,500 transfer should be denied or sent for approval even before any business API call occurs.

The gateway decision is an early control. The downstream resource server must still enforce the granted authorization when the agent invokes the actual API. The model's text cannot expand the grant. Per-route AI policies describes the route-level decision.

Preserve one joined evidence chain

Record the subject or workload, client, authorization server, grant identifier, detail type and version, approved resource, actions and limits, model route, data classification, policy version, decision, reason, and time. Use a correlation identifier that follows the planned action to the downstream API event.

Do not log access tokens, refresh tokens, private keys, or unnecessary business content. Preserve verification status and references instead. Restrict access to grant details that expose sensitive accounts or transactions.

During review, choose one completed action and reconstruct the consent or authorization decision, token issuance, model request, gateway policy, user approval if required, and resource-server result. The chain should show that no component silently widened authority.

Revocation and change need fail-closed behavior

Short lifetimes reduce stale authority, but agents can keep plans and context after a token expires. Revalidate before consequential model calls and before the final business API action. Handle revocation, user removal, resource changes, and policy-version changes.

If the authorization server is unavailable, follow the approved failure policy. A financial action should usually stop. A low-risk read may use a bounded cached verification if the design explicitly allows it. Record the decision and cache age.

A changed authorization detail should create a new grant identifier or versioned record. Never overwrite the evidence attached to an earlier action.

DeepInspect

DeepInspect can evaluate verified authorization context for authenticated HTTP model traffic deliberately routed through it. Policy can combine the user or workload identity, role, RAR detail reference, data classification, model destination, and use case before forwarding the request.

Consent, authorization-server policy, token issuance, revocation, and downstream resource-server enforcement remain with their respective systems. The gateway provides an additional decision and evidence point at the LLM boundary.

Book a technical deep dive at deepinspect.ai.