User-Mediated Credential Delivery as a Complementary Authorization Primitive for AI Agents

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

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

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

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

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

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

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

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

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

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

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