Agent Operation Authorization

In agent-based systems, especially those involving generative capabilities, it is essential to convey not only what actions are permitted, but also the original intent behind them and conditions under which an autonomous agent may act on behalf of a principal. This document specifies the Agent Operation Authorization framework — a mechanism that enables verifiable delegation of actions from human principals to autonomous AI agents with fine-grained agent operation authorization. The framework includes Agent Operation Authorization Proposal and Agent Operation Authorization phases. This specification defines several new JSON Web Token (JWT) claims to support agent operation authorization: agent_operation_proposal (used in authorization requests), agent_operation_authorization (used in access tokens), agent_identity (for verified agent-user binding), evidence (for user intent provenance), and context (for policy evaluation in proposal phase). These claims enable fine-grained control over autonomous agent operations and ensure cryptographic verification of user intent. The AI agent constructs a structured agent_operation_proposal object and submits it to the Authorization Server (AS) via OAuth 2.0 Pushed Authorization Requests (PAR) [RFC9126], without including the user's original natural-language instruction. This design ensures that downstream verifiers can validate both the policy boundaries and the provenance of the initiating instruction, without dependency on Decentralized Identifiers (DIDs). This enables secure, auditable delegation for autonomous AI Agent. As an optional enhancement for user experience, the agent MAY include a reference (e.g., a hash or identifier) to the original user prompt in the PAR request. This reference can be used by the AS to display the original user intent during the authorization consent process, and MAY be included in the final authorization token for audit purposes. Upon successful user confirmation and authentication of the Authorization Proposal during the first phase, the Authorization Server (AS) SHALL issue an Agent Operation Authorization Token. This token serves as the access token for subsequent interactions. The agent MUST present this JWT access token when accessing protected resources at the AS, using the mechanisms defined in OAuth 2.0 [RFC6749] and bearer token usage rules [RFC6750]. Together, these components ensure that AI systems act only within user-approved boundaries, mitigating risks such as hallucination. It is designed for use in autonomous AI Agent system, multi-agent orchestration, and regulated domains such as finance, healthcare, and public services — particularly where accountability and auditability are important. The framework supports enterprise identity providers, and zero-trust architectures.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and RFC 8174 [RFC8174].

The PAR-JWT (Pushed Authorization Request in JWT format) is used in the first phase. Its purpose is to deliver the agent-proposed operational strategy to the AS, enabling the generation of a high-quality consent UI and establishing an evidentiary starting point, without including the user's original input. Its format is defined as follows:

The agent_user_binding_proposal claim is a structured JSON object proposed by the client (e.g., an AI agent) to describe its own identity context when acting on behalf of a user. In the Agent Operation Authorization Request (i.e., the PAR-JWT), this claim represents a proposal of the agent-to-user binding and is not yet cryptographically endorsed by the Authorization Server (AS). The Authorization Server can determine whether a user is authorized to access a given agent by verifying the user's identity token (e.g., an ID Token) issued by a trusted Identity Provider. This requires that the token includes the agent's identifier in its aud (audience) claim, indicating that the token was intended for use with that agent. Since only users authorized by the Identity Provider receive tokens with the appropriate audience, validating the token and its audience suffices to establish legitimacy. The Authorization Server MUST validate this binding during request processing. Only upon successful validation—and after obtaining explicit user consent—does the AS issue an Agent Operation Authorization Token that includes the agent_identity claim as part of a trusted authorization assertion. At that point, the presence of agent_identity in the AS-issued token serves as an implicit attestation that the binding has been verified. The agent_operation_proposal field is a Rego policy string for OPA enforcement. The context field is a structured input format for OPA decision-making. The evidence field in the authorization token contains user confirmation records generated during the authorization phase. See Section 4 for the detailed format of this field. The agent_user_binding_proposal field format is as follows:

