User-Mediated Credential Delivery as a Complementary Authorization Primitive for AI Agents
draft-emerson-oauth-user-mediated-delivery-00

Network Working Group                                         C. Emerson
Internet-Draft                                                AgentAdmit
Intended status: Informational                               1 July 2026
Expires: 2 January 2027

   User-Mediated Credential Delivery as a Complementary Authorization
                        Primitive for AI Agents
             draft-emerson-oauth-user-mediated-delivery-00

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 9.7
   of [KLRC] and strengthen the authorization foundation that the IETF
   AI Agent Authentication and Authorization framework depends on.

   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 2 January 2027.

Emerson                  Expires 2 January 2027                 [Page 1]
Internet-Draft      User-Mediated Credential Delivery          July 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  The Gap: Automated Credential Delivery  . . . . . . . . . . .   3
   4.  User-Mediated Credential Delivery . . . . . . . . . . . . . .   4
     4.1.  Structural Defense Against Prompt Injection . . . . . . .   5
     4.2.  Step-Up Authorization . . . . . . . . . . . . . . . . . .   6
   5.  Self-Describing Connection Credentials  . . . . . . . . . . .   6
   6.  Caller-Identity Consent Differentiation . . . . . . . . . . .   7
   7.  Discovery-by-Introspection  . . . . . . . . . . . . . . . . .   7
   8.  Strengthening the Framework . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. IPR Notice  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     12.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Operational Deployment  . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

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 4 of [KLRC]), the layered stack from identifiers through
   compliance, and the integration of WIMSE, SPIFFE, and OAuth 2.0
   provide a strong foundation.

Emerson                  Expires 2 January 2027                 [Page 2]
Internet-Draft      User-Mediated Credential Delivery          July 2026

   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 9.4.1 of [KLRC]), Client Credentials (Section 9.4.2 of
   [KLRC]), cross-domain chaining (Section 9.6 of [KLRC]), CIBA-based
   human-in-the-loop (Section 9.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.

   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.

3.  The Gap: Automated Credential Delivery

   The framework's authorization model (Section 9 of [KLRC]) correctly
   identifies that agents act on behalf of users, systems, or on their
   own behalf.  For user-delegated authorization, Section 9.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 9.7 of [KLRC] acknowledges the limitation directly:

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

Emerson                  Expires 2 January 2027                 [Page 3]
Internet-Draft      User-Mediated Credential Delivery          July 2026

   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 9.6 of
   [KLRC]) are all automated delivery mechanisms where the user has no
   visibility into or control over how the credential reaches the agent.

   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.

   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.  This interface presents available
       permission scopes organized by the application's own role and
       access model.

   3.  The user selects scopes and duration.  The user explicitly
       chooses what the agent can access (e.g., read workout data,
       create meal plans, view analytics) and for how long (e.g., 24
       hours, 7 days, until revoked).  The scope selection occurs in the
       user's authenticated session, not in a redirect flow initiated by
       the agent.

Emerson                  Expires 2 January 2027                 [Page 4]
Internet-Draft      User-Mediated Credential Delivery          July 2026

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

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

   6.  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 used, and
       returns a scoped access token along with operational metadata
       describing the authorized endpoints, methods, and request
       schemas.

   7.  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
       logs the access for audit purposes.

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

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 2 January 2027                 [Page 5]
Internet-Draft      User-Mediated Credential Delivery          July 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.

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.

   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 never interacted with can immediately
   determine where to exchange the credential and begin operating.

   This complements the OAuth discovery mechanisms described in
   Section 9.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?).

Emerson                  Expires 2 January 2027                 [Page 6]
Internet-Draft      User-Mediated Credential Delivery          July 2026

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.

   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 9.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:

Emerson                  Expires 2 January 2027                 [Page 7]
Internet-Draft      User-Mediated Credential Delivery          July 2026

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

8.  Strengthening the Framework

   User-mediated delivery does not replace the framework's processes.
   It strengthens the foundation they depend on.

   Agent Credential Provisioning (Section 7 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 8.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 8.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 9.4.1 of [KLRC]):  The

Emerson                  Expires 2 January 2027                 [Page 8]
Internet-Draft      User-Mediated Credential Delivery          July 2026

      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 9.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 9.5 of [KLRC]):  Transaction tokens reduce risk within a
      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 9.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 9.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.

   Tool-to-Service Access (Section 9.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 9.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 9.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.

Emerson                  Expires 2 January 2027                 [Page 9]
Internet-Draft      User-Mediated Credential Delivery          July 2026

   Agent Monitoring, Observability, and Remediation (Section 10 of
   [KLRC]):  With mandatory introspection, every agent API call is
      logged with: which agent, which user authorized it, which scopes
      were exercised, which resource was accessed, and the response
      status.  The audit trail starts from a deliberate human
      authorization decision.

9.  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 enforce one-time use.  The credential MUST NOT
   be stored in plaintext after generation.

   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.

10.  IANA Considerations

   This document has no IANA actions.

11.  IPR Notice

   The methods described in this document are the subject of a pending
   patent application.  The author will file an IPR disclosure with the
   IETF in accordance with BCP 79.

12.  References

12.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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

12.2.  Informative References

Emerson                  Expires 2 January 2027                [Page 10]
Internet-Draft      User-Mediated Credential Delivery          July 2026

   [CIBA]     Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B.
              Campbell, "OpenID Connect Client-Initiated Backchannel
              Authentication Flow", 1 September 2021,
              <https://openid.net/specs/openid-client-initiated-
              backchannel-authentication-core-1_0.html>.

   [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-02, 1 June 2026,
              <https://datatracker.ietf.org/doc/draft-klrc-aiagent-
              auth/>.

   [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
              RFC 7662, DOI 10.17487/RFC7662, October 2015,
              <https://www.rfc-editor.org/rfc/rfc7662>.

Acknowledgements

   The author acknowledges the contributions of the authors of [KLRC] in
   establishing the foundation for AI agent authentication and
   authorization standards.  The framework's identification of the
   human-in-the-loop limitation in Section 9.7 directly motivated this
   work.

Operational Deployment

   A reference implementation of the authorization infrastructure
   described in this document, including exchange endpoints, mandatory
   introspection, scoped token issuance, and connection credential
   handling, is deployed and operational at https://agentadmit.com.

Author's Address

   Christopher Emerson
   AgentAdmit
   United States of America
   Email: christopher@agentadmit.com
   URI:   https://agentadmit.com

Emerson                  Expires 2 January 2027                [Page 11]