]> China Mobile

BeiJing China chenmeiling@chinamobile.com

China Mobile

BeiJing China chenjia@chinamobile.com

CNNIC

BeiJing China yaojk@cnnic.cn

jiangyuning2@h-partners.com

Huawei

liuchunchi@huawei.com

lx19950218@gmail.com

Security OAuth Working Group OAuth Agent AI Artificial Intelligence Authorization Delegation Revocation Gap Analysis This document provides a systematic analysis of these emerging agent-based use cases. It categorizes them into distinct scenarios, details their specific authorization requirements, and performs a comprehensive gap analysis against the existing OAuth 2.0 framework and its common extensions. The analysis identifies fundamental gaps and requirements, providing a foundation for future work on new extensions within the OAuth Working Group toward creating a more secure and interoperable ecosystem for agent-based systems.

Introduction The OAuth 2.0 Authorization Framework has become the factual standard for delegated authorization on the internet. Its success is rooted in a well-defined model where a resource owner grants a third-party client limited access to their resources without sharing their credentials. This model primarily assumes a user-present, interactive flow where a static set of permissions (scopes) is approved upfront. However, the landscape is rapidly evolving with the advent of sophisticated AI-driven "Agents". These are not simple clients but autonomous or semi-autonomous entities that perform complex, multi-step tasks on behalf of a user or another system. Their operational characteristics include:

• Delegated Autonomy: Agents act with authority delegated from a principal (user or system) over extended periods.
• Complex Task Decomposition: An agent might take a high-level instruction (e.g., "plan my business trip") and decompose it into numerous discrete actions involving multiple resource servers.
• Asynchronous & Long-Running Operations: Tasks may run for hours, days, or indefinitely, often without direct, real-time supervision from the principal.
• Dynamic & Emergent Needs: The exact permissions required may not be known at the start of a task but emerge as the agent plans and executes its steps.
• Composition & Chaining: Agents may delegate sub-tasks to other agents, forming a chain of authority.
• Cross-Domain: Chained or composited task orchestration often require calling of resources in different administrative domains.

This document does not propose new solutions or protocols. Instead, its purpose is to: * **Define the key actors and concepts in agent-based authorization scenarios. * **Describe a set of core use cases that exemplify the new challenges. * **Conduct requirement and gap analysis for each use case, identifying where the current OAuth 2.0 framework and its extensions fall short. * **Summarize the key security considerations. By clearly articulating these gaps, this document aims to provide a shared understanding of the problem space and stimulate focused work on developing interoperable solutions for the next generation of delegated authorization.

Terminology In addition to the terms defined in , this document uses the following terms:

User (Resource Owner):

An entity capable of granting access to a protected resource. In the context of this document, the user is the person who delegates authority to an agent. Conforms to the definition of "Resource Owner" in .

Authorization Server (AS):

The server that authenticates the User and issues access tokens to the Agent after obtaining the User's authorization. Conforms to the definition in .

Resource Server (RS):

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. Conforms to the definition in .

Data Subject:

A natural person whom accessed data describes, and who is neither the Resource Owner nor a party to the authorization exchange.

Delegation Chain:

A sequence of delegation events, where one actor grants a subset of its authority to another, for example: User -> Agent A -> Agent B.

Intent:

A high-level description of a goal or task that the user wants the agent to accomplish (e.g., "book me a flight to Hawaii for next week").

Tool:

A specific API or function that an agent can call to perform an action (e.g., a search_flights API, a send_email function).

Grant Layer Authority:

The set of permissions established at the time of authorization, typically represented by scopes in an access token. It defines what an agent is allowed to do in principle (e.g., "The agent has the authority to book parks"). This authority is the primary focus of the core OAuth 2.0 framework and its extensions like RAR.

Execution Layer Evidence:

A verifiable, non-repudiable record, generated at the moment a specific, critical action is taken. It serves as cryptographic proof of a principal's explicit consent to the concrete parameters of that single action (e.g., "The user explicitly approved booking 'Sunnyvale Park' for $25 on this specific date"). This evidence proves what was done and under whose direct approval at runtime, not just what was allowed to be done.

A Visual overview of Core Authorization Gaps Before diving into the specific use cases, it is crucial to understand the three fundamental and recurring challenges that emerge when applying the current OAuth 2.0 framework to agent-based systems. These challenges, or "gaps," are not unique to any single use case but are common threads that run through nearly all of them. Visualizing these gaps helps to clarify the problems this document aims to address. For detailed gaps of each use case, please refer to the section of Use Cases and Gap Analysis.

The Authorization Context Gap The Problem: There is a disconnect between the user's high-level intention given to an agent at one point in time, and the specific, low-level permission request made by that agent at a later time. The Authorization Server (AS) and the user, when asked for consent, lack the necessary context to securely evaluate the request. Imagine a user asks their AI assistant to plan a trip. Days later, the assistant needs to book a flight. | | Time T1: User provides high-level intent. | (Context: Paris) | | . . . . (Hours/Days Later) . . . . . | |---1. Request Token-->| Time T2: Agent needs to perform a specific action. | | (scope=booking_api) | | | | | |<--2. Redirect for----| | User Consent | | | |<--3. AS shows Consent Prompt--------------| | +------------------------------------+ | | | "Allow 'AI Assistant' to | | | | access your Booking Service?" | | | +------------------------------------+ | | ^ | +-------|-----------------------------------+ | --[ THE CONTEXT GAP ]-- The user thinks: "Why now? Is this for my Paris trip, or something else?" The AS doesn't know the original intent ("Paris trip") to help the user decide. ]]> Explanation of the Gap: At Time T2, the consent prompt shown to the user is generic. It lacks the critical context from Time T1 (i.e., that this booking is for the "Paris trip"). The user is forced to either deny a legitimate request due to uncertainty or approve it blindly, creating a security risk. The AS has no standard mechanism to receive and validate this "intent" context from the initial interaction.

The Delegation Chain Gap The Problem: When a task is delegated through a series of agents (A → B → C), there is no standard, cryptographically verifiable way for the final Resource Server (RS) to confirm that the entire delegation chain is legitimate and authorized by the original user. A user's Travel Agent (A) delegates flight booking to a specialized Flight Booker (B), which in turn uses a Payment Processor (C) to complete the transaction. Agent A -----> Agent B -----> Agent C -----> Resource Server (Travel) (Flights) (Payment) (Bank API) THE IDEAL (but currently missing standard): A cryptographically verifiable chain of authority. [Token for A] -> delegates to -> [Token for B] -> delegates to -> [Token for C] THE REALITY (The Gap): Agent C presents its token. | v Resource Server +-------------+ | Sees Token C| | Validates C | +-------------+ ^ | --[ THE DELEGATION CHAIN GAP ]-- The RS has no standard way to know that C is acting on behalf of B, which is acting on behalf of A, under the authority of the original User. ]]> Explanation of the Gap: The Resource Server (the Bank API) can only validate that the token from Agent C is valid for Agent C. It cannot "look back" up the chain to verify that this request originated from a legitimate delegation path starting with the user's authorization to Agent A. This prevents end-to-end security, makes auditing impossible, and complicates the enforcement of progressively narrower permissions down the chain.

The Mass Revocation Gap The Problem: When a security event occurs (e.g., a user's account is compromised, an agent is found to be malicious), there is no standard, efficient mechanism to instantly revoke all authorizations and tokens associated with a specific entity (like a user or a client). The existing one-by-one revocation process is too slow. A user's account is compromised. This user had previously granted access to multiple agents, which now hold active tokens. During this slow, sequential process, malicious actors can still use Tokens B through Z to access resources. ]]> Explanation of the Gap: The time it takes to iterate through and revoke each token individually creates a dangerous "vulnerability window." Attackers can continue to exploit the still-valid tokens until the revocation process is complete. What is needed is a standardized, atomic "kill switch" to terminate all related sessions and grants instantly in response to a single event.

Use Cases and Gap Analysis This section explores three categories of use cases, providing a concrete example for each, and analyzes the gaps in the existing OAuth 2.x framework. For each use case, we examine what can be achieved with existing tools and, more importantly, what is missing.

Category 1: Personal & Consumer Scenarios

Authorization Requirement Summary The personal and consumer use cases share several recurring authorization requirements that challenge the traditional, static, and upfront nature of OAuth 2.0 grants. These requirements focus on providing user-centric context, control, and lifecycle management for agent-delegated authority.