The user_identity_token MUST be a cryptographically verifiable identity credential (e.g., an OpenID Connect ID Token). The AS validates this token to establish the user's identity before issuing an authorization token. The agent_workload_token identifies the running agent workload. Unless otherwise specified, it SHOULD be a Workload Identity Token (WIT) as defined in . Deployments that already use other workload identity mechanisms (such as SPIFFE SVID) MAY map those tokens into this field, provided that the Authorization Server (AS) can validate them and bind the workload identity to the expected agent. agent_user_binding_proposal fields

Field	Type	Description	Requirement
user_identity_token	JWT string	A verifiable identity token for the end user, issued by a trusted Identity Provider.	MUST be an OpenID Connect ID Token or equivalent cryptographically signed token. The Authorization Server will validate this token to establish the user's identity.
agent_workload_token	JWT string	A verifiable workload identity token for the agent, typically a Workload Identity Token (WIT) as defined in I-D.ietf-wimse-workload-creds; deployments using SPIFFE MAY map SPIFFE SVIDs into this field.	MUST be a valid, signed workload identity credential. The Authorization Server will validate this token to establish the agent's identity and trustworthiness.
device_fingerprint	string	An optional unique identifier for the client device instance.	OPTIONAL. If provided, it SHOULD be a stable, privacy-preserving fingerprint (e.g., derived from hardware and app properties). Used by the AS to populate the `clientInstance` field in the resulting `agent_identity` claim.

agent_identity fields

Field	Type	Description	Requirement
version	string	Schema version	MUST be "1.0"
id	URI	Unique identifier	MUST be a UUID URI
issuer	URI	Issuer of identity	MUST be a valid URI
issuedTo	string	Target user identity	MUST be a cryptographically verifiable user identifier issued by a trusted Identity Provider, such as the sub claim from an ID Token.
issuedFor	object	Agent context	MUST contain platform:the logical platform or service namespace, client:The software client identifier (e.g., mobile app ID), clientInstance:A unique fingerprint of the client instance (e.g., device+app hash).
issuanceDate	timestamp	When identity was issued	MUST conform to ISO 8601
validFrom	timestamp	When identity becomes valid	MUST conform to ISO 8601
expires	timestamp	When identity expires	MUST conform to ISO 8601

The agent_operation_proposal field format is as follows:

The agent_operation_proposal field should be a valid Rego policy string. The context field format is as follows:

The Agent Client sends this PAR-JWT to the Authorization Server (AS) via the Pushed Authorization Request (PAR) mechanism, as defined in (OAuth 2.0 Pushed Authorization Requests).

Upon successful user authorization and authentication, the Authorization Server (AS) issues a Verifiable Agent Operation Credential in the form of a JWT token. The purpose of this credential is to serve as a digitally signed and independently verifiable "authorization letter", which enables the Personal Agent to perform authorized operations on behalf of the user. The issuer of the credential is the Authorization Server (AS) (indicated by the iss claim), and the intended audience is the Resource Server (indicated by the aud claim) that will verify and honor this authorization. The credential becomes effective immediately after the user clicks "Allow" or "Consent".

The evidence field in the authorization token contains user confirmation records generated during the authorization phase. The evidence field format in the authorization token is as follows:

The evidence field MAY alternatively use a W3C Verifiable Credential format for compatibility with existing credential infrastructures. When using W3C VC format, the credential MUST contain user confirmation evidence and be signed by the Authorization Server. Alternative W3C Verifiable Credential format for evidence:

The agent_identity claim is issued by the Authorization Server (AS) after successfully validating a user identity token and confirming the agent's workload identity. It contains an authoritative representation of the binding between the agent and the user, along with contextual information necessary for authorization decisions.

agent_identity fields in the authorization token

