Agent Operation Authorization

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 31 August 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

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.¶

2. Requirements Language

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].¶

3. agent_operation_proposal Token Structure

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:¶

                {
                    "iss": "https://client.myassistant.example",
                    "sub": "user_12345@myassistant.example",
                    "aud": "https://as.online-shop.example",
                    "exp": "2025-11-11T23:59:00Z",
                    "iat": "2025-11-11T10:30:00Z",
                    "agent_user_binding_proposal": { ... },
                    "agent_operation_proposal": "package agent\nallow { input.transaction.amount <= 50.0 }",
                    "context": { ... }
                }

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:¶

    {
      "agent_user_binding_proposal": {
        "user_identity_token": "eyJhbGciOiJSUzI1NiIs...",
        "agent_workload_token": "eyJhbGciOiJFUzI1NiIs...",
        "device_fingerprint": "dfp_abc123"
      }
    }

The user_identity_token MUST be a cryptographically verifiable identity credential (e.g., an OpenID Connect ID Token). The AS will validate 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 [I-D.ietf-wimse-workload-creds]. 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.¶

The agent_operation_proposal field format is as follows:¶

            {
            "agent_operation_proposal": "package agent\nallow { input.transaction.amount <= 50.0 }"
            }

The agent_operation_proposal field should be a valid Rego policy string.¶

The context field format is as follows:¶

            {
            "context": {
                "channel": "mobile-app",
                "deviceFingerprint": "dfp_abc123",
                "language": "zh-CN",
                "user": {
                "id": "user_12345@myassistant.example"
                },
                "agent": {
                "instance": "dfp_abc123",
                "platform": "personal-agent.myassistant.example",
                "client": "mobile-app-v1.myassistant.example"
                }
            }
            }

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

4. Agent Operation Authorization Token

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".¶

{
  "iss": "https://as.online-shop.example",
  "sub": "user_12345@myassistant.example",
  "aud": "https://api.online-shop.example",
  "exp": "2025-11-11T23:59:00Z",
  "iat": "2025-11-11T10:35:00Z",

  // ====== Evidence of User Confirmation ======
  "evidence": {
    "id": "evidence-confirmation-abc123",
    "user_confirmation_record": {
      "displayed_content": "Add items under $50 to cart during the Nov 11 promotion (valid until 23:59)",
      "user_action": "confirmed_via_button_click",
      "timestamp": "2025-11-11T10:33:15Z",
      "session_context": {
        "oauth_session_id": "session_abc123",
        "device_fingerprint": "dfp_xyz789"
      }
    },
    "as_signature": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...signature_over_confirmation_record"
  },

  // ====== Agent Identity ======
  "agent_identity": { ... },

  // ====== Agent Operation Authorization ======
  "agent_operation_authorization": {
    "policy_id": "opa-policy-789"
  },


  // ====== auditTrail ======
  "auditTrail": {
      "evidence_reference": "evidence-confirmation-abc123",  // References the evidence object by ID
      "semanticExpansionLevel": "medium",
      "userAcknowledgeTimestamp": "2025-11-11T10:33:00Z",
      "consentInterfaceVersion": "consent-ui-v2.1"
  },

  // ====== Optional: Reference to Proposal ======
  "references": {
    "relatedProposalId": "urn:uuid:op-proposal-456"
  }
}

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:¶

{
  "evidence": {
    "user_confirmation_record": {
      "displayed_content": "string",
      "user_action": "string",
      "timestamp": "ISO8601_timestamp",
      "session_context": {
        "oauth_session_id": "string",
        "device_fingerprint": "string"
      }
    },
    "as_signature": "signature_over_user_confirmation_record_by_AS"
  }
}

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:¶

