Network Working Group C. Emerson Internet-Draft AgentAdmit Intended status: Informational 26 October 2026 Expires: 29 April 2027 User-Mediated Credential Delivery as a Complementary Authorization Primitive for AI Agents draft-emerson-oauth-user-mediated-delivery-01 Abstract This document proposes user-mediated credential delivery as a complementary authorization primitive for AI agent frameworks. Rather than delivering credentials through automated channels controlled by the agent or its platform, user-mediated delivery places the authorization decision and credential delivery in the user's trusted context, separate from the agent's execution environment. This document describes four methods: user-mediated credential delivery, self-describing connection credentials, caller-identity consent differentiation, and discovery-by-introspection. These methods address the human-in-the-loop gap identified in Section 10.7 of [KLRC] and strengthen the authorization foundation that the IETF AI Agent Authentication and Authorization framework depends on. This revision relates the primitive to the gap analysis in [CHEN-UC] and to the intent credential proposed in [INTENT], states how it composes with grant-layer mechanisms, and reports implementation status. The methods described in this document are patent pending. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 29 April 2027. Emerson Expires 29 April 2027 [Page 1] Internet-Draft User-Mediated Credential Delivery October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. The Gap: Automated Credential Delivery . . . . . . . . . . . 4 4. User-Mediated Credential Delivery . . . . . . . . . . . . . . 5 4.1. Structural Defense Against Prompt Injection . . . . . . . 7 4.2. Step-Up Authorization . . . . . . . . . . . . . . . . . . 8 4.3. Per-Action Confirmation . . . . . . . . . . . . . . . . . 8 4.4. Recording Intent Without Interpreting It . . . . . . . . 9 5. Self-Describing Connection Credentials . . . . . . . . . . . 9 6. Caller-Identity Consent Differentiation . . . . . . . . . . . 10 7. Discovery-by-Introspection . . . . . . . . . . . . . . . . . 11 8. Composition with Grant-Layer Mechanisms . . . . . . . . . . . 12 9. Relationship to the Use-Case Analysis . . . . . . . . . . . . 12 10. Strengthening the Framework . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 14. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . 18 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 15.2. Informative References . . . . . . . . . . . . . . . . . 18 Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Emerson Expires 29 April 2027 [Page 2] Internet-Draft User-Mediated Credential Delivery October 2026 1. Introduction [KLRC] provides a well-structured framework for composing existing standards to address AI agent authentication and authorization. The framework's approach, consolidating proven standards rather than proposing new protocols, is sound and timely. The AIMS model (Section 5 of [KLRC]), the layered stack from identifiers through compliance, and the integration of WIMSE, SPIFFE, and OAuth 2.0 provide a strong foundation. This document identifies a structural gap in the framework and proposes a complementary authorization primitive, user-mediated credential delivery, that addresses the gap while strengthening the processes the framework already defines. The gap is this: the framework provides no mechanism for a human user to proactively define the scope, duration, and delivery of authorization to an AI agent before the agent acts. Every authorization flow described in the draft, Authorization Code Grant (Section 10.4.1 of [KLRC]), Client Credentials (Section 10.4.2 of [KLRC]), cross-domain chaining (Section 10.6 of [KLRC]), CIBA-based human-in-the-loop (Section 10.7 of [KLRC]), delivers credentials through automated channels that the agent or its platform controls. The user approves, but the credential delivery is automated. This creates attack surfaces and limits user sovereignty over what agents can do with their data. [CHEN-UC] catalogues the same family of problems from the use-case side. Its authorization context gap (Section 3.1 of [CHEN-UC]), its summary gaps on interactive consent, revocation, and execution-layer evidence (Section 6 of [CHEN-UC]), and its first-connection use case with no authorization front channel (Section 4.1.6 of [CHEN-UC]) describe situations in which the user, not the agent, needs to be the party that frames and delivers authorization. Section 9 maps each of these to the methods in this document. The practical baseline is static credentials. A study of the published documentation of 1,634 Model Context Protocol servers found that, of the 857 that document a credential channel, 84.5% deliver the credential through an environment variable or configuration file, 8.3% document a way to revoke one grant on its own, and 8.8% document an expiring or user-chosen lifetime [MCP-STUDY]. Section 7 of [KLRC] calls static API keys an antipattern for agent identity; the same bearer, long-lived, hard-to-rotate properties make them an antipattern for user-delegated access, and that is the practice this primitive replaces. Emerson Expires 29 April 2027 [Page 3] Internet-Draft User-Mediated Credential Delivery October 2026 As software platforms shift toward agent-first architectures, with agents consuming APIs at orders of magnitude greater frequency than human users, the authorization layer becomes infrastructure, not a feature. User-mediated delivery provides that infrastructure. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Resource application: The application that holds the user's data and exposes the APIs an agent calls. It acts for the resource owner and as the resource server. It may operate the consent surface itself or delegate that surface to a separately operated service. Connection: A single user-authorized relationship between one agent and one resource application, identified by its own connection identifier and carrying its own scopes, duration, ceilings, and audit trail. Connection credential: The one-time credential the user receives at the end of a grant and delivers to the agent, exchangeable exactly once for an access token. Declared purpose: Text supplied by the resource application stating why access is being requested, shown to the user before approval and recorded with the grant. User intent: Text supplied by the user, in the user's own words, stating what the user wants the agent to do, recorded with the grant alongside the declared purpose. 3. The Gap: Automated Credential Delivery The framework's authorization model (Section 10 of [KLRC]) correctly identifies that agents act on behalf of users, systems, or on their own behalf. For user-delegated authorization, Section 10.4.1 of [KLRC] ("User Delegates Authorization") specifies that the agent obtains an access token using the OAuth Authorization Code Grant. This flow involves a redirect-based exchange where the user authenticates and approves access, and the token is delivered to the application via an automated redirect URI. Section 10.7 of [KLRC] acknowledges the limitation directly: Emerson Expires 29 April 2027 [Page 4] Internet-Draft User-Mediated Credential Delivery October 2026 "Additional specification or design work may be needed to define how out-of-band interactions with the User occur at different stages of execution. CIBA itself only accounts for client initiation, which doesn't map well to cases that envision the need for User confirmation to occur mid-execution." This is precise. CIBA [CIBA] is reactive: the agent initiates, the user confirms. The user evaluates a request they didn't frame, with context they may not fully understand, under time pressure. A compromised agent can frame the CIBA request to manipulate approval. The deeper issue is that all authorization flows in the framework share a common assumption: credentials flow through automated channels controlled by the requesting application or agent platform. The redirect URI in OAuth Authorization Code, the backchannel in CIBA, and the token exchange in cross-domain chaining (Section 10.6 of [KLRC]) are all automated delivery mechanisms where the user has no visibility into or control over how the credential reaches the agent. Section 10.1 of [KLRC] places the translation of an agent's mission into authorization requirements in a planning step before the agent requests authorization, and leaves that translation out of scope. User-mediated delivery places that translation with the user: the user authors the grant and the mission text travels with it as evidence (Section 4.4). Section 10.4.1 of [KLRC] recommends that users be authenticated with phishing-resistant mechanisms such as a passkey. User-mediated delivery builds on that recommendation: the same user-verified authenticator can sign a commitment to the exact grant the user is making, producing evidence that outlives the session. As AI models increase in capability, some providers are introducing model-level safeguards and tiered access controls that restrict certain high-risk behaviors. These mechanisms operate at the model layer. They do not, and cannot, define or enforce what an agent is authorized to do within a specific application's data and APIs. Even with such safeguards in place, resource applications require their own authorization layer, one that is user-mediated, scoped to the application's own permission model, and revocable by the user. 4. User-Mediated Credential Delivery User-mediated credential delivery addresses this gap by placing the authorization decision and the credential delivery in the user's trusted context, a browser or mobile interface the user controls, separate from the agent's execution context. Emerson Expires 29 April 2027 [Page 5] Internet-Draft User-Mediated Credential Delivery October 2026 The flow operates as follows: 1. The user authenticates with the resource application through normal application login (OAuth, SSO, or native authentication). 2. The user navigates to a connection management interface within the resource application, or to a consent surface opened on the application's behalf from within that signed-in session. This interface presents available permission scopes organized by the application's own role and access model, limited to a scope ceiling the application computes for that user. It may also present the application's declared purpose for the request. 3. The user authors the grant. The user explicitly chooses what the agent can access (e.g., read workout data, create meal plans, view analytics), for how long (e.g., 24 hours, 7 days, 30 days, until revoked), and optionally how much (per-period call ceilings for groups of resources). The user may record their intent in their own words. If the user already holds active grants for the same application, the interface presents them for review, with the choice to revoke any of them or knowingly keep them alongside the new grant. The scope selection occurs in the user's authenticated session, not in a redirect flow initiated by the agent. 4. Optionally, the user completes a presence ceremony. Where the application requires it, a user-verified authenticator (platform biometric or security key) signs a commitment to the exact grant parameters: scopes, duration, ceilings, declared purpose, and user intent. The signed assertion, the public key, and the commitment preimage are retained as consent evidence (Section 4.4). 5. The resource application generates a connection credential. This credential is a high-entropy, time-limited token that encodes the user's authorization decisions and the location of the exchange endpoint. The credential is displayed to the user exactly once and is not stored in plaintext by the resource application. Emerson Expires 29 April 2027 [Page 6] Internet-Draft User-Mediated Credential Delivery October 2026 6. The user delivers the credential to their agent. The user copies the credential and provides it to their AI agent through whatever interface they use to communicate with the agent (chat, voice, or a configuration file). This is the critical step: the credential delivery occurs through a channel the user controls, not through an automated redirect or backchannel that the agent or its platform controls. In-session display with copy to the clipboard is the recommended default; delivery into the agent's configuration channel preserves the same property for deployments that do not want the model to observe even the short-lived credential. 7. The agent exchanges the credential for a scoped access token. Because the credential is self-describing, the agent determines the exchange endpoint from the credential itself, with no preconfigured knowledge of the application, and presents the connection credential to that endpoint. The exchange validates the credential, verifies it has not expired or been redeemed, and returns a scoped access token along with operational metadata describing the authorized endpoints, methods, request schemas, and any ceilings the user set. The access token is not renewable by the agent: there is no refresh path, and continuing past a chosen duration takes a new user-mediated grant. 8. The agent operates within the granted scopes. Every subsequent API call by the agent is validated through mandatory introspection [RFC7662], which enforces the granted scopes and ceilings and logs the access for audit purposes, together with the declared purpose and user intent recorded on the connection. The application may mark particular scopes as requiring a fresh human confirmation for each use (Section 4.3). 9. The user can revoke at any time. The connection management interface shows all active agent connections with their scopes, duration, and last activity. The user can revoke any connection instantly. Revocation takes effect at the agent's next introspected request, and any per-action confirmation that was pending at the moment of revocation can no longer be consumed. 4.1. Structural Defense Against Prompt Injection The authorization decision occurs outside the agent's execution context. A malicious instruction injected into the agent's context, via prompt injection, tool poisoning, or compromised system prompts, cannot trigger a new authorization grant. The user must independently navigate to the connection interface, authenticate, select scopes, and deliver the credential. There is no programmatic path from "injected prompt" to "escalated permissions." Emerson Expires 29 April 2027 [Page 7] Internet-Draft User-Mediated Credential Delivery October 2026 This is a structural defense against prompt injection at the authorization layer. It does not prevent prompt injection itself, but it ensures that a compromised agent cannot obtain additional permissions beyond what the user explicitly granted before the compromise occurred. 4.2. Step-Up Authorization When an agent attempts an operation requiring a scope it was not granted, the system returns the specific missing scope in the error response. The agent can communicate this to the user and request renewed authorization. The user decides whether to grant the additional scope through a new user-mediated flow, not through a CIBA push notification initiated by the agent. A deployment may require the presence ceremony of step 4 whenever a new grant would exceed what the user's active connections already allow, so that widening an agent's reach takes a human touch. 4.3. Per-Action Confirmation Some actions should not run on a standing grant alone, such as sending money, deleting records, or emailing a customer list. A resource application may mark a scope as confirm-each-time. When an agent's request reaches such a scope, introspection does not grant the call; it stages a pending confirmation that identifies the exact request by digest, and the user confirms exactly that request, with a user-verified authenticator, in their own context. The agent then retries with the resulting attestation identifier, and the introspection response names the confirmation it consumed. The grant does not change and the agent keeps its token; it simply cannot complete that one call until the human has confirmed it. The user can also decline, and a decline is final for that staged request. Section 10.7 of [KLRC] states that confirmation solicited inside an agent framework does not by itself constitute authorization, that the agent must not treat local UI confirmation as sufficient, and that such confirmation must be tied to a verifiable authorization grant. Per-action confirmation satisfies that requirement by construction: the confirmation is produced outside the agent's execution context, commits to the request digest, is verified server-side at introspection, and is recorded against the connection whose grant the user authored. It yields what Section 2 of [CHEN-UC] calls Execution Layer Evidence, a record of the user's explicit consent to the concrete parameters of one action, and it is the "pause" that Section 6 of [CHEN-UC] finds missing, resolved in the user's context rather than through a channel the agent controls. Emerson Expires 29 April 2027 [Page 8] Internet-Draft User-Mediated Credential Delivery October 2026 4.4. Recording Intent Without Interpreting It [CHEN-UC] describes the authorization context gap: at the moment of consent, neither the user nor the authorization server knows the high-level intention under which the agent is acting. [INTENT] proposes to close that gap with a signed credential carrying the user's intent, which an authorization server interprets, by its own policy, into narrowly scoped access tokens. User-mediated delivery closes the same gap at grant time without introducing an interpreter. Two texts are recorded with every grant: the application's declared purpose (why the application is asking) and the user's intent (what the user wants done, in the user's own words). Both are shown at consent, both are signed into the consent commitment when a presence ceremony runs, and both travel with the connection into every introspection record, audit row, grant and revocation event, and alert. Neither text is an input to a policy engine. The permissions are exactly the scopes, duration, and ceilings the user selected; the recorded texts are evidence and review context. Three consequences follow. First, the question of who issues the intent credential and what it attests has a direct answer: the consent surface, operating in the user's context, attests that at a given time a user-verified authenticator signed a commitment to these exact grant parameters, including the two recorded texts. Second, there is no semantic translation step for a compromised or careless component to get wrong, because no component translates. Third, behavior that drifts from the recorded purpose can be detected deterministically against the connection's own history and flagged for a human to review, but such a signal is not acted on automatically; the human decides judgment calls, and only hard numeric thresholds the user set can revoke on their own. Structured constraints in the style of [RFC9396] and recorded natural-language intent are complementary. This document records the natural-language texts as evidence; the enforceable boundary is the structured grant. The user-authored call ceilings of step 3 are a bounded capability in the sense of Section 5.1 of [CHEN-UC], limited to counts: the user grants a budget of calls per resource group, the ceiling is signed into the consent commitment, and introspection validates each call against it. 5. Self-Describing Connection Credentials A connection credential generated through user-mediated delivery may be self-describing: the credential itself encodes the information the agent needs to complete the exchange. Emerson Expires 29 April 2027 [Page 9] Internet-Draft User-Mediated Credential Delivery October 2026 In one implementation, the credential format is: [prefix]_[base64url(exchange_endpoint_url)].[secret] The agent parses the credential by splitting on the delimiter, decoding the first segment to obtain the exchange endpoint URL, and presenting the full credential to that endpoint. The agent requires no preconfigured knowledge of the resource application, its API endpoints, or its authentication infrastructure. The credential tells the agent where to go. This eliminates the cold-start problem for agent-to-application connections. An agent receiving a connection credential from a user for an application it has not interacted with before can immediately determine where to exchange the credential and begin operating. This complements the OAuth discovery mechanisms described in Section 10.10 of [KLRC]. Those mechanisms address server-level discovery (what does this authorization server support?). Self- describing credentials address connection-level discovery (where does this specific user-granted credential need to go?). 6. Caller-Identity Consent Differentiation As AI agents become pervasive, resource applications will serve requests from multiple distinct classes of callers through the same API endpoints: interactive human sessions, the application's own internal AI processes (recommendation engines, analytics, coaching features), and external user-delegated AI agents. Each caller class presents different trust characteristics, operates under different user expectations, and requires independent consent evaluation. A user who shares their data with a colleague (a human) may not want the platform's built-in AI to analyze that same data, or they may permit the platform's AI but deny external agents. Each decision is independent. User-mediated delivery enables a consent differentiation mechanism at the resource application layer: 1. The resource application determines the caller identity class from structural characteristics of the authentication token, such as token format prefix, signing algorithm, issuer claim, or session context. The determination is based on token-derived characteristics, not on user-provided identifiers or request content. The requestor cannot self-select its caller identity class. Emerson Expires 29 April 2027 [Page 10] Internet-Draft User-Mediated Credential Delivery October 2026 2. The application routes the request to an isolated consent evaluation path corresponding to the determined caller class. Each path enforces consent requirements independently configurable by the data owner. 3. Consent granted for one caller class does not authorize access by another. No consent path evaluates or inherits preferences from any other caller class. 7. Discovery-by-Introspection Section 10.10 of [KLRC] describes OAuth discovery mechanisms for dynamic environments. These mechanisms address infrastructure-level discovery: what servers exist, what grant types they support, how resources are protected. User-mediated delivery enables a complementary discovery mechanism that operates at the connection level: discovery-by-introspection. When an agent exchanges a connection credential or introspects an existing access token, the response includes scoped operational metadata: * Application identity: The name and API base URL of the resource application. * Filtered endpoint map: Only the API endpoints the agent is authorized to access based on its granted scopes. Endpoints requiring scopes not in the credential are excluded. * Field-level request body schemas: For each authorized endpoint that accepts a request body, the required fields, optional fields, data types, and descriptions. This metadata is execution-enabling rather than merely descriptive. The agent can construct valid API requests directly from the discovery response without consulting external documentation, developer portals, or API reference materials. Different agents with different authorized scopes for the same application receive different filtered metadata. An agent authorized with read-only scopes sees only read endpoints. An agent with read and write scopes sees both. Each agent discovers only the operations it is permitted to perform. Emerson Expires 29 April 2027 [Page 11] Internet-Draft User-Mediated Credential Delivery October 2026 8. Composition with Grant-Layer Mechanisms User-mediated delivery is a property of how the first credential reaches the agent and who authors the grant. It is not an alternative to the mechanisms that describe or protect the authority once issued, and it composes with them. * Sender-constrained tokens ([RFC9449], [RFC8705]) prove who holds a token at use time and shut down theft and replay. As Section 5.2 of [CHEN-UC] observes, they say nothing about the user's consent to the action or about the step before issuance. Nothing in this document requires bearer semantics for the exchanged access token; it may be sender-constrained. * Rich Authorization Requests ([RFC9396]) give the grant structure. User-mediated delivery is about where the values come from: the user, in their own session, rather than a client's request. * Transaction tokens and token exchange (Sections 10.5 and 10.6 of [KLRC]) carry authority through internal call chains and across domains after the first hop. This primitive covers the first hop, user to agent, where the human authority enters the system, and leaves downstream delegation to those mechanisms. * Policy languages express what is permitted. A deployment may generate its scope-selection interface from a policy without changing anything in this document. 9. Relationship to the Use-Case Analysis [CHEN-UC] is a catalogue of agent authorization use cases and gaps discussed in the OAuth working group. This section states, in that document's own terms, which of its gaps user-mediated delivery addresses and how. Authorization context gap (Section 3.1 of [CHEN-UC]): Addressed at grant time by recording the declared purpose and user intent with the grant and carrying both into every later record (Section 4.4). The consent prompt the user sees is the one the user is framing, not a generic prompt pushed days later. First connection with no authorization front channel (Section 4.1.6): The use case asks for front-channel-free Emerson Expires 29 April 2027 [Page 12] Internet-Draft User-Mediated Credential Delivery October 2026 bootstrapping, a user-authored grant, and a scoped, revocable credential that replaces a static API key. Those three requirements are the flow in this document: the grant begins in the user's signed-in session with the resource application, the credential is delivered by the user, and the agent needs only to receive the credential and read the exchange endpoint from it. First connection with a front channel the client does not use (Section 4.1.7): Of that use case's needs, this document speaks to one: that the consent step stays with the user and out of reach of the agent's own automation (Section 4.3 and the invariant in Section 11). It does not address terminal disposition or a presence signal from the client to the resource server. Pre-approval versus continuous dialogue (Section 6, gap 1): User- mediated delivery is deliberately pre-approval: the user defines the boundary before the agent acts. The continuous part is the step-up loop (the agent reports the missing scope, the user decides in a new user-mediated flow) and per-action confirmation (Section 4.3). No standardized interactive channel (Section 6, gap 2): Per-action confirmation is such a channel, resolved in the user's context. The agent cannot frame or complete it. Insufficient revocation (Section 6, gap 4, and Section 3.3): Because every grant is its own connection, revocation is a connection- level operation rather than a token-level one, and with mandatory introspection it is a server-side state change rather than a call per token. Revoking one user's agent, every connection one user granted, or every connection carrying one agent label are then selections over connections, and token revocation in the sense of [RFC7009] becomes a consequence rather than the primitive. This document does not standardize a revocation API; implementation experience is reported in Section 13. Grant-layer versus execution-layer evidence (Section 6, gap 6): The consent ceremony produces grant-layer evidence (a user-verified signature over the exact grant), and per-action confirmation produces execution-layer evidence (a user-verified confirmation that commits to a specific request digest). Bounded capabilities (Section 5.1): User-authored call ceilings, signed into the grant and validated at introspection, are a count- limited instance of the bounded capability that section describes. Emerson Expires 29 April 2027 [Page 13] Internet-Draft User-Mediated Credential Delivery October 2026 10. Strengthening the Framework User-mediated delivery does not replace the framework's processes. It strengthens the foundation they depend on. Agent Credentials (Section 7 of [KLRC]): The framework calls static API keys an antipattern for agent identity. For user-delegated access the same properties apply, and the connection credential has the opposite lifecycle: one-time, minutes-lived, scoped to one user's selection, stored only as a hash, exchangeable exactly once. Agent Credential Provisioning (Section 8 of [KLRC]): The framework describes automated runtime provisioning through orchestration systems. For agent operations that affect user data, user- mediated delivery adds a deliberate human authorization step. The agent's infrastructure credentials (WIMSE/SPIFFE) authenticate the agent. The user's connection credential authorizes access to the user's data. Two layers, each controlled by the appropriate entity. Transport Layer Authentication (Section 9.1 of [KLRC]): mTLS authenticates the connection but not the intent. A self- describing connection credential tells the agent where to connect and what it can do there. Application Layer Authentication (Section 9.2 of [KLRC]): WPTs and HTTP Message Signatures prove agent identity and key possession. They do not prove user authorization intent. An access token issued through user-mediated delivery carries both identity and the user's explicit scope selections. User Delegates Authorization (Section 10.4.1 of [KLRC]): The Authorization Code Grant uses a redirect URI, an automated channel. User-mediated delivery eliminates the redirect. The credential is displayed to the user and manually delivered to the agent. There is no automated channel to intercept, redirect, or manipulate through prompt injection. Agent Obtains Own Authorization (Section 10.4.2 of [KLRC]): Client Credentials are appropriate for autonomous agent operations. For accessing user data, user-mediated delivery separates "agent authenticates itself" from "agent accesses user data." Risk Reduction with Transaction Tokens (Section 10.5 of [KLRC]): Transaction tokens reduce risk within a Emerson Expires 29 April 2027 [Page 14] Internet-Draft User-Mediated Credential Delivery October 2026 service's internal microservice chain. User-mediated delivery strengthens the foundation: the initial access token that feeds the transaction token chain was issued from a verified human authorization, not an automated redirect. Cross-Domain Access (Section 10.6 of [KLRC]): The draft describes automated token chaining across authorization domains. User- mediated delivery replaces chaining with independent per- application connections. Each connection is independently scoped, independently revocable, and independently authorized by the user. Human in the Loop (Section 10.7 of [KLRC]): CIBA is reactive: the agent initiates, the user confirms under pressure. User-mediated delivery is proactive: the user defines boundaries before the agent acts. If the agent exceeds its scopes, the system returns the specific missing scope, enabling the agent to request renewed authorization from the user through a new user-mediated flow. Where a single action warrants a human decision mid-execution, per-action confirmation provides it in the user's context and ties it to the grant, as that section requires. Tool-to-Service Access (Section 10.8 of [KLRC]): The draft correctly identifies forwarding access tokens as an anti-pattern. With user-mediated delivery, each tool or service connection is independently authorized. There are no access tokens to forward because each connection carries its own scoped authorization. Privacy Considerations (Section 10.9 of [KLRC]): The draft recommends opaque tokens with introspection for claim minimization. User-mediated delivery with mandatory introspection implements this: the access token is validated server-side on every call, no sensitive claims need to be embedded in the token itself. Discovery in Dynamic Environments (Section 10.10 of [KLRC]): The draft's OAuth discovery describes infrastructure capabilities. Discovery-by-introspection describes agent-specific operational capabilities filtered to the agent's granted scopes. Agent Monitoring, Observability, and Remediation (Section 11 of [KLRC]): That section requires durable, tamper-evident audit records that capture the agent, the delegated subject, the resource, the action and decision, a timestamp and correlation identifier, and remediation or revocation events. With mandatory introspection, every agent API call produces such a record, starting from a deliberate human authorization decision and carrying the declared purpose and user intent on the connection. Grant and revocation events are recorded durably and survive the grant's expiry or Emerson Expires 29 April 2027 [Page 15] Internet-Draft User-Mediated Credential Delivery October 2026 revocation. Where the trail is hash-chained, an auditor holding an export can detect an altered, deleted, or reordered row without trusting the operator. 11. Security Considerations User-mediated credential delivery shifts the credential delivery channel from automated (redirect URI, backchannel) to user- controlled. This introduces a structural defense against prompt injection at the authorization layer but does not prevent prompt injection itself. The connection credential is a bearer token during its exchange window. Implementations SHOULD limit the exchange window (e.g., fifteen minutes) and MUST enforce one-time use. Implementations SHOULD make the credential unavailable for further redemption on the first redemption attempt that presents it, whether or not validation succeeds, so that a racing or replayed attempt cannot win. The credential MUST NOT be stored in plaintext after generation. The human hop has its own risks, and this document does not pretend otherwise. Three properties limit them: the credential is one-time and dies in minutes; it carries only the scopes the user just selected, so the blast radius is the grant, not the account; and the grant is revocable per connection with an audit trail. The requirement this document states is the exclusion of any agent- addressable delivery path; the delivery channels listed are illustrative and differ in strength. In-session display with copy to the clipboard is the recommended default, and deployments MAY disable weaker channels. Section 8 of [KLRC] requires that the large language model have no access to the agent's credentials. User-mediated delivery is compatible with that requirement: the artifact the user handles is an exchange-only credential that is worthless after one use and expires in minutes, and the access token returned by the exchange MUST be held by the agent's runtime and MUST NOT be placed in model context. Deployments that want the model to observe not even the short-lived credential can deliver it through the agent's configuration channel, which preserves the user-mediated property. The self-describing credential format encodes the exchange endpoint URL. Implementations MUST validate that the decoded URL points to a legitimate exchange endpoint to prevent credential phishing. The value of the presence ceremony and of per-action confirmation rests on one invariant: an automated process MUST NOT be able to complete the user-verification step. An agent, including the agent Emerson Expires 29 April 2027 [Page 16] Internet-Draft User-Mediated Credential Delivery October 2026 the grant is for, must not be in a position to satisfy the authenticator prompt on the user's behalf. Implementations SHOULD stage the step and hand it to the human, and SHOULD treat any path by which software could complete it as a vulnerability. Tying the approval to what the user was actually shown remains an open problem; a confirmation rendered on a device where the agent controls the input proves nothing. Recorded purpose and intent texts are evidence, not policy. Implementations MUST NOT widen a grant on the basis of free text, and SHOULD treat any automated interpretation of such text as advisory input for human review. Revocation SHOULD be enforced at the next introspected request, and a per-action confirmation pending at the moment of revocation SHOULD become permanently non-consumable. Where consent and audit trails are exported for third-party verification, implementations SHOULD make the chain verifiable offline with published tooling, and SHOULD describe the property as tamper-evident, which is what a hash chain provides. 12. IANA Considerations This document has no IANA actions. 13. Implementation Status This section records the status of a known implementation of the methods described in this document, following [RFC7942]. It is to be removed before publication as an RFC. The author operates a hosted service, AgentAdmit (https://agentadmit.com), implementing user-mediated credential delivery as described here: a consent surface opened from the resource application's signed-in session, on which the user selects scopes and a duration (one hour to thirty days, or until revoked), optionally sets call ceilings, records intent in their own words alongside the application's declared purpose, reviews existing grants, optionally completes a user-verified presence ceremony at an evidence tier the application selects (synced passkeys that are user- verified but unattested, or directly attested authenticators validated against FIDO metadata), and receives a one-time connection credential; self-describing credentials; exchange for a scoped access token with operational metadata; mandatory per-call introspection; step-up on missing scopes; confirm-each-time scopes with per-request confirmation and decline; per-connection revocation, plus revocation of every connection one user granted or every connection carrying one Emerson Expires 29 April 2027 [Page 17] Internet-Draft User-Mediated Credential Delivery October 2026 agent label in one server-side operation; and hash-chained consent and audit exports. Documentation is published at https://agentadmit.com/docs. The service is proprietary. Public, MIT-licensed reference verifiers for the exported chains and for consent evidence are at https://github.com/PhoenixCo-Founder/ agentadmit-verifiers, and a demonstration MCP server implementing the flow, including per-call confirmation, is at https://github.com/ PhoenixCo-Founder/agentadmit-mcp-showcase. The study cited in the introduction, with its aggregate data and scripts, is at https://github.com/PhoenixCo-Founder/mcp-user-controllability-study. The implementation runs in production infrastructure the author operates, including a consumer fitness application, TrainerTracer (https://trainertracer.com), on the web and in its iOS and Android releases, where users grant, review, and revoke agent connections and confirm individual agent actions. 14. IPR Notice The methods described in this document are the subject of a pending patent application. An IPR disclosure is on file with the IETF in accordance with BCP 79 (https://datatracker.ietf.org/ipr/7378/). 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15.2. Informative References [CHEN-UC] Chen, M., Su, L., and P. C. Liu, "Agent Authorization use cases and gap analysis", Work in Progress, Internet-Draft, draft-chen-oauth-agent-authz-use-cases-04, 12 October 2026, . Emerson Expires 29 April 2027 [Page 18] Internet-Draft User-Mediated Credential Delivery October 2026 [CIBA] Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. Campbell, "OpenID Connect Client-Initiated Backchannel Authentication Flow", 1 September 2021, . [INTENT] Chen, M., Su, L., and P. C. Liu, "The Intent Token - A Credential for Delegated User Intent", Work in Progress, Internet-Draft, draft-chen-oauth-agent-intent-token-00, 19 October 2026, . [KLRC] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-03, 9 September 2026, . [MCP-STUDY] Emerson, C., "Can Users See, Scope, and Revoke What AI Agents Hold? A Study of 1,634 MCP Servers", 30 September 2026, . [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . Emerson Expires 29 April 2027 [Page 19] Internet-Draft User-Mediated Credential Delivery October 2026 [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . Changes Since -00 * Updated all references to [KLRC] from draft-klrc-aiagent-auth-02 to -03, which renumbered the cited sections (for example, Section 9.7 is now Section 10.7), and added its mission, static- key, confirmation, and audit requirements where they bear on this document. * Added [CHEN-UC], [INTENT], [MCP-STUDY], [RFC7009], [RFC7942], [RFC8705], [RFC9396], and [RFC9449] as informative references. * Added a definitions list, a section relating the methods to the use-case gap analysis, a section on recording purpose and intent as evidence without interpretation, and a section on composition with grant-layer mechanisms. * Expanded the delivery flow with the scope ceiling, call ceilings, existing-grant review, the optional presence ceremony, the recommended delivery channel, non-renewable access tokens, per- action confirmation, and revocation closure. * Added security considerations on redemption, the human hop, model access to credentials, the user-verification invariant, free-text evidence, revocation, and verifiable trails. * Added an Implementation Status section per [RFC7942] and updated the IPR notice with the disclosure on file. Acknowledgements The author acknowledges the contributions of the authors of [KLRC] in establishing the foundation for AI agent authentication and authorization standards, and of the authors of [CHEN-UC] for the use- case and gap catalogue that this revision draws on. The framework's identification of the human-in-the-loop limitation directly motivated this work. Author's Address Christopher Emerson AgentAdmit United States of America Email: christopher@agentadmit.com Emerson Expires 29 April 2027 [Page 20] Internet-Draft User-Mediated Credential Delivery October 2026 URI: https://agentadmit.com Emerson Expires 29 April 2027 [Page 21]