Field	Type	Description	Requirement
version	string	Schema version	MUST be "1.0"
id	URI	Unique identifier for this binding instance	MUST be a UUID-based URI
issuer	URI	Issuer of the `agent_identity` claim	MUST be the URI of the Authorization Server
issuedTo	string	Verified user identifier on whose behalf the agent acts	MUST be a globally unique, cryptographically verifiable identifier derived from a validated identity token (e.g., the `sub` claim, optionally prefixed with the issuer URI such as `https://idp.example.com\|user-12345`). It MUST NOT be a plain username or unverified string.
issuedFor	object	Context identifying the agent	MUST contain: platform: Logical service namespace; client: Software client identifier (e.g., mobile app ID); clientInstance: Unique fingerprint of the client instance (e.g., device+app hash).
issuanceDate	timestamp	Time when the binding was issued	MUST conform to ISO 8601 UTC
validFrom	timestamp	Time when the binding becomes effective	MUST conform to ISO 8601 UTC
expires	timestamp	Time when the binding expires	MUST conform to ISO 8601 UTC

The agent_identity claim is signed by the AS to ensure its authenticity and integrity. The AS SHALL validate all inputs before issuing this claim, ensuring that the identities of both the user and the agent are verified. The policy_id field is a string that serves as an OPA policy reference and MUST match a registered policy in the AS

auditTrail establishes a complete, semantically traceable chain—from the user's original intent to the system's final executed action—in AI Agent scenarios. This mechanism is known as a Semantic Audit Trail. The specific purposes and their descriptions are outlined in the following table:

Purposes and Descriptions of the Semantic Audit Trail

Purpose	Description
1. Intent Provenance	Records what the user originally said (e.g., "Add something cheap to cart on Nov 11 night") to prevent disputes such as: "I didn't say I wanted to add anything to cart!"
2. Action Interpretation	Documents how the system interpreted and rendered the input into a concrete operation (e.g., "Add items under $50 to cart during the Nov 11 promotion (valid until 23:59)"), reflecting the AI's reasoning process.
3. Semantic Transparency	Shows whether semantic expansions or default values were applied (e.g., mapping "cheap" to $50, defining "night" as 00:00–06:00).
4. User Confirmation Evidence	Includes timestamps indicating when the user reviewed and confirmed the interpreted action, serving as proof of authorization.
5. Accountability Support	Enables post-hoc analysis in case of erroneous transactions: Was the issue due to ambiguous user input, system misinterpretation, or misleading UI guidance.

| | | | | | | (2) | | Parse & structure | | | | operation proposal | | | | | | (3) | | Build operation | | | | proposal JWT | | | | | | (4) | | Create and sign | | | | JWT with JWS | | | | | | (5) | | POST /par with JWT | | | |------------------->| | | | | | (6) | | | Validate JWT | | | | | | | | | | | | | (7) | | Return request_uri | | | |<-------------------| | | | | | (8) | | 302 Redirect | | |<------------------| | | | /authorize?client_id=..request_uri=... | | |--------------------------------------->| | | | | | (9) | | | Consent UI | |<---------------------------------------| | | | | | (10) | User approves | | | |--------------------------------------->| | | | | | (11) | | | Register policy | | | | Issue access token | | | | | (12) | | Return access token| | | |<-------------------| | | | | | (13) | | Present access token | | |---------------------------------------->| | | | | (14) | | | | Verify token | | | | Enforce policy | | | | (15) | | | | Execute or deny | | | Response | |<------------------------------------------------------------| ]]>

builds operation proposal object | v (3) Agent creates operation proposal JWT | v (4) Agent creates JWT with operation proposal claim, signs with JWS | v (5) Agent sends JWT to AS via PAR: POST /par { "request": "" } | v (6) AS validates JWS, extracts proposal and validates | v (7) AS returns request_uri to Agent | v (8) Agent redirects User to AS: /authorize?request_uri=... | v (9) AS displays consent UI to User | v (10) User reviews displayed operation and approves | v (11) AS registers policy and issues Agent Operation Authorization Token | v (12) AS returns access token to Agent | v (13) Agent presents access token to Resource Server | v (14) RS verifies token and enforces OPA policy | v (15) Action executed or denied, response returned to User ]]>