Requirement Theme	Use Cases and Forms
Dynamic & Contextual Authorization	UC1: Authorization with task context; UC3: Conditional authority (based on event or time); UC5: Just-in-time permission requests; UC7: Acting on a challenge.
Granular & Constrained Authority	UC1, UC4: User-defined constraints (e.g., spending limits);UC2: Pre-approved, multi-faceted constraints (spending limits, action types, app scope) and immutable grant boundaries; UC3, UC5: Fine-grained permissions (for devices, files); UC4: Agent-specific policies (e.g., rate limits); UC6: User-defined scopes for headless services.
Differentiated Actor Identity	UC4: Distinguishing human vs agent, between different agent classes.
Task-Oriented Lifecycle Management	UC1, UC4: Task-bound revocation; UC2: Grant-level lifecycle (auto-expiry, single-action revocation) and amortized authorization; UC3: Bulk client revocation; UC6: Headless bootstrapping of credentials; UC7: Terminal disposition signaling.
Verifiable, Action-Specific Consent	UC1: Approval of final action parameters at execution time; UC2: Attributable actions linked to a specific grant; UC7: Separation of grant-layer authority from execution-layer evidence.

The summary includes only authorization requirements that recur across multiple use cases. Use-case-specific requirements or gaps remain with the individual scenarios, such as the architectural mismatch with local OS permissions in UC5, the need for independent per-class consent in UC4, and the lack of presence signaling and visible destination routing in UC7.

Use Case 1: Personal Digital Assistant

• Scenario Description: A user gives a high-level, natural language command to their AI assistant. The assistant can decompose this command into multiple steps and interact with various services to fulfill the request.
• Example: On Monday morning, Alice tells her AI assistant, "Help me plan a picnic for this Saturday." The assistant begins its work autonomously:
  1. It first checks Alice's calendar for availability (requires calendar.read).
  2. It then checks the weather forecast for Saturday (requires weather.read).
  3. Seeing the weather is good, it spends some time researching nearby parks based on Alice's past preferences (requires maps.searchand profile access).
  4. On Tuesday afternoon, after identifying the perfect spot, the assistant determines it needs final authorization to book the picnic spot (requires parks.book) and add the event to Alice's calendar (requires calendar.write).
  5. The assistant now presents an authorization request to Alice.
• Challenge: Context Collapse and the Erosion of Informed Consent. This scenario highlights a fundamental challenge to the traditional OAuth 2.0 model, which stems from the temporal decoupling of task initiation and authorization.
  • Context Collapse: The authorization request Alice receives on Tuesday afternoon is a simple prompt listing scopes like parks.book and calendar.write. The original context—the "picnic planning" instruction from the previous day—is lost. To Alice, the request is at best confusing ("Why does this app want to book a park now?") and at worst, indistinguishable from a sophisticated phishing attack. The traditional OAuth consent screen, designed for immediate, in-context requests, fails to provide the necessary assurance for the user to make a safe and informed decision.
  • Inadequacy of Binary Choices: Alice's only options are "Grant" or "Deny." However, her real question might be, "Which park did you choose?" or "Is there a fee?" The current framework provides no mechanism for this crucial dialogue. Denying the request causes the agent's task to fail, while granting it feels like signing a blank check.
  • Task-Level Revocation: Alice should be able to say, "Cancel the picnic planning," and have all permissions and pending actions related to this specific task instantly revoked, without affecting other tasks the agent might be performing.
  • Silent Execution Within a Valid Grant: where an action falls inside an existing grant, no fresh approval is triggered at all. A high-impact or irreversible action can therefore execute with valid authority and without any human having approved that specific action. The failure is not a bad consent screen, it is the absence of one.
• Authorization Requirements:
  • Authorization Context: The authorization request should carry sufficient task and action context for the user to understand why the requested authority is needed.
  • Task-Scoped Revocation: The user should be able to revoke authority associated with a specific task without affecting unrelated tasks performed by the same agent.
  • Pre-Authorized Constraints: Structured constraints previously approved by the user should remain associated with subsequent actions so that compliance can be checked at execution time.
  • Admission-to-Execution Binding: When execution relies on an earlier admission based on originator authorization, applicable policy, or prior consent, the execution endpoint should be able to verify the admission basis and the scope and constraints attached to it.
  • Action-Specific Approval: When fresh user approval is required for a high-impact or irreversible action, the approval should be bound to the concrete action parameters and verified before the action takes effect.
• Gap Analysis: This use case does not imply that OAuth itself should be responsible for parsing user intent (the agent's job) or orchestrating the task (the agent framework's job). Instead, it reveals a critical gap in the authorization experience when interacting with autonomous systems.
  • What Works (Partially): The OAuth Authorization Code flow can be used to get initial permissions, provided the client chooses to initiate it upon receiving a challenge. Refresh Tokens can maintain the agent's session.
  • What's Missing (The Gap):
    • No Standard for Authorization Context: The core gap is the lack of a standardized mechanism to carry the justification for the request from the agent to the user via the Authorization Server. OAuth's model, designed for immediate user-initiated flows, implicitly relies on the user's short-term memory to provide context. This assumption breaks down in agentic workflows. There is no standard way for the agent to pass a cryptographically verifiable "context object" (e.g., "This is for the picnic you requested on Monday") that the AS can present to the user.
    • No Standardized Interactive Consent Flow: There is no standard OAuth mechanism for an Authorization Server to facilitate a "clarification dialogue." The AS acts as a simple gatekeeper with a static grant/deny choice. It cannot "pause" the flow to allow the user to query the agent for more details (e.g., "Show me the park details") before consenting to the parks.book scope. This logic is currently left to complex, proprietary application-layer implementations.
    • Impractical Task-Level Revocation: OAuth Token Revocation () revokes a single token. To achieve task-level revocation, the application would need to build and maintain a complex, non-standard mapping of tasks to all associated tokens. There is no standard way to issue a single command like "revoke all tokens and authority related to 'picnic-task-123'."
    • No Standard Binding of Pre-Authorized Constraints to Execution: When the user has previously approved structured constraints on an action, existing grant-layer mechanisms do not provide a common way to bind those constraints to the concrete action performed later and verify that relationship at execution time. states this T0-to-T1 constraint-binding problem and defines requirements without proposing a mechanism.
    • No Standard Admission-to-Execution Binding: When a request is admitted based on originator authorization, applicable policy, or prior consent rather than a fresh user decision, existing mechanisms do not define how the execution endpoint verifies that admission basis or ensures that the concrete action remains within the admitted scope and constraints.
    • No Standard for Execution-Layer Evidence: At the moment of financial commitment (the final "Book" step), a simple access token representing Grant-Layer Authority (e.g., a parks.book scope) is insufficient. The core requirement is for Execution-Layer Evidence: a non-repudiable, cryptographic proof that binds the user's explicit, real-time consent to the specific parameters of the transaction (e.g., "Book picnic spot at 'Sunnyvale Park', cost $25"). This evidence serves as proof of the human's decision at the moment of execution, proving what the user agreed to, not just that the agent possessed the authority to book something. The existing framework lacks a standard for generating or verifying such evidence. Where such evidence is required, it must be verified before the high-impact or irreversible effect is committed.

Use Case 2: Daily Small-Amount Orders

• Scenario Description: This use case addresses the user's need to delegate routine, low-risk tasks without being interrupted for approval on every single action. The user grants their AI assistant a pre-approved, constrained autonomy for a defined period. This "amortized consent" model allows the agent to operate independently within clear, enforceable boundaries (e.g., budget, time, allowed actions), striking a balance between automation and user control.
• Example: On Monday morning, Dave tells his assistant, "Handle my daily errands." In a single interaction, he approves the day's grant: the assistant may read options, draft orders, and spend up to $30 per transaction and $100 total for the day—across food delivery, travel, and household services. The grant is set to expire automatically at midnight. Throughout the day, the assistant:
  1. Reads takeout options nearby and drafts a dinner order for the family (requires read, draft permissions).
  2. Places the dinner order for $24 (requires send, spend permissions—within the per-transaction and total caps).
  3. Attempts a $38 rideshare booking for Wednesday's trip. This exceeds the per-transaction cap, so the action is automatically held and surfaced to Dave for explicit approval of the exception.
  4. Orders household supplies for $18 (within all caps).
  5. At midnight, the grant expires automatically. Dave's card statement shows the charges; when asked later, the assistant can recount what the day's grant permitted and why each action was taken.
• Authorization Requirements:
  • Structured, Multi-faceted Constraints: The grant must support clear, machine-enforceable boundaries that go beyond simple scopes. This includes per-transaction and cumulative spending limits, allowed application targets (e.g., only food-delivery-app), and tiered action classes (e.g., read < draft < send < spend).
  • Single Upfront Authorization (Amortized Consent): The user should perform a single, strong authentication to establish the grant for its entire lifetime, eliminating the need for per-action re-authentication as long as the agent operates within the defined bounds.
  • Immutable Grant Boundaries: The agent must not be able to widen or extend its own authority. Any change to the grant's boundaries requires a fresh, explicit authorization from the user.
  • Grant-Level Lifecycle Management: Every grant must have a mandatory, explicit expiration time. The user must also be able to revoke the entire grant and all associated authority with a single, immediate action.
  • Verifiable Action-to-Grant Linkage: Every action taken by the agent must be cryptographically attributable to the specific grant that authorized it, ensuring a clear audit trail.
