]> AgentAdmit

United States of America christopher@agentadmit.com https://agentadmit.com

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 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 and to the intent credential proposed in , states how it composes with grant-layer mechanisms, and reports implementation status. The methods described in this document are patent pending.

Introduction 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 ), 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 ), Client Credentials (Section 10.4.2 of ), cross-domain chaining (Section 10.6 of ), CIBA-based human-in-the-loop (Section 10.7 of ), 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. catalogues the same family of problems from the use-case side. Its authorization context gap (Section 3.1 of ), its summary gaps on interactive consent, revocation, and execution-layer evidence (Section 6 of ), and its first-connection use case with no authorization front channel (Section 4.1.6 of ) describe situations in which the user, not the agent, needs to be the party that frames and delivers authorization. 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 . Section 7 of 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. 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.

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

The Gap: Automated Credential Delivery The framework's authorization model (Section 10 of ) correctly identifies that agents act on behalf of users, systems, or on their own behalf. For user-delegated authorization, Section 10.4.1 of ("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 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 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 ) 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 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 10.4.1 of 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.

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, 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 ().
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.
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 , 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 ().
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.

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

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.

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 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 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 finds missing, resolved in the user's context rather than through a channel the agent controls.

Recording Intent Without Interpreting It 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. 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 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 , 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.

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

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.

Discovery-by-Introspection Section 10.10 of 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.

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 (, ) prove who holds a token at use time and shut down theft and replay. As Section 5.2 of 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 () 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 ) 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.

Relationship to the Use-Case Analysis 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 ):

Addressed at grant time by recording the declared purpose and user intent with the grant and carrying both into every later record (). 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 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 ( and the invariant in ). 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 ().

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 becomes a consequence rather than the primitive. This document does not standardize a revocation API; implementation experience is reported in .

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.

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

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

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

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

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

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

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

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 10.6 of ):

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

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

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

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

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

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 revocation. Where the trail is hash-chained, an auditor holding an export can detect an altered, deleted, or reordered row without trusting the operator.

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

IANA Considerations This document has no IANA actions.

Implementation Status This section records the status of a known implementation of the methods described in this document, following . 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 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.

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/).

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

Changes Since -00

• Updated all references to 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 , , , , , , , and 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 and updated the IPR notice with the disclosure on file.

Acknowledgements The author acknowledges the contributions of the authors of in establishing the foundation for AI agent authentication and authorization standards, and of the authors of 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.