In multi-agent systems, a primary agent (Agent A) may delegate a subset of its authorized operations to a secondary agent (Agent B). This specification supports such delegation while preserving:

End-to-end auditability back to the original human principal;
No privilege escalation beyond the original authorization scope;
Explicit AS validation at every delegation hop.

To support secure agent-to-agent delegation, the Agent Operation Authorization Token MAY include a delegation_chain claim. This claim is an ordered list (from most recent to original) of cryptographically verifiable delegation events, enabling resource servers to validate that the current agent's authority is derived—without escalation—from an original human-confirmed authorization. The delegation_chain is an array of delegation records, ordered from most recent to earliest. Each record MUST be cryptographically bound to the issuing Authorization Server during token issuance.

Each entry in the delegation_chain is signed by the Authorization Server at issuance time, ensuring its integrity and non-repudiation. The chain is extended—not copied—by the AS during each delegation step. The following subsections describe how agents initiate delegation and how the AS validates and extends this chain. The delegation_chain contains the following fields: delegation_chain Fields

Field	Type	Description	Requirement
delegator_jti	string (URI)	The JTI (JWT ID) of the delegator's authorization token, serving as a reference to the prior authorization in the delegation chain.	REQUIRED. MUST be a valid JWT ID that can be resolved by the AS.
delegator_agent_identity	object	The agent_identity claim from the delegator's token, identifying the delegating agent.	REQUIRED. MUST match the agent_identity structure defined in this specification.
delegation_timestamp	timestamp	The time when this delegation was authorized by the AS.	REQUIRED. MUST conform to ISO 8601 UTC format.
operation_summary	string	A human-readable description of the delegated operation for audit and logging purposes.	OPTIONAL. Useful for post-hoc analysis and compliance reporting.
as_signature	string (JWT)	Cryptographic signature from the AS over this delegation record, ensuring integrity and non-repudiation.	REQUIRED. MUST be verifiable using the AS's public key.

When initiating delegation, Agent A submits a Pushed Authorization Request (PAR) to the AS containing:

Its current Agent Operation Authorization Token (or a reference via jti if tokens are stored server-side);
A new agent_user_binding_proposal for Agent B (note: user remains the original human principal);
A requested_sub_operation descriptor (e.g., policy template ID or scope hash).

Importantly, Agent A does not submit raw credentials like sourcePromptCredential. The AS validates the user confirmation evidence and authorization scope using the provided token reference.

The AS MUST perform the following checks:

Validate that the submitted token (or jti) is valid and issued by this AS.
Confirm that the original token permits delegation (e.g., contains "delegation_allowed": true).
Verify that the requested sub-operation is strictly narrower in scope than the original authorization. This may be implemented via:
1. Pre-registered policy templates with hierarchical relationships;
2. Runtime evaluation using a policy engine (e.g., OPA) if enabled;
3. Scope string containment (for simple cases).
Authenticate Agent B’s identity via its agent_workload_token in the new binding proposal.

If all checks pass, the AS issues a new Agent Operation Authorization Token for Agent B. The new token:

References the same original human intent (via internal linkage, not token exposure);
Includes a new agent_identity for Agent B;
Extends the delegation_chain with a new, AS-signed record referencing Agent A's token (jti).

The resulting token for Agent B contains:

A fresh agent_identity identifying Agent B;
An updated delegation_chain with one additional entry;
No exposure of the original user’s ID Token or Agent A’s private credentials (while the issuedTo field allows maintaining the link to the human principal).

Resource Servers can validate the entire chain by:

Verifying the AS signature on each delegation_chain entry;
Confirming that the final agent_identity.issuedTo matches the original human principal;
Ensuring no operation exceeds the cumulative scope of the chain.