• Gap Analysis:
  • What Works (Partially): The OAuth authorization code flow can establish the initial grant. Rich Authorization Requests can express structured authorization details. DPoP can bind tokens to the agent presenting them. Token revocation can kill individual tokens.
  • What's Missing (The Gap):
    • No standard for human-readable intent at grant time: Scopes are opaque strings; the user's actual instruction is not part of the authorization record, so context must be reconstructed later, or cannot be at all.
    • No standard consequence-tiered action model: Every design invents its own ladder, so "the agent may draft but not send" has no interoperable expression.
    • No amortized-authentication model: OAuth assumes interactive, per-session approval; there is no notion of one strong authentication covering a bounded grant lifetime.
    • No grant-level revocation: RFC 7009 revokes single tokens. There is no standard "end this grant and everything under it" — the mapping of task to tokens is proprietary.
    • No standard spend-cap semantics: Per-transaction and cumulative monetary bounds are proprietary to each implementation.
    • No standard binding of grant bounds to execution-time enforcement: A grant's stated limits have no interoperable path to the independent services that must enforce them.

Use Case 3: Smart Home & Automation

• Scenario Description: A central home hub agent manages various IoT devices based on pre-defined rules or real-time events.
• Example: Bob sets up a "Good Morning" routine. When his alarm goes off at 7 AM on a weekday, the home hub agent is authorized to:
  1. Slowly turn on the bedroom lights (device: bedroom_light, capability: brightness).
  2. Set the thermostat to 70°F (device: thermostat, capability: set_temperature).
  3. Start the coffee maker (device: coffee_maker, capability: on_off).
• Authorization Requirements:
  • Persistent Delegation: After a one-time setup, the agent should be able to perform these actions daily without Bob's intervention.
  • Fine-Grained Device & Capability Permissions: The agent should be authorized to control the brightness of the bedroom_light, but not, for example, to unlock the front_door.
  • Conditional or Event-Driven Authorization: The permissions should only be usable when specific conditions are met (e.g., time=7AM AND day=weekday).
  • Bulk Revocation: When Bob sells his house, he needs a simple way to revoke all permissions for all devices from his home hub with a single action.
• Gap Analysis:
  • What Works (Partially): Refresh Tokens are well-suited for persistent delegation. Scopes can be defined with high granularity (e.g., device:bedroom_light:brightness).
  • What's Missing (The Gap):
    • "Scope Explosion" and Usability: In a home with hundreds of devices and capabilities, presenting the user with a list of thousands of scopes to approve is unmanageable. The OAuth consent screen was not designed for this scale.
    • No Standardized Policy Enforcement: OAuth grants what an agent can do, but not when or under what conditions. The logic to enforce time=7AM is outside the protocol and should be custom-built into the agent or the device's resource server, leading to inconsistent and non-interoperable implementations.
    • No Standardized Bulk Revocation: is for revoking one token at a time. There is no standard API to "revoke all tokens for user Bob" or "revoke all tokens issued to the home hub client." This is a critical administrative and security gap, forcing reliance on proprietary AS-specific APIs.

Use Case 4: Agent as User's Full Proxy to Access Third-Party Tools