{
  "evidence": {
    "type": "VerifiableCredential",
    "credentialSubject": {
      "type": "UserConfirmationEvidence",
      "userAction": "confirmed_via_ui_interaction",
      "displayedContent": "Add items under $50 to cart during Nov 11 promotion",
      "confirmationTimestamp": "2025-11-11T10:33:15Z",
      "sessionId": "session_abc123"
    },
    "issuer": "https://as.example.com",
    "issuanceDate": "2025-11-11T10:33:15Z",
    "@context": ["https://www.w3.org/2018/credentials/v1"]
  }
}

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": {
          "version": "1.0",
          "id": "urn:uuid:agent-identity-789",
          "issuer": "https://as.example.com",
          "issuedTo": "https://idp.example.com|user-12345",
          "issuedFor": {
            "platform": "personal-agent.myassistant.example",
            "client": "mobile-app-v1.myassistant.example",
            "clientInstance": "dfp_abc123"
          },
          "issuanceDate": "2025-11-11T10:35:30Z",
          "validFrom": "2025-11-11T10:35:30Z",
          "expires": "2025-11-11T23:59:00Z"
        }
      }

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:¶

5. Workflow

+--------+       +----------------+       +--------+       +------------------+
|  User  |       |   AI Agent     |       |  AS    |       | Resource Server  |
+--------+       +----------------+       +--------+       +------------------+
     |                   |                    |                    |
(1)  |      prompt       |                    |                    |
     |------------------>|                    |                    |
     |                   |                    |                    |
(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       |
     |                   |                    | Extract evidence   |
     |                   |                    | field and validate |
     |                   |                    |                    |
(7)  |                   |                    | Return request_uri |
     |                   |                    |<-------------------|
     |                   |                    |                    |
(8)  |                   | Redirect user to   |                    |
     |                   | /authorize?request_uri=...              |
     |                   |---------------------------------------->|
     |                   |                    |                    |
(9)  | Approve           |                    |                    |
     |<------------------------------------------------------------|
     |                   |                    |                    |
(10) |                   |                    | Validate JWT       |
     |                   |                    | Extract operation  |
     |                   |                    | Issue access token |
     |                   |                    |<-------------------|
     |                   |                    |                    |
(11) |                   | Present access     |                    |
     |                   | token ------------>| Resource API       |
     |                   |                    |------------------->|
(12) |                   |                    | Verify user        |
     |                   |                    | confirmation       |
     |                   |                    | evidence           |
     |                   |                    |------------------->|
(13) |                   |                    | Enforce OPA        |
     |                   |                    | policy             |
     |                   |                    | Execute or deny    |
     |                   |                    |<-------------------|
     |                   |                    | Response           |
     |<------------------------------------------------------------|
(14) |                   |                    | Action executed    |
     |                   |                    | or denied          |

(1) User says: "Add something cheap to cart on Nov 11 night"
     |
     v
(2) AI Agent parses intent → 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": "<jwt>" }
     |
     v
(6) AS validates JWS, extracts evidence field and validate
     |
     v
(7) AS issues request_uri to agent
     |
     v
(8) Agent redirects user to /authorize?request_uri=...
     |
     v
(9) User reviews the displayed operation and confirms the authorization
     |
     v

(10) AS register the policy and issues Agent Operation Authorization Token as access token which includes the policy_id
     |
     v
(11) Agent uses token to access Resource Server
     |
     v
(12) AS verifies user confirmation evidence
     |
     v
(13) RS enforces OPA policy
     |
     v
(14) Action executed or denied

6. Agent-to-Agent Delegation

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.¶

    "delegation_chain": [
    {
      "delegator_jti": "urn:uuid:token-abc-123",
      "delegator_agent_identity": { /* agent_identity of Agent A */ },
      "delegation_timestamp": "2025-12-18T10:15:00Z",
      "operation_summary": "Delegate inventory check for item X",
      "as_signature": "eyJhbGciOiJSUzI1NiIs..."
    }
  ]

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:¶

7. Security Considerations

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.¶

8. IANA Considerations

Authors' Addresses