The JWS signature provides integrity protection for the authorization token, while the evidence field contains user confirmation records generated during the authorization phase. Authorization Servers MUST validate the user confirmation evidence and session context before issuing authorization tokens. The Authorization Server MUST generate a cryptographic signature over the user_confirmation_record to ensure its integrity and non-repudiation. This signature provides authoritative attestation that the user confirmed the displayed content at the specified timestamp. When using W3C Verifiable Credential format for evidence, Authorization Servers MUST validate the credential's signature and verify that it contains appropriate user confirmation evidence as described in this specification. Public keys referenced by issuerKey MUST be obtained through secure, trusted mechanisms (e.g., pre-registration, PKI). Expression evaluation (e.g., CEL) MUST occur in sandboxed environments. The use of PAR prevents leakage of sensitive operation data in URLs. This specification assumes a threat model in which the agent implementation (including its evidence construction and signing logic) is part of the trusted computing base, while the large language model (LLM) used to derive operation proposals is not. The mechanisms defined here are primarily intended to make the transformation from the user's original intent to the final authorized operation transparent and auditable, and to avoid granting the LLM direct control over authorization decisions. During the authorization phase, the Authorization Server (AS) acts as the witness of the user's consent: it presents the rendered operation to the user on an AS-controlled interface and, upon explicit approval, issues the Agent Operation Authorization Token embedding user confirmation evidence. This evidence includes the displayed content, user action, and confirmation timestamp, all covered by the AS's signature on the token for audit and verification purposes. Deployments MAY define whitelists or policy profiles that limit which classes of operations an agent can be authorized to perform for a user, especially for highly sensitive resources. This can help reduce the risk of over-broad delegation. For Agent-to-Agent delegation, the Authorization Server acts as the central policy enforcer and trust anchor. It MUST NOT issue delegation tokens unless it can cryptographically verify the user confirmation evidence and confirm that the proposed sub-operation is within the bounds of the original authorization. The delegation_chain MUST be constructed and signed by the AS (and not self-reported by agents) in order to prevent forgery.

This document requests IANA to register the following two claims in the "JSON Web Token Claims" registry, following the procedure defined in RFC 8126.

Claim Name:: agent_identity
Claim Description:: A structured claim that conveys the identity and issuance metadata of an autonomous agent acting on behalf of a user. It includes a unique identifier, issuer, target user, deployment context, and validity timestamps, enabling secure binding of agent operations to a verified identity.
Change Controller:: IETF
Specification Document:: This document requests registration of the agent_identity claim in the IANA "JSON Web Token Claims" registry .

Claim Name:: agent_operation_proposal
Claim Description:: A Rego policy string proposed by an agent for authorization evaluation. This claim is used in the initial authorization request to convey a policy that, upon validation and registration by the Authorization Server, will be referenced via a policy_id in subsequent access tokens.
Change Controller:: IETF
Specification Document:: This document, Section X.Y ("Agent Operation Proposal")

Claim Name:: agent_operation_authorization
Claim Description:: A structured claim that conveys authorization metadata for agent-performed operations, including a reference to a registered policy via the policy_id field. This claim is included in access tokens issued after successful policy validation and registration by the Authorization Server.
Change Controller:: IETF
Specification Document:: This document, Section X.Z ("Agent Operation Authorization")

Claim Name:: context
Claim Description:: A structured claim providing contextual information for policy evaluation, including user and agent identity attributes, device characteristics, channel, and locale. This claim serves as the input data for Open Policy Agent (OPA) enforcement decisions.
Change Controller:: IETF
Specification Document:: This document, Section X.Z ("context")

Claim Name:: delegation_chain
Claim Description:: An optional array of AS-signed delegation records tracing agent-to-agent authorizations. Each record includes: delegator_jti (reference to prior token), delegator_agent_identity (delegating agent's identity), delegation_timestamp, operation_summary (optional human-readable description), and as_signature (AS cryptographic signature ensuring integrity). Enables end-to-end validation of delegation lineage without exposing raw credentials.
Change Controller:: IETF
Specification Document:: This document, Section .

While not required for interoperability, implementers may find it useful to validate claim structures using JSON Schema. Informative schemas for the claims defined in this document may be developed and published separately. Such schemas are not normative and do not require IANA registration.