• Scenario Description: A user authorizes an agent to use a third-party service on their behalf. The service, however, was designed for human interaction and has no built-in awareness of automated agents, leading to potential misuse or policy violations.
• Example1: Charlie authorizes his personal research assistant agent to use his subscription to an academic paper database. The agent, acting as Charlie, begins downloading hundreds of papers for a literature review. The database service detects this high-frequency activity, flags it as a potential DDoS attack or data scraping, and temporarily locks Charlie's account, disrupting both the agent's task and Charlie's own access.
• Example2: The database service later adds its own built-in AI features: an AI summarizer that processes users' saved papers. Charlie now faces three distinct classes of caller against the same API surface: his own interactive sessions, the service's built-in AI, and his external research agent. He may be comfortable with the built-in summarizer processing his library but not an external agent, or the reverse. His consent decision for one class says nothing about the others.
• Authorization Requirements:
  • Agent-User Differentiation: The third-party service should be able to reliably distinguish between requests coming directly from Charlie and requests made by his agent.
  • Agent-Specific Policies: The service needs a way to apply different policies (e.g., stricter rate limits, restricted API access) to the agent without impacting the human user's normal access rights.
  • Delegated Authority with Constraints: The authorization given to the agent should be a constrained subset of the user's full permissions (e.g., "can search and download, but no more than 100 papers per hour").
  • Caller-Class Differentiation: Beyond distinguishing the agent from its user, the service should be able to distinguish among classes of caller (at minimum the interactive human session, the application's own platform-native AI, and external user-delegated agents) in a way the caller cannot self-select.
  • Independent Per-Class Consent: The user should be able to grant or deny consent for each caller class independently, with no inheritance between classes, consent for one class must not imply consent for any other.
  • An Attachment Point for Internal-AI Consent: The application's own AI features typically never traverse the authorization layer at all, so there is currently nothing to attach a consent decision to for that class.
• Gap Analysis:
  • What Works (partially): OAuth allows a user to delegate access to a client (the agent). The scope parameter can limit which APIs the agent can call.
  • What's Missing (The Gap):
    • Lack of Reliable Caller-Class Differentiation: There is no standard mechanism for a resource server to reliably distinguish between different classes of callers, such as a human user's interactive session, a platform's internal AI feature, and an external, user-delegated agent. This forces services to rely on unreliable heuristics (e.g., traffic patterns, User-Agent strings) to apply class-specific policies like rate limits or to detect abuse. Furthermore, because the caller class cannot be determined from a trustworthy signal that the caller cannot self-select, users cannot grant or deny consent on a per-class basis (e.g., "allow my external agent but not the platform's internal AI").
    • Confused Deputy Vulnerability: Even with clear caller identification, an agent with legitimate authority can be tricked (e.g., through prompt injection or cross-request data contamination) into misusing its authority for an unauthorized purpose or principal. Caller identification does not solve this, as the agent's identity and credentials are valid. The gap is the lack of a standard mechanism to bind the delegated authority to the specific, originating principal or task context and to verify this binding at the resource server before an action is performed. While RFC 8693 can represent the actor chain, it does not provide a standard way to ensure the initiating context is invariantly bound to the final action.
    • Inability to Express Granular Constraints: The standard scope mechanism is binary (permission is granted or not). It cannot express or enforce nuanced constraints like rate limits, data volume caps, or time-of-day restrictions as part of the authorization grant itself.

Use Case 5: Agent as User's Proxy to Access Operating System Resources

• Scenario Description: An agent running on a user's device (e.g., a laptop or smartphone) needs to perform tasks that require access to local resources like files, applications, or system settings.
• Example: Diana asks her desktop agent, "Clean up my downloads folder and free up disk space." To do this, the agent needs permission to read and delete files within /home/diana/downloads. However, to be "helpful," the agent might also try to clear system-wide caches, which requires elevated, system-level permissions.
• Authorization Requirements:
  • Fine-Grained Resource Access: The agent should be granted access only to the specific files or settings needed for a task (e.g., a single folder), not the user's entire home directory or full system access.
  • Task-Scoped Permissions: Permissions should be granted for the duration of a specific task and automatically revoked upon completion. The task lifecycle is typically maintained by a remote agent service, and the OS should have a way to understand or be informed of task boundaries so that permissions can be properly bound to the task's lifetime.
  • Secure Privilege Escalation: If a task requires elevated permissions, there should be a secure, user-approved mechanism for the agent to request them just-in-time, rather than running with high privileges constantly. Such a mechanism account for the fact that the requester is an autonomous agent—a non-human subject with uncertain operational status—rather than assuming a fully capable and responsible human user is always present and in control.
• Gap Analysis:
  • What Works (Partially): Modern operating systems have their own permission models (e.g., app sandboxing, runtime permission prompts).
  • What's Missing (The Gap):
    • Architectural Mismatch: OAuth is a framework for network-based delegated authorization. It is not designed to manage local, process-level OS permissions. There is a fundamental mismatch between the two models.
    • No Protocol-Level Link Between Task Lifecycle and Permission Lifecycle: There is no standard protocol to connect an agent's high-level task intent (often determined in the cloud or maintained by a remote agent service) to a secure, fine-grained grant of local OS permissions on the device. More fundamentally, even if a task lifecycle is tracked by the agent service, the OS has no visibility into that lifecycle and no standard way to understand when a task begins, updates, or completes. Without a protocol-level link between task state and permission state, the OS cannot bind a permission grant to the duration of a specific task or automatically revoke it upon task completion.
    • No Elevation Mechanism Suitable for Agent Subjects: While operating systems provide privilege escalation mechanisms (e.g., sudo, UAC, macOS authorization dialogs), these are designed for human users who are capable of acting autonomously and taking responsibility for their actions. Their core assumption is that the requester is a responsible human subject. An autonomous agent, however, is a non-human subject with uncertain operational status—it may make errors, enter unexpected states, or require human intervention. Existing elevation mechanisms do not support a non-human subject requesting elevation on behalf of a user, nor do they provide a way to attribute accountability when an agent's elevated action causes harm. As a result, developers are forced to choose between two undesirable outcomes: either the agent runs with persistent broad permissions (violating least privilege), or every elevation request requires human intervention (defeating the purpose of automation). The gap is not merely the absence of a mechanism for one-time elevation, but the absence of a mechanism designed for agents as a distinct subject type with built-in safety and accountability guardrails.

Use Case 6: First Connection to a Service with No Authorization Front Channel

• Scenario Description: A user wants their agent to access a service that has no authorization server relationship, its own or a delegated one, and exposes no browser-facing authorization endpoint. The agent runs in a headless or remote environment with no co-located browser. Neither side can present the front channel that existing flows assume.
• Example: Dana subscribes to a note-taking service that exposes a plain REST API with no authorization server and no browser-facing authorization endpoint, as is common for services and MCP servers that predate or do not implement an authorization framework. She wants her personal assistant agent, which runs on a cloud host, to file notes for her. To make the first connection, Dana needs to:
  1. Grant the agent scoped access (notes.write, but not account.manage).
  2. Set a lifetime for that access and retain the ability to revoke it.
  3. Get the resulting credential to the agent, which has no browser and cannot complete a redirect-based flow.

Today her only practical option is to copy a static API key into the agent's environment variables: long-lived, all-or-nothing, and invisible to her after setup.

• Authorization Requirements:
  • Front-Channel-Free Bootstrapping: The first-connection grant must be possible when neither the service nor the agent can present a browser-based interaction channel.
  • User-Authored Grant: The user, not the agent, needs a way to initiate the grant and set its scopes and lifetime, since there is no authorization request for the agent to redirect her to.
  • Scoped, Revocable Credential: The resulting credential must carry a constrained scope and lifetime and remain revocable by the user, in contrast to the static API key it replaces.
• Gap Analysis:
  • What Works (Partially): The Device Authorization Grant removes the co-located browser requirement on the client side. Static API keys work operationally, which is why they are the de facto practice.
  • What's Missing (The Gap):
    • A verification page is still assumed: presumes an authorization server with a browser-facing verification page, and the client initiates the request and proposes the scopes. It does not cover the case where no such page exists because the service has no front channel at all.
    • No standard first-connection grant: There is no standardized way for the user to grant scoped, revocable access and for the agent to obtain the resulting credential when no front channel exists on either side. This precedes the flows in the existing use cases; Use Case 1's gap analysis, for example, notes that the Authorization Code flow can obtain the initial permissions, which assumes that front channel is available.
    • The workaround is the anti-pattern: Environment-variable API keys are long-lived, over-broad, and invisible to the user after setup; these are the same over-privileging properties Section 5 warns against.

Use Case 7: First Connection with a Front Channel the Client Does Not Use

• Scenario Description: A user is working with an agent that reaches a service on her behalf. The agent's client connects to the service for the first time and holds no credential for it. The resource server answers the first request with a challenge whose WWW-Authenticate header points to its protected resource metadata [RFC9728], and its authorization server supports the authorization code grant with PKCE . The user is present and a browser is available. Both sides can present the front channel and the client can run the grant, but whether it starts one in response to the challenge is left to the client, and when it does not, the resource server is not told why.
• Example: Erin asks the assistant in her terminal to file a bug in her team's tracker, which the agent reaches through an MCP server protected by the team's authorization server. The first request is answered with 401. Depending on the client and how it was started, the agent opens the sign-in page, fetches the metadata and stops, or stops at once. In the last two cases the agent goes on without the tracker's tools, and what Erin is told, if anything, varies by client. To make the first connection, Erin needs:
  1. The client to start the authorization when the challenge arrives and she is present, after showing her which authorization server and resource she is being sent to.
  2. The consent step to stay with her and out of reach of the agent's own automation.
  3. When the client does not complete it, the resource server to learn what happened, so it can wait, offer another path, or tell her what to do.
• Authorization Requirements:
  • Acting on a Challenge: A client that can run an interactive grant and has a user present needs to be able to treat a resource server's challenge as a request to start one, with the user's consent.
  • Terminal Disposition: A client that does not complete the challenge needs a standard, machine-readable way to tell the resource server what happened, from a small enumerated set, for example: user interaction required, user interaction pending, flow not supported, refused by policy, and failed.
  • Visible Destination: Before the user is sent anywhere, the client needs to show which authorization server and resource the challenge points to, since both come from the resource server.
• Gap Analysis:
  • What Works (Partially): defines the challenge, [RFC9728] lets the client find the authorization server from it, and the authorization code grant with PKCE runs once the client starts it. Client ID metadata documents and Dynamic Client Registration let a client with no prior relationship identify itself.
  • What's Missing (The Gap):
    • No expectation to act: These documents describe what a client can do after a challenge; none says when it should. Measurements of eight shipped MCP clients, against a resource server that answered the first request with 401 and a challenge carrying resource_metadata, found that in one-shot mode one ran the grant on its own and one did so only with a per-server configuration flag. The rest stopped after discovery or registration, or did nothing, although one of them ran the grant when started as an interactive session. All eight completed the same grant through their own sign-in steps.
    • No disposition: A client that does not complete the challenge has no standard way to say why. Policy refusal, an unsupported flow, pending user interaction and failure all look the same to the resource server, which hurts incident triage and audit evidence as well as the user. In the measurements, a client in the middle of signing in left the same trace at the resource server as two that had given up: a 401, a fetch of the protected resource metadata, then nothing until its first request with a token.
    • No presence signal: No standard mechanism lets a client tell the resource server that a user is present and able to complete a front-channel step.
    • Scope: Completing the challenge establishes grant-layer authority only. Binding a person's decision to the parameters of a specific consequential action stays with the execution-layer evidence the document already separates.

Category 2: Enterprise & Business Process Scenarios

Authorization Requirement Summary The enterprise and business-process use cases share several recurring authorization requirements, although the form of each requirement depends on the workflow structure and trust boundaries involved.

Requirement Theme	Use Cases and Forms
Constrained Delegated Authority	UC8: least privilege at each step; UC9: authority partitioned by branch; UC10: domain- and operation-specific permissions; UC11: scoped delegation to sub-providers and tenants; UC12: attenuation at each delegation hop; UC13: constrained and verifiable delegation for subtasks.
Verifiable Delegation Provenance	UC8: verification of the multi-hop authorization path; UC10: verification of the Registrant--Registrar--Registry delegation; UC12: verification of attenuated authority and the represented principal across organizations; UC13: end-to-end verification of delegation restrictions.
Common Task Identifier Across Hops	UC8: common claim_id; UC10: common audit context identifier across agent hops; UC13: consistent authorization context across subsequent approvals.
Revocation & Authorization Lifecycle	UC9: termination of task-group authority; UC10: task-specific revocation; UC12: revocation with bounded staleness; UC13: task-scoped revocation of derived authority across domains.
Cross-Domain Authorization	UC11: authorization across sub-provider administrative domains; UC12: authorization between independently administered organizations; UC13: consistent context and revocation across domains.

The summary includes only authorization requirements that recur across multiple use cases. Use-case-specific requirements or gaps remain with the individual scenarios, such as data-subject authorization and execution-layer evidence in UC8, aggregate constraints and late-bound members in UC9, the standardized representation of a cross-agent audit identifier in UC10, batched authorization in UC11, stranger verifiability in UC12, and the incomplete binding between original tasks and subsequent authorizations in UC13.

Use Case 8: Complex Business Process Automation

• Scenario Description: A task is passed through a chain of specialized agents, each performing one step of a larger business process.
• Example: An automated insurance claim process:
  1. Agent A (Intake): Receives a claim from a customer and is authorized to read the customer's policy. It passes the claim to the next agent.
  2. Agent B (Verification): Receives the claim from Agent A. It is authorized to access external databases to verify the details of the incident. It then passes the verified claim to Agent C.
  3. Agent C (Adjudication): Receives the verified claim from Agent B. It is authorized to run a risk assessment and approve or deny the claim. If approved, it delegates the final action to Agent D.
  4. Agent D (Payment): Receives the approved claim from Agent C. It is authorized only to execute a payment to the customer's bank account for the approved amount.
• Authorization Requirements:
  • Verifiable Delegation Chain: The final agent (Payment Agent D) and the resource server (the bank's API) should be able to cryptographically verify the entire authorization path: Customer -> Agent A -> Agent B -> Agent C -> Agent D.
  • Principle of Least Privilege at Each Step: Agent B should have no payment authority, and Agent D should have no access to the customer's policy details. The permissions must be strictly constrained at each step in the chain.
  • Auditable Context: The entire process must be tied to a single, auditable claim_id that is securely passed along the chain.
  • Data Subject: Where an agent accesses data describing a Data Subject (a natural person who is not the authorizing Resource Owner), the system need provide a mechanism for the Data Subject to authorize the access and be able to determine and represent the authority that permits this access.
  • Execution-Layer Evidence for Final Action: The final payment action by Agent D must not only be authorized by the delegation chain (Grant-Layer Authority) but must also generate verifiable Execution-Layer Evidence. This evidence must bind the specific payment details (amount, recipient) to the full, verifiable delegation chain and the original claim_id, creating an undeniable record that the specific transaction was legitimate and explicitly sanctioned.
• Gap Analysis:
  • What Works (Partially): OAuth 2.0 Token Exchange introduces the act (actor) claim, which provides a primitive to show that one agent is acting on behalf of another. This is a foundational building block.
  • What's Missing (The Gap):
    • No Native Support for Chains: A standard OAuth token represents a simple, two-party delegation (User -> Agent A). It cannot natively represent a multi-step chain (User -> A -> B -> C). While the act claim from helps, there is no standard for how to nest these claims to create a verifiable, multi-hop chain. This is a major architectural gap.
    • Lack of Standardized Context Passing: There is no standard field in an OAuth token to carry the claim_id securely through the process. Developers resort to custom claims in a JWT, which harms interoperability.
    • No Standard Representation for a Third-Party Data Subject: Existing OAuth mechanisms do not define common semantics for representing that the protected data being accessed concerns a person who is distinct from the Resource Owner or authorization subject, or for indicating the authority under which that third-party data may be accessed. RFC 8693 can represent the current and prior actors in a delegation chain, but does not define a distinct Data Subject role for this purpose. RFC 9396 permits application-specific authorization details, but does not define common semantics for representing this relationship. As a result, downstream agents and Resource Servers cannot rely on an interoperable representation of the Data Subject relationship or the authority permitting access to that person's data.
    • No Standard for Execution-Layer Evidence: The existing OAuth framework excels at defining Grant-Layer Authority—what an agent is allowed to do. However, it lacks a standard mechanism for generating Execution-Layer Evidence—a non-repudiable, cryptographic proof of a user's explicit consent for a specific, high-risk action at the moment it occurs. This gap is critical for auditability and dispute resolution in processes like insurance claim payments, as grant-layer tokens (representing the delegation chain) prove potential, not the legitimacy of a specific, executed transaction.

Use Case 9: Coordinated Task Group

• Scenario Description: A coordinating agent decomposes a user's request into subtasks and delegates them to multiple specialized agents. Unlike a delegation chain (Use Case 7), authorization in a task group may need to be partitioned across sibling branches, while some task-level constraints and lifecycle state remain shared across the group .
• Example 1 -- Partitioned Authorization: A payment assistant coordinates agents from multiple banks to compare promotional discounts for a payment. Each bank agent should receive only the permissions and authorization context required for its own bank. Permissions or sensitive context assigned to one branch should not automatically be available to another branch.
• Example 2 -- Shared Task Constraint: A user asks a travel assistant to arrange a business trip and authorizes a total spend of at most 100 units for the trip. The assistant delegates flight booking to a flight agent and hotel booking to a hotel agent operating in separately administered domains. The user has not fixed how the limit is divided between the two. Each delegated authorization may be valid independently, while their combined use may exceed the task-level limit.
• Example 3 -- Late-Bound Members: A health assistant decomposes a user's request into health-data collection, status prediction, and advice generation. Some sub-agents may be selected upfront, while others may be selected during execution as intermediate results determine which additional capabilities are needed.
• Authorization Requirements:
  • Branch-Level Partitioning: The authorization framework must support partitioning permissions and relevant authorization context among members according to their subtasks and resource domains.
  • Task-Level Aggregate Constraints: The authorization framework must support binding multiple delegation branches to constraints that apply to and are consumed by the task as a whole.
  • Late Binding of Members: Members selected during task execution must be able to obtain appropriately constrained authority under the existing task authorization.
  • Group Lifecycle: Authority associated with the task group must be able to be terminated as a unit when the task ends or its authorization is revoked.
• Gap Analysis:
  • What Works (Partially): Existing mechanisms address several parts of this problem. considers centralized authorization for static and dynamic task groups. allows a client to express how permissions and authorization context are partitioned across multiple actors in an authorization request, including scoping the permitted actor per authorization_details entry. Token Exchange , Identity Chaining , and Transaction Token Chaining provide building blocks for propagating delegated authority and context along individual delegation chains.
  • What's Missing (The Gap):
    • No Common Task-Group Authorization Model: Existing mechanisms can authorize or constrain individual members, but do not define a common interoperable binding that relates independently delegated authorities to the same task group, including late-bound members and a common lifecycle.
    • No Shared Authorization State Across Branches: Per-member partitioning does not address constraints consumed jointly by multiple branches. Across separately administered domains, there is no standard way for delegated authorizations to reference and consistently enforce the same task-level aggregate authorization state.

Use Case 10: Automated DNSSEC DS Record Maintenance Agent

• Scenario Description: This case follows the multi-agent RRR (Registrant-Registrar-Registry) model defined in . A corporate domain owner deploys chained agents to fully automate DS record updates during DNSSEC KSK rollovers, zone bootstrapping, and zone deletion, relying on CDS/CDNSKEY signals between child authoritative zones and parent registry systems.
• Example: The whole workflow runs unattended under a one-time delegated permission from the domain registrant, forming a delegation chain: Registrant --> Registrar Agent --> Registry Agent.
  • Zone Agent: Publishes consistent CDS/CDNSKEY records on all name servers after key rollover.
  • Registrar Agent: Pulls and validates CDS data, forwards DS update requests to the registry.
  • Registry Agent: Applies DS records to the parent zone and sends operation notifications.
• Authorization Requirements:
  • Verifiable Delegation Chain: A cryptographically verifiable multi-hop delegation chain is required for a full audit trail.
  • Fine-Grained, Constrained Authority: Permissions must be limited to a fixed set of domains and allow only DS updating, without the ability to modify other DNS records.
  • Task-Scoped Revocation: The ability to revoke all DS automation permissions for a specific task without affecting other agent workflows.
  • Standardized Audit Context: A standard audit context identifier must be passed across all agent hops for compliance logging.
• Gap Analysis:
  • What Works (Partially): Client Credentials can assign identities to registry/registrar agents. RFC 8693 token exchange supports simple single-hop agent delegation.
  • **What's Missing (The Gap)
    • No Standard for Multi-Hop Delegation: Current DS automation does not use OAuth. OAuth only supports two-party delegation and lacks a standard syntax for representing a multi-hop RRR delegation chain. Relying on proprietary JWT claims harms interoperability.
    • No Standardized Fine-Grained Authority for DNS: While Rich Authorization Requests (RAR) provides a syntax for expressing fine-grained permissions, there is no standardized authorization type or structure defined for DNS operations. Without a common definition, each implementation would invent its own, preventing interoperability for this specific requirement.
    • Inadequate Revocation Mechanisms: OAuth has no standardized task or bulk revocation API. Securing the entire DS automation workflow via OAuth would require making numerous, slow single-token revocation calls during an incident.
    • No Standard for Cross-Agent Audit ID: There is no reserved OAuth JWT claim to carry a consistent audit identifier across all agent hops, which breaks end-to-end compliance logging for the DS automation process.

Use Case 11: Managed Services

• Scenario Description: The managed service model refers to an integrated end-to-end managed service solution delivered by a prime service integrator through the aggregation of infrastructure and services from multiple sub-providers. End users interact with a single, unified resource platform instead of multiple separate sub-modules. However, coordinating resources across different administrative domains introduces complex authorization challenges.
• Example:
  • Telecom operator delivers a managed global secure SD-WAN orchestration service, which requires coordination of many localized regional telecom operators/ISPs and security service providers.
  • Telecom operator delivers a managed smart home + security solution through a home-hub, which integrates controls over IPTV, streaming services, smart IoT (security cameras) etc.
• Authorization Requirements:
  • Cross-domain Authorization: The fast provisioning of an integrated service (take SD-WAN as an example) requires acquiring authorization from different service sub-providers in their respective administrative domains.
  • Batched Authorization: The fast provisioning of the integrated service requires requesting a batch of authorizations from different service sub-providers.
  • Delegated Authorization:
    • Prime service integrator may need to conditionally delegate network configuration modification privileges for specific branches to the on-site O&M teams of local sub-providers. This delegation MAY be hierarchical.
    • End-users are often times tenants that only have renting privileges instead of ownership rights. Thus technically the prime service integrator is delegating the access privileges to the end-user to access each modular sub-service.
• Gap Analysis:
  • What Works (Partially):
  • Cross-domain Single Authorization: The OAuth allows cross-domain authorization through OAuth 2.0 authorization grant and Identity Chaining. But it MUST require one access token at a time.
  • Single Domain Workflow: The OAuth allows workflow orchestration through Transaction Token. It only allows workflow inside one trust domain.
  • What's Missing (The Gap):
    • No Standard for Multi-Hop, Attenuated Delegation: The scenarios involving delegation to sub-provider O&M teams or end-user tenants represent a multi-hop, hierarchical delegation where permissions must be narrowed (attenuated) at each step. While OAuth 2.0 Token Exchange supports a single delegation hop, there is no standard mechanism to represent or verify a full, attenuated delegation chain. This forces reliance on proprietary, non-interoperable solutions to ensure that a sub-provider or tenant cannot exceed the authority granted to them.
    • Batched Authorization: There is no standard for requesting access permissions for a batch of resources at once, while precisely delegating fine-grained privileges to the respective sub-agents responsible for executing each sub-task.
    • Cross-domain Workflow: There is no standard for request access permissions across different trust domains while ensuring the secure propagation of contextual information (claims, caller identity, rich authorization contexts, etc.).

Use Case 12: Cross-Organizational Delegation Between Fully-Provisioned Organizations

• Scenario Description: An agent operated by Organization A must invoke a service operated by Organization B. Each organization runs its own complete trust infrastructure: its own authorization server, identity provider, and workload identity systems. No trust relationship, federation agreement, key exchange, or communication channel exists between them before the first request, and none can be assumed: the interaction may be first contact. This is the ordinary condition of open agent-to-tool ecosystems (e.g., MCP tool servers, agent-mediated commerce) once agents cross organizational boundaries.
• Example: A manufacturer's procurement agent, acting on behalf of a named employee, invokes a supplier's quoting and ordering API. The supplier has never onboarded the manufacturer. At request time the supplier's service must determine: (a) that the calling agent is operated by an identifiable, accountable organization; (b) that the agent holds authority for this specific operation, delegated through possibly several intermediate agents, each of which may only have narrowed it; (c) that the agent acts on behalf of the claimed human principal; and (d) that none of that authority has been revoked - all within its normal request latency, and without a synchronous callback to the manufacturer's infrastructure, whose availability and reachability it does not control.
• Authorization Requirements:
• Stranger Verifiability: The receiving organization must be able to verify authority rooted in the sending organization using generally available infrastructure that both parties joined independently, with no interaction-specific bilateral arrangement (no pre-exchanged keys, no shared authorization server, no federation onboarding step).
• Verifiable Attenuated Delegation: Presented authority may have passed through multiple agents. Each hop may only narrow it (permitted operations, resource scope, validity), and the receiver must be able to verify both the narrowing and the invariance of the on-behalf-of principal from the presented material itself, rather than by trusting the sending organization's internal policy.
• Local Decision with Bounded Revocation Staleness: The receiver's authorization decision must complete without a runtime call to the sending organization, while revocation of the sender's authority must still reach the receiver with an explicit, bounded staleness that the receiver can enforce and fail safe on.
• Gap Analysis:
  • What's Missing (The Gap):
    • Pre-Established Trust Assumption: Existing cross-domain mechanisms presuppose arranged trust. OAuth Identity Chaining, for example, requires the participating authorization servers to have pre-established trust and exchanged key material (Section 2.1) - precisely what a first-contact interaction lacks by definition.
    • Runtime Coupling to Foreign Infrastructure: Token-exchange and challenge-based patterns place the sending side's authorization server (or one federated with it) in the request path, making the availability, latency, and reachability of another organization's infrastructure a precondition for the receiver's own service.
    • Delegation Opacity at the Receiver: Standard access tokens do not allow a receiving organization to independently verify multi-hop narrowing or the invariance of the acting-for principal across intermediaries; the receiver is asked to trust issuer-side policy it cannot inspect.

Use Case 13: Industrial Agent for Equipment Maintenance

• Scenario Description: A manufacturing enterprise uses an industrial agent to coordinate equipment maintenance. The agent delegates diagnostic and corrective tasks to specialized agents, some operated by an equipment supplier. The participating organizations have an established trust relationship but administer their authorization independently. The actions and agents needed may only become known during execution. A task may begin with permission to read equipment data and later require separate approval for an operational change. The authorization challenge is to preserve the relationship between the original task, subsequent approvals, and delegated authority across this evolving workflow.
• Example: A plant manager asks a maintenance agent to investigate a production issue and recommend a corrective action:
  1. Agent A (Coordination): Receives authorization to investigate the issue and delegate diagnostic work. Its initial authority permits access to relevant equipment data but does not permit changes to equipment operation.
  2. Agent B (Diagnosis): An equipment supplier's agent receives limited authority from Agent A to read the data needed for diagnosis. It may delegate part of the analysis to another specialized agent, subject to the same or narrower restrictions. The enterprise's data service must be able to verify the resulting delegated authority.
  3. Additional Approval: Agent A uses the diagnosis to propose an operational adjustment. Because this exceeds its existing authority, it requests additional authorization from the plant manager. The manager reviews the proposed action in the context of the original maintenance task and authorizes only that action and its delegation for execution.
  4. Agent C (Execution): Agent A delegates the newly approved action to an execution agent. The equipment service, acting as the Resource Server (RS), verifies that the request is covered by the approved action and the authority delegated to Agent C. Agent B's diagnostic authority does not acquire the additional execution permission.
  5. Task Completion or Cancellation: When the task ends or the manager withdraws authorization, authority derived for that task must cease to permit further requests, including authority delegated to supplier agents. Other maintenance tasks should remain unaffected.
• Authorization Requirements:
  • Constrained and verifiable Delegation: Each agent must receive only the authority needed for its subtask. The receiving RS must be able to verify the originating principal, the calling agent, and the applicable delegation restrictions. Where enterprise policy requires verification of each delegation step, the presented authorization information must support that verification across organizational boundaries.
  • Task-Bound Additional Authorization: Permissions discovered during execution must be requested under the original task context. Additional approval must identify the operation being authorized and the agents permitted to exercise or further delegate that authority. Approval of a corrective action must not broaden permissions held by agents performing diagnosis.
  • Consistent Authorization Context: The task, its approvals, and the authority derived for participating agents must have a verifiable association across authorization servers and resource servers. This association must support authorization decisions and auditing without disclosing unrelated task data or internal workflow details.
  • Task-Scoped Revocation: The authorizing principal must be able to terminate authority derived for the task, including downstream authority issued in other domains. Participating systems must have a defined way to determine which authorizations are affected and the maximum delay before withdrawal takes effect. This concerns authorization of further requests; handling an operation already in progress remains an application responsibility.
• Gap Analysis:
  • What Works (Partially): OAuth 2.0 supports initial authorization and subsequent authorization requests. Rich Authorization Requests (RAR) can describe a proposed operation. Token Exchange supports delegation and nested act claims identifying current and prior actors. Token Revocation and Token Introspection provide token revocation and status checking. Work in progress also addresses parts of this workflow: Identity Chaining supports authorization across established trust domains; Transaction Tokens and the Transaction Token Chaining Profile propagate transaction context, with the latter also constraining scope across domains; addresses task groups and member-token revocation.
  • What's Missing (The Gap):
    • Incomplete Binding Between Tasks and Subsequent Authorizations: A new authorization request can obtain permission for the corrective action, and transaction identifiers can correlate requests. However, the mechanisms above do not provide a common profile relating the original task authorization, a later approval, and the authority issued to different agents for that task. Such a profile needs to distinguish an approved extension of the task's authority from unrelated access and specify which delegated authorities the new approval affects. This is a gap in common authorization relationships, rather than in the representation of industrial operations.
    • Incomplete End-to-End Verification of Delegation Restrictions: Actor history in does not itself prove the restrictions granted at each delegation step. Cross-domain chaining can enforce scope limits through trusted authorization servers, but this does not provide the receiving RS with an independently verifiable record of each upstream delegation and its restrictions. Where that stronger assurance is required, interoperable rules for representing and validating the relationship between source and derived authority remain necessary. Deployments that accept the issuing authorization server's assurance can already rely on existing trust mechanisms and policy.
    • Incomplete Revocation of Derived Authority Across Domains: permits revocation of related tokens from the same grant, but a maintenance task may involve multiple grants and authorization servers. does not generally link the lifecycle of an exchanged token to its source token. Task-group revocation in the cited work in progress does not establish a cross-domain lifecycle for all such derived grants. The remaining gap is a common way to identify dependent authorizations, propagate withdrawal across domains, and establish when downstream enforcement has taken effect. Short token lifetimes and introspection help limit exposure but do not define this dependency model.

Category 3: Security & Administrative Scenarios

Use Case 14: Automated Security Incident Response

• Scenario Description: A security agent detects a security threat and must take immediate, automated action to contain it.
• Example: A security system detects that an employee's laptop has been compromised by malware. An automated security agent is triggered to:
  1. Immediately revoke all active login sessions for that employee across all company applications (e.g., email, code repository, HR system).
  2. Isolate the compromised laptop from the corporate network.
  3. Temporarily suspend the user's account to prevent further unauthorized access.
• Authorization Requirements:
  • Privileged, System-Level Authority: The security agent needs broad, pre-approved authority to perform high-impact administrative actions.
  • Global Token Revocation API: The agent must be able to make a single API call to the Authorization Server to "immediately revoke all access and refresh tokens associated with user ID employee-123."
  • Non-Repudiable Execution Evidence: For post-hoc audits and security forensics, simply logging the action is insufficient. A critical requirement is the generation of durable, non-repudiable, and potentially offline-verifiable evidence at the moment of execution. This evidence must cryptographically attest to the specific action performed (e.g., "Agent sec-ops-bot-01 isolated host laptop-789 at 2024-08-21T10:00:00Z under policy POL-456 in response to alert ALERT-XYZ"). This formal proof is essential for accountability, especially when an automated agent takes high-risk actions like suspending a user account.
• Gap Analysis:
  • What Works (Partially): The OAuth Client Credentials grant is suitable for giving the security agent its own system-level identity and authority.
  • What's Missing (The Gap):
    • Critically Inadequate Revocation API: This is the most significant gap for this use case. The one-token-at-a-time revocation endpoint in is completely insufficient for a security incident. The need to make potentially thousands of individual API calls to revoke tokens is too slow and unreliable during an active attack. The lack of a standardized bulk revocation API is a major operational and security failure point.
    • Absence of a Standard for Verifiable Action Records: The OAuth framework focuses on granting and validating the authority to perform an action (i.e., possessing a valid token). It does not, however, define a standard mechanism for creating a durable, cryptographically verifiable record of the action itself at the moment of execution. In a security context, a simple log entry stating "action performed" is insufficient for high-stakes forensic analysis. What is missing is a formal, non-repudiable piece of evidence that binds the agent's identity, the specific action taken (e.g., "isolate host laptop-789"), the policy justification, and the timestamp into a single, verifiable artifact. This gap makes it difficult to construct an undeniable audit trail for automated, high-risk security operations.

Analysis of Existing OAuth Extensions The OAuth 2.0 ecosystem is rich with extensions designed to address security and functionality gaps in the core specification. However, many of these powerful extensions were conceived before the rise of highly autonomous, dynamic, and often ephemeral AI agents. Their design assumptions, therefore, do not always align with the unique challenges presented by agent-centric architectures. This section analyzes several key existing extensions and related concepts to evaluate their applicability to agent authorization use cases. For each, we identify its strengths, its limitations in agentic scenarios, and potential directions for evolution.

Rich Authorization Requests (RAR)

• Applicability and Strengths: RAR represents a significant step beyond simple string-based scopes. It allows clients to request fine-grained, structured, and parameterized permissions. For example, instead of a generic transaction scope, a client can request authorization for a specific action like {"type": "payment", "amount": "50", "currency": "USD", "recipient": "X"}. This capability is invaluable for creating auditable and least-privilege grants, which is a core requirement for reining in agent capabilities.
• Limitations in Agentic Scenarios: The primary limitation of RAR in agentic scenarios is its static nature. RAR defines the structure of a permission, but it assumes the values are known at the time of the authorization request. Autonomous agents often operate with non-deterministic logic; they discover the need for specific actions as they execute a task. An agent planning a picnic might not know the exact cost or booking details for a park shelter until it has already completed several other steps. This makes it difficult to request all necessary, fine-grained permissions upfront. In essence, RAR is a powerful Grant-Layer mechanism for defining the shape of authority. It cannot, by design, capture the user's specific, just-in-time consent for a transaction whose final parameters were only determined at the moment of execution. It describes the authority, not the human decision at runtime.
• Potential Directions for Evolution: A potential direction is to evolve RAR or develop a complementary mechanism for "bounded capabilities". This would allow a user to grant an agent a budget or a set of constraints (e.g., "a maximum of $100 for picnic supplies within a 10-mile radius"). The agent could then use this grant to dynamically construct and justify specific RAR-formatted requests at runtime, with the authorization server validating each request against the pre-approved bounds.

Demonstrating Proof-of-Possession (DPoP)

• Applicability and Strengths: DPoP enhances security by cryptographically binding access tokens to a specific client's public/private key pair. This effectively prevents token theft and replay attacks, as a stolen token is useless without the corresponding private key. This is a critical security baseline for any system where agents handle sensitive operations.
• Limitations in Agentic Scenarios: The challenge arises in highly dynamic agent architectures. DPoP's model assumes a relatively stable client with a persistent key. This assumption breaks down when a primary agent needs to delegate a task to a dynamically created, ephemeral sub-agent, or when an agent migrates between compute environments. Each new instance would require a new token bound to its new key, creating significant overhead and complexity if it requires a full round-trip to the authorization server. DPoP is a critical Grant-Layer security control, binding a token to a client to prove the legitimacy of the actor possessing the authority. However, it says nothing about the legitimacy of the specific action being performed at the Execution Layer or the user's explicit consent for that action.
• Potential Directions for Evolution: Future work could explore a "multi-hop DPoP" model. In this model, a parent agent holding a DPoP-bound token could securely derive a new, more constrained token for a sub-agent, binding it to the sub-agent's ephemeral key. This would create a verifiable chain of possession and delegation without requiring constant interaction with the central authorization server, making it more suitable for chained or group agent tasks.

Client-ID Metadata Document (CIMD)

• Applicability and Strengths: CIMD (and the broader concept of dynamic client registration) proposes a powerful shift from static, pre-registered clients to dynamic, discoverable ones. By defining client_id as a resolvable URI, an Authorization Server can fetch client metadata on-the-fly. This enables "plug-and-play" onboarding for new agents and greatly simplifies the lifecycle management of cryptographic keys by exposing them via a jwks_uri.
• Limitations in Agentic Scenarios: Despite its flexibility, CIMD's current metadata vocabulary is client-application-centric, not agent-centric.
  1. Lack of Agent Context: Standard fields (e.g., redirect_uris, client_name) fail to describe agent-specific attributes like its level of autonomy, risk profile, or operational policies.
  2. Public URI Dependency: The reliance on a stable, public URI is problematic for ephemeral or internal sub-agents that may not have a persistent, publicly resolvable address.
  3. Missing Delegation Traceability: While CIMD can verify an agent's identity, it does not provide a standard mechanism to describe its lineage or delegation path (i.e., "who created this agent?").
• Potential Directions for Evolution: To bridge these gaps, CIMD could be extended with:
  1. Agent-Specific Metadata: Introduce new fields like agent_type, max_autonomous_budget, or human_in_the_loop_policy to enable better risk assessment by Authorization Servers.
  2. Inline or Vouched-For Metadata: Allow ephemeral agents to present their metadata directly in a request or have it "vouched for" and signed by a trusted parent agent, removing the public URI requirement.
  3. Trust Chain Assertions: Incorporate fields like parent_agent_id or integrate concepts from specifications like OpenID Federation to build a verifiable delegation chain.

Transaction Tokens

• Applicability and Strengths: This refers to a common architectural pattern, often implemented using JWTs, where initial user context is encoded into a token and propagated through a series of internal microservices. This ensures consistent authorization and context within a trusted security domain.
• Limitations in Agentic Scenarios: The fundamental gap is one of trust boundaries. This pattern is designed for use within a single, trusted system. It is ill-suited for multi-hop delegation scenarios involving untrusted third-party agents, as the tokens lack standard mechanisms for permission attenuation (reduction) or enforcement across organizational boundaries.
• Potential Directions for Evolution: To be viable in agent ecosystems, this concept would need to evolve into a standardized "Attenuating Agent Token". Such a token would need a formal, interoperable mechanism for a parent agent to reduce permissions before passing it to a child agent, ensuring the child cannot exceed the parent's authority. Furthermore, embedding verifiable proofs of execution could enhance end-to-end auditability.

Summary of Major Gaps The use cases above highlight several fundamental gaps between the needs of AI agents and the capabilities of the standard OAuth 2.x framework:

1. From 'Pre-Approval' to 'Continuous Dialogue': A Paradigm Shift. OAuth's model is to get all permissions upfront. Agents need a continuous, interactive authorization model where permissions are granted dynamically and just-in-time as a task evolves from a high-level intent.
2. Lack of a Standardized Interactive Channel. The framework has no built-in mechanism for an agent to "pause" and securely ask the user for an intermediate decision or to respond to a real-time authorization challenge from a resource server.
3. Inability to Represent Delegation Chains. Standard tokens cannot securely represent a multi-step delegation chain (User -> Agent A -> Agent B). This is a critical blocker for automating complex, multi-agent business processes.
4. Insufficient Revocation Mechanisms. The single-token revocation API is inadequate. The lack of standardized APIs for task-level and bulk (per-user or per-client) revocation is a major operational and security deficiency.
5. Authorization Is Modeled Per-Client, Not Per-Group. OAuth has no notion of a set of clients acting as one task group under a single grant: no group membership representation, no admission of late-selected members, and no group-level lifecycle or atomic revocation.
6. The Grant-Layer vs. Execution-Layer Gap: The existing OAuth framework excels at defining Grant-Layer Authority—what an agent is allowed to do. However, it lacks a standard mechanism for generating Execution-Layer Evidence—a non-repudiable, cryptographic proof of a user's explicit consent for a specific, high-risk action at the moment it occurs. This gap is critical for auditability and dispute resolution, as grant-layer tokens prove potential, not the legitimacy of a specific, executed transaction.
7. Lack of Machine-Readable Terminal Disposition. When a client receives an authorization challenge from a resource server but fails or refuses to complete it (e.g., due to policy, lack of user presence, or unsupported flows), there is no standard, machine-readable way to communicate this disposition back to the resource server. This leaves the resource server to infer the client's state from silence, which hinders incident triage, auditability, and the ability to offer alternative paths to the user.

Security Considerations As we design new authorization mechanisms for agents, security must be the primary concern. The autonomy of agents amplifies the risk of any vulnerability.

• Risk of Over-Privileging: The current lack of dynamic authorization tempts developers to request broad, long-lived permissions ("god tokens"), dramatically increasing the damage if an agent is compromised. Future solutions must make it easy to follow the Principle of Least Privilege.
• Delegation Chain Vulnerabilities: Without a standard for secure delegation chains, custom implementations are prone to "Confused Deputy" attacks, where an agent is tricked into misusing its authority.
• Revocation Timeliness: In a world of powerful, autonomous agents, the ability to instantly and completely revoke all permissions for a compromised user or agent is not a "nice-to-have"; it is an absolute necessity.
• Non-Repudiation: For enterprise and B2B scenarios, actions taken by agents must be cryptographically auditable and non-repudiable, creating a strong digital paper trail.
• Coordinator as a Single Point of Authority: In coordinated task groups, the leading agent both requests authorization on behalf of all members and assigns their tasks. If the coordinator is compromised, the blast radius covers the entire group; its authority to act as an applier for others must therefore be separately authenticated, authorized, and auditable.
• Durable Record of the Authorization Grant: While agent actions must be non-repudiable, this is insufficient without a durable record of the authorization grant event itself. This record must capture the identity of the authorizing principal, the exact scopes granted, the time of the grant, and the policy version in effect, which disappear when a grant ends, this event record must persist to provide a verifiable source of truth for post-hoc audits and to answer the critical question: "What did the human actually authorize?".
• Agent-Operable Consent Surfaces: AI agents can click "Approve" buttons themselves, so a simple click is no longer proof of human consent. We need approval methods that agents can't fake, like a confirmation on your phone or a fingerprint scan.

IANA Considerations This document has no IANA actions.

Acknowledgements The analysis and use cases in this document are derived from observations of emerging AI agent technologies and their application trends across various industries. Thanks are due to the OAuth community for their past and ongoing efforts in building a secure and interoperable authorization framework, upon which this work is built. The authors would like to thank Blake Morrison, Mohamad Khalil Yossif, niyuan, Dick Hardt, Michael Jones, Christopher Emerson, morganLR, Eric Leleu, Thi Nguyen-Huu, Jeff, Laxmikant and Iman for commenting, contributing and providing feedback on this draft.

Informative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM Data-Fields are encapsulated in IPv6. Practical Identity LLC Defakto Security CVS Health This specification defines a profile of the OAuth Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining] mechanism that uses a Transaction Token (Txn-Token) [I-D.ietf-oauth-transaction-tokens] as the subject token in a Token Exchange [RFC8693] request to obtain a JWT Authorization Grant for crossing a trust boundary. A Txn-Token is scoped to a single trust domain and represents the full authorization context of an in-progress transaction, regardless of whether that transaction was initiated by a human user calling an external API, by an internal system event, or by an automated workload. This profile specifies how a service operating within that trust domain can present its Txn-Token to obtain a JWT Authorization Grant that carries the necessary context across a trust boundary, enabling an access token to be issued for a partner service, without exposing internal trust-domain credentials or token formats beyond the trust boundary. deSEC Enabling support for automatic acceptance of DNSSEC Delegation Signer (DS) parameters from the Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and success reporting, and multi-party issues such as concurrent updates. This document describes recommendations about how these points are best addressed in practice. Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Huawei Huawei This document describes a mechanism for Batch Authorization Delegation, which enables a batch of fine-grained, actor-bound permissions in a single request and securely delegates them to multiple collaborating actors. Huawei Huawei Huawei Singapore Huawei Singapore This method extends OAuth 2.0 by adding fields to token and message flows, enabling sub-agents to act as a task group. It simplifies authorization for task groups, avoids repeated interactions between sub-agents and the authorization server, and bounds the authority delegated to the group and to each member while maintaining compatibility with existing OAuth 2.0 workflows. Yuthent An autonomous software agent commonly acts under authority a human granted at an earlier moment: the human expresses and authorizes an intent at one time, and the agent executes one or more concrete actions at a later time. The credentials and session state the agent carries at execution time establish that some agent is authorized to act, but they do not establish that this specific action, with these specific parameters, falls within the constraints the human actually signed. As agent autonomy and action throughput grow, the population of executed actions that no human individually bounded grows with it. This document is a problem statement. It characterizes the gap between an authorized agent and an authorized action, explains why existing delegation, logging, and payment-mandate mechanisms do not close it, and states the requirements any solution would have to satisfy. It defines no protocol or mechanism.

References

Hardt, J., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, https://www.rfc-editor.org/info/rfc6749.

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, https://www.rfc-editor.org/info/rfc7009.

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, https://www.rfc-editor.org/info/rfc8693.

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, https://www.rfc-editor.org/info/rfc9396.

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, https://www.rfc-editor.org/info/rfc6750.

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, https://www.rfc-editor.org/info/rfc7591.

Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, https://www.rfc-editor.org/info/rfc7636.

[RFC9728]

Jones, M., Salgueiro, G., Jones, P., and P. Smyslov, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, February 2025, https://www.rfc-editor.org/info/rfc9728.

Brossard, D. and T. Lodderstedt, "OAuth 2.0 Client ID Metadata Document", Work in Progress, Internet-Draft, draft-ietf-oauth-client-id-metadata-document-02, 15 October 2024, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-02.

Ni, Y., "Batch Authorization Delegation for OAuth 2.0", Work in Progress, Internet-Draft, draft-ni-oauth-batch-authorization-delegation-00, https://datatracker.ietf.org/doc/html/draft-ni-oauth-batch-authorization-delegation-00.

Song, Y., Li, L., Jiang, Y., and F. Liu, "OAuth2.0 Extension for Multi-AI Agent Collaboration", Work in Progress, Internet-Draft, draft-song-oauth-ai-agent-collaborate-authz-01, 28 February 2026, https://datatracker.ietf.org/doc/html/draft-song-oauth-ai-agent-collaborate-authz-01.

Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-17.

Fletcher, G., Kasselman, P., and S. O'Dell, "Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining", Work in Progress, Internet-Draft, draft-fletcher-transaction-token-chaining-profile-02, 6 July 2026, https://datatracker.ietf.org/doc/html/draft-fletcher-transaction-token-chaining-profile-02.

Yossif, M., "Problem Statement: Verifiable Human Mandates for Autonomous Agent Actions", Work in Progress, Internet-Draft, draft-yossif-agent-mandate-problem-00, 22 July 2026, https://datatracker.ietf.org/doc/html/draft-yossif-agent-mandate-problem-00.