Agent Authorization use cases and gap analysis

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; UC2: Conditional authority (based on event or time); UC4: Just-in-time permission requests; UC6: Acting on a challenge.
Granular & Constrained Authority	UC1, UC3: User-defined constraints (e.g., spending limits); UC2, UC4: Fine-grained permissions (for devices, files); UC3: Agent-specific policies (e.g., rate limits); UC5: User-defined scopes for headless services.
Differentiated Actor Identity	UC3: Distinguishing human vs agent, between different agent classes.
Task-Oriented Lifecycle Management	UC1, UC4: Task-bound revocation; UC2: Bulk client revocation; UC5: Headless bootstrapping of credentials; UC6: Terminal disposition signaling.
Verifiable, Action-Specific Consent	UC1: Approval of final action parameters at execution time; UC6: 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 UC4, the need for independent per-class consent in UC3, and the lack of presence signaling and visible destination routing in UC6.

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: 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 3: 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 4: 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 5: 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 6: 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	UC7: least privilege at each step; UC8: authority partitioned by branch; UC9: domain- and operation-specific permissions; UC10: scoped delegation to sub-providers and tenants; UC11: attenuation at each delegation hop; UC12: constrained and verifiable delegation for subtasks.
Verifiable Delegation Provenance	UC7: verification of the multi-hop authorization path; UC9: verification of the Registrant--Registrar--Registry delegation; UC11: verification of attenuated authority and the represented principal across organizations; UC12: end-to-end verification of delegation restrictions.
Common Task Identifier Across Hops	UC7: common `claim_id`; UC9: common audit context identifier across agent hops; UC12: consistent authorization context across subsequent approvals.
Revocation & Authorization Lifecycle	UC8: termination of task-group authority; UC9: task-specific revocation; UC11: revocation with bounded staleness; UC12: task-scoped revocation of derived authority across domains.
Cross-Domain Authorization	UC10: authorization across sub-provider administrative domains; UC11: authorization between independently administered organizations; UC12: 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 UC7, aggregate constraints and late-bound members in UC8, the standardized representation of a cross-agent audit identifier in UC9, batched authorization in UC10, stranger verifiability in UC11, and the incomplete binding between original tasks and subsequent authorizations in UC12.

Use Case 7: 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 8: 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 9: 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 10: 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 11: 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 12: 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 13: 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.