Agent Action Confirmation Protocol (AACP)
draft-liu-agent-action-confirmation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Meihui Liu | ||
| Last updated | 2026-11-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-agent-action-confirmation-00
Individual submission M. Liu
Internet-Draft China Mobile
Intended status: Standards Track 2 November 2026
Expires: 6 May 2027
Agent Action Confirmation Protocol (AACP)
draft-liu-agent-action-confirmation-00
Abstract
AI agents invoke operations with side effects: writes to resources,
creation of durable records, financial transactions, and delegated
actions on remote systems. Existing requirement documents in the
agentproto working group establish that such operations require
confirmation by the human user, that this confirmation must occur
outside of LLM prompt inference, and that in multi-agent delegation
the receiving agent must be able to verify that a presented
confirmation actually originated from the user and is not fabricated
by an intermediate agent. No document in the current document set
defines a protocol, message format, or evidence format that satisfies
these requirements. This document defines the Agent Action
Confirmation Protocol (AACP): an action descriptor format derived
from OAuth 2.0 Rich Authorization Requests (RFC 9396), a confirmation
request format, a signed confirmation evidence format, and verifier-
side processing rules with a distinct-outcome failure model. The
design is transport-neutral and profiled here for JSON over HTTP with
JWS signatures; a CBOR/COSE mapping is defined. A requirement
traceability matrix maps each mechanism to its source requirement in
the agentproto document set.
This document is informed by, and positions itself relative to, two
prior individual submissions that addressed user confirmation of
agent actions and have since expired: CHEQ
[I-D.rosenberg-aiproto-cheq] and the Agent Operation Authorization
framework [I-D.liu-agent-operation-authorization]. The differences
are summarized in Section 1.4.
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/.
Liu Expires 6 May 2027 [Page 1]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
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 6 May 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Motivation . . . . . . . . . . . . . . . . 3
1.2. Relationship to agentproto Requirement Documents . . . . 5
1.3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 7
1.4. Relationship to Prior Individual Submissions . . . . . . 8
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 10
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. The Confirmation Service . . . . . . . . . . . . . . . . 11
4.3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Confirmation Flows . . . . . . . . . . . . . . . . . . . 12
5. Action Descriptor . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Rendering Requirements . . . . . . . . . . . . . . . . . 14
5.3. Action Digest Computation . . . . . . . . . . . . . . . . 15
5.4. CDDL Definition . . . . . . . . . . . . . . . . . . . . . 15
6. Confirmation Request . . . . . . . . . . . . . . . . . . . . 15
7. Confirmation Evidence . . . . . . . . . . . . . . . . . . . . 16
7.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Signature and Canonicalization . . . . . . . . . . . . . 17
7.3. Authentication Context . . . . . . . . . . . . . . . . . 18
7.4. Binding Rules . . . . . . . . . . . . . . . . . . . . . . 18
7.5. Lifetime and Freshness . . . . . . . . . . . . . . . . . 19
8. Verification Procedure . . . . . . . . . . . . . . . . . . . 19
Liu Expires 6 May 2027 [Page 2]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
8.1. Verification Steps . . . . . . . . . . . . . . . . . . . 19
8.2. Outcome Matrix and Error Codes . . . . . . . . . . . . . 20
8.3. Replay Prevention . . . . . . . . . . . . . . . . . . . . 22
9. Multi-Agent Confirmation . . . . . . . . . . . . . . . . . . 22
9.1. Delegated Flow . . . . . . . . . . . . . . . . . . . . . 22
9.2. Handoff Chain Binding . . . . . . . . . . . . . . . . . . 22
9.3. Denied, Unobtainable, and Stale Are Different Facts . . . 23
10. API Integration . . . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 24
11.2. Residual Risks . . . . . . . . . . . . . . . . . . . . . 25
11.3. Algorithm Agility . . . . . . . . . . . . . . . . . . . 26
11.4. Key Management . . . . . . . . . . . . . . . . . . . . . 26
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
13.1. Media Types . . . . . . . . . . . . . . . . . . . . . . 27
13.2. Confirmation Outcome Values Registry . . . . . . . . . . 27
13.3. Error Code Allocation . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Complete CDDL Definition . . . . . . . . . . . . . . 31
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 32
B.1. Action Descriptor (flight booking) . . . . . . . . . . . 32
B.2. Confirmation Request . . . . . . . . . . . . . . . . . . 33
B.3. Confirmation Evidence (payload before JCS and signing) . 33
B.4. Denied Evidence . . . . . . . . . . . . . . . . . . . . . 33
B.5. Unobtainable Status . . . . . . . . . . . . . . . . . . . 33
Appendix C. Requirement Traceability Matrix . . . . . . . . . . 33
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction
1.1. Background and Motivation
AI agents are software applications that utilize Large Language
Models (LLMs) to perform tasks, and they invoke operations with side
effects on external systems: creating bookings, updating records,
initiating payments, executing delegated administrative actions. Two
properties of current agent architectures make unconfirmed side-
effecting operations hazardous:
1. Fallible inference. An agent may invoke the wrong operation, or
the right operation with wrong parameters, as a direct
consequence of model error. Read operations are recoverable;
side-effecting operations may not be.
Liu Expires 6 May 2027 [Page 3]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
2. Untrustworthy intermediaries. In multi-agent delegation, a chain
of agents conveys context and instructions between the user and
the agent that ultimately acts. An intermediate agent may
fabricate the claim "the user approved this" — whether through
hallucination or compromise — and nothing in current agent
communication protocols lets the acting agent distinguish a real
user decision from a fabricated one.
The agentproto working group's requirement documents address both
properties but deliberately stop at the requirements level.
[I-D.rosenberg-agentproto-usecases] Section 3.2.3 requires that
confirmation for side-effecting operations happen "programatically,
outside of the LLM prompt inference", that APIs be annotated with
which operations require confirmation, and that the annotation carry
user-visible names and descriptions of the attributes that require
confirmation, together with their mapping into the operation's JSON
payload. Section 3.3.6 extends the requirement to inter-agent
communication: "How can the invoked AI agent trust that the
confirmation actually came from the end user, and is not instead a
hallucination generated by the invoking AI Agent? This will also
require protocol machinery to provider cryptographic assurances."
The security-focused documents in the document set define requirement
models for the evidence that would answer this question, while
explicitly declining to define the evidence format.
[I-D.bu-agentproto-security-principal-binding] separates claims
including "action evidence" (claim C-005) from other security-
relevant claims, and defines row-outcome and dependency-closure rules
so that a verification result cannot be stronger than its inputs.
[I-D.he-agentproto-verifier-evidence] requires that a verification
result report whether a check has been "exercised into its declared
rejecting and unverifiable outcomes"; that document "defines no wire
format, encoding, token, claim vocabulary, test harness, or
registry". [I-D.konda-agentproto-evaluation-state] requires that the
facts "the input was established and evaluated negatively" and "the
input could not be established at all" remain distinct across a
protocol boundary, and notes that its test cases have "a machine-
readable form published separately".
[I-D.wadkins-agentproto-action-determinability] requires that a
claimed agent transition remain "independently determinable after the
original interaction has ended".
This document defines the missing piece: a wire-level protocol and
evidence format that satisfies those requirements. It is
deliberately positioned as a profile-ready building block rather than
a new architecture: AACP defines what must be confirmed, how the
confirmation is bound to the action, and how a verifier processes and
Liu Expires 6 May 2027 [Page 4]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
reports the result. It does not define new transport, discovery, or
agent identity mechanisms, and composes with the candidate transports
under discussion in the working group.
1.2. Relationship to agentproto Requirement Documents
This document takes requirements from, and is intended to be citable
by, the following documents in the working group's document set:
+=================================================+=================+
| Source document |Requirement |
| |taken |
+=================================================+=================+
| [I-D.rosenberg-agentproto-usecases] |Programmatic |
| |confirmation |
| |outside LLM |
| |inference; API |
| |annotation of |
| |confirmation |
| |requirements; |
| |user-visible |
| |attribute |
| |mapping (Sec |
| |3.2.3); |
| |cryptographic |
| |assurance that |
| |confirmation |
| |originates from |
| |the user in |
| |inter-agent |
| |flows (Sec |
| |3.3.6) |
+-------------------------------------------------+-----------------+
| [I-D.bu-agentproto-security-principal-binding] |Claim separation |
| |(C-005 action |
| |evidence, C-007 |
| |evidence |
| |provenance, |
| |C-008 |
| |freshness); row- |
| |outcome |
| |semantics; |
| |failure handling |
| |(C-009) |
+-------------------------------------------------+-----------------+
| [I-D.he-agentproto-verifier-evidence] |Exercise |
| |evidence: a |
| |result must |
Liu Expires 6 May 2027 [Page 5]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
| |report whether |
| |checks have been |
| |exercised into |
| |rejecting and |
| |unverifiable |
| |outcomes |
+-------------------------------------------------+-----------------+
| [I-D.konda-agentproto-evaluation-state] |Evaluation state |
| |preservation: |
| |denied vs |
| |unobtainable vs |
| |stale are |
| |distinct facts |
| |with distinct |
| |protocol |
| |outcomes |
+-------------------------------------------------+-----------------+
| [I-D.wadkins-agentproto-action-determinability] |Post-session |
| |determinability: |
| |evidence remains |
| |verifiable after |
| |sessions, |
| |credentials, and |
| |agent instances |
| |are gone |
+-------------------------------------------------+-----------------+
| [I-D.agentic-ai-usecases-requirements] |CMN-12: a |
| |participant must |
| |be able to |
| |verify that a |
| |change is |
| |authorized at |
| |the time it |
| |happens, and |
| |must be able to |
| |determine |
| |whether a check |
| |failed or could |
| |not be completed |
+-------------------------------------------------+-----------------+
| [I-D.srivastava-agentproto-handoff-context] |Handoff chain: |
| |offers named by |
| |hash (chain |
| |binding of |
| |confirmation to |
| |delegation path) |
+-------------------------------------------------+-----------------+
| [I-D.okutomi-session-bound-agent-identity] |Context |
Liu Expires 6 May 2027 [Page 6]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
| |diversion: |
| |evidence must |
| |not be |
| |acceptable for a |
| |different actor, |
| |task, or |
| |authority |
| |boundary |
+-------------------------------------------------+-----------------+
| [I-D.howe-agentproto-contact-center-usecases] |Cross-channel |
| |confirmation and |
| |dialog |
| |resumption |
| |semantics for |
| |out-of-band |
| |confirmation |
| |(CC3-1, CC3-4) |
+-------------------------------------------------+-----------------+
Table 1
Appendix C contains the full traceability matrix from mechanism to
requirement.
1.3. Scope and Non-Goals
In scope:
* A JSON [RFC8259] action descriptor format, derived from and
aligned with the "authorization_details" structure of OAuth 2.0
Rich Authorization Requests [RFC9396], extended with confirmation-
specific metadata.
* A confirmation request format and a signed confirmation evidence
format, including binding rules, freshness rules, and an
authentication context.
* Verifier-side processing rules with a distinct-outcome failure
model, suitable for enforcement at API gateways and at acting
agents.
* A CBOR [RFC8949] / COSE [RFC9052] mapping.
Out of scope (non-goals):
* Agent discovery, routing, session establishment, or transport
selection. AACP rides on existing or emerging agent communication
protocols and API invocation mechanisms.
Liu Expires 6 May 2027 [Page 7]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
* Agent identity, agent-to-agent authentication, or token issuance.
AACP binds confirmations to actions and users; it presumes agent
authentication is solved by the surrounding protocol, and requires
only that identifiers be nameable.
* How users authenticate to the Confirmation Service. AACP carries
an authentication context describing how the user authenticated,
not the authentication mechanism itself.
* Prompt injection defenses in general. AACP reduces the blast
radius of prompt injection by moving irreversible decisions out of
LLM inference, but does not detect or prevent injection attacks.
* General-purpose audit systems and transparency services. AACP
evidence is designed to be referenceable by such systems (e.g., by
digest), not to replace them.
The scope boundary above is aligned with the agentproto working group
charter [CHARTER]. The charter places "the design of human to agent
user interfaces, client application UX, or the rendering of agent
outputs on end-user devices" and "audit data structures and their
production, validation, or consumption" outside the working group's
scope. AACP addresses neither: its rendering requirements are
constraints on API metadata and on programmatic processing of that
metadata (which fields must be confirmed and how their values are
named for display), not user interface design; and its evidence is an
authorization input, not an audit data structure. The distinct-
outcome signals of Section 8.2 are protocol errors, which the charter
places in scope.
1.4. Relationship to Prior Individual Submissions
Two prior individual Internet-Drafts addressed user confirmation of
agent actions and have since expired without renewal:
CHEQ [I-D.rosenberg-aiproto-cheq] proposed a signed object
memorializing a human decision, with collection outside the LLM,
embeddable in MCP, A2A, and N-ACT. Its core concern — that
hallucinated decisions must not produce unwanted actions, and that a
signature by an identity provider authenticating the user is the
assurance mechanism — is shared by AACP. AACP differs in three ways.
First, CHEQ is transport-embedded but verifier-implicit: it does not
define a verifier-side processing model, so the question of what a
relying party does with a malformed, stale, or redirected CHEQ is
left open; AACP's row-outcome model (Section 8) makes that processing
normative. Second, CHEQ was written before the agentproto document
set existed and therefore does not trace to its requirements; AACP
aligns with the claim separation (C-005, C-007, C-008), row-outcome,
Liu Expires 6 May 2027 [Page 8]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
and dependency-closure models of
[I-D.bu-agentproto-security-principal-binding], the exercise
requirements of [I-D.he-agentproto-verifier-evidence], and the
evaluation-state requirements of
[I-D.konda-agentproto-evaluation-state]. Third, CHEQ couples
confirmation with privacy-protected information collection; AACP
separates concerns and defines only the confirmation exchange.
The Agent Operation Authorization framework
[I-D.liu-agent-operation-authorization] proposed a two-phase JWT
model: an agent_operation_proposal conveyed via OAuth Pushed
Authorization Requests, and an Agent Operation Authorization Token
recording confirmed authorization. Its insight — that a structured
operation proposal, presented to the user through the authorization
server rather than through the agent, prevents unauthorized or
hallucinated actions — is likewise shared. AACP differs in that it
is not bound to the OAuth authorization code/PAR flow: it defines an
independent confirmation exchange that composes with agent-to-agent
delegation (Section 9), where the user is not the OAuth resource
owner vis-a-vis the acting agent, and where the delegated flow's
hallucination problem (Section 3.3.6 of
[I-D.rosenberg-agentproto-usecases]) is not solved by a token issued
to the agent. AACP's evidence is verified at action time against the
operation's parameters (action digest), not presented as a bearer
credential.
The user-mediated credential delivery proposal
[I-D.emerson-oauth-user-mediated-delivery], currently active in the
OAuth working group's problem space, includes per-action confirmation
by introspection with a user-verified authenticator. AACP is
complementary: that work places authorization decisions and
credential delivery in the user's trusted context at the OAuth grant
layer; AACP defines the confirmation object, its binding rules, and
its verification semantics for the agent communication layer, and can
carry evidence produced by such a flow in its auth-context.
2. Terminology
The terms "agent", "user", and "agent communication protocol" are
used as in [I-D.rosenberg-agentproto-usecases].
Acting Agent (AA) The agent that will invoke a side-effecting
operation (an API call or a delegated sub-task) and that must
present evidence that the operation was confirmed. In the
terminology of [I-D.rosenberg-agentproto-usecases], typically the
"invoked agent"; in tool-calling deployments, the agent holding
the tool.
Requesting Agent (RA) The agent in whose dialog with the user the
Liu Expires 6 May 2027 [Page 9]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
confirmation is collected; typically the "invoking agent". In
single-agent flows, RA and AA are the same entity.
Confirming User (U) The human whose decision the evidence records.
Confirmation Service (CS) The component that renders an action
descriptor to the user through a non-LLM programmatic path,
collects the user's decision, and signs the confirmation evidence.
The CS is the trust anchor of this protocol.
Action Descriptor (AD) The typed, self-contained description of the
operation to be confirmed, as defined in Section 5.
Confirmation Request (CR) The message from AA to CS asking for
confirmation of a specific action, as defined in Section 6.
Confirmation Evidence (CE) The signed record of the user's decision,
as defined in Section 7.
Verification The procedure by which a verifier checks a CE against
the operation it accompanies (Section 8).
Row outcome As in [I-D.bu-agentproto-security-principal-binding]:
the verified status of a single claim row after verification
processing, distinct from specification or implementation status.
3. Requirements Language
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD 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.
4. Architecture
4.1. Roles
AACP involves four roles:
U (Confirming User) — CS (Confirmation Service) — AA (Acting Agent) —
[optional RA (Requesting Agent)] — target operation
The Acting Agent constructs the Action Descriptor and the
Confirmation Request. The Confirmation Service renders the
descriptor to the user, obtains the decision, and produces signed
Confirmation Evidence. The Acting Agent (or the API it invokes)
verifies the evidence at action time; any later verifier can re-
verify the evidence after the fact.
Liu Expires 6 May 2027 [Page 10]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
The Confirmation Service is the only role that holds a signature key
in the base protocol. This is a deliberate design decision: it
isolates the trust question "did the user really decide this?" into a
component whose key management, user interface, and authentication
quality can be audited independently of any agent implementation.
The CS is frequently a component of the user's client application,
the enterprise's authorization infrastructure, or a dedicated
confirmation application on a user device.
4.2. The Confirmation Service
A conforming Confirmation Service:
* MUST render confirmation requests to the user through a
programmatic interface, not by embedding the request in an LLM
prompt. This is the requirement of
[I-D.rosenberg-agentproto-usecases] Section 3.2.3. A CS that
forwards the confirmation decision through an LLM inference step
does not conform.
* MUST render every parameter marked "confirm": true in the action
descriptor, with its user-visible label, before presenting the
decision control.
* MUST sign evidence with a key bound to an identifier that
verifiers can discover and validate (Section 7.2).
* MUST NOT sign evidence for a decision it did not itself render and
collect.
* SHOULD bind the rendering it produced to the evidence it signs
(via the rendering digest, Section 7.4).
* MUST maintain replay state for the lifetime of each request
(Section 8.3).
4.3. Trust Model
The trust model answers three questions:
1. Does the verifier trust the CS to have actually interacted with
the user? Established by CS key validation and by local policy
(a verifier may accept a restricted set of CSes, e.g., those
operated by the same enterprise as the verifier).
Liu Expires 6 May 2027 [Page 11]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
2. Does the evidence concern THIS action? Established by the action
digest: the verifier recomputes the digest over the operation it
is about to execute. A CE that confirms a different action, or
an action with different parameters, will not match
(Section 7.4).
3. Is the evidence current? Established by the challenge (AA-
generated nonce), the confirmed-at time, and the lifetime
(Section 7.5).
A fourth property, aligned with
[I-D.okutomi-session-bound-agent-identity], is audience binding in
delegated flows: a CE names the acting agent for which it was issued,
so evidence obtained for one delegation is not acceptable for another
(Section 9).
The model deliberately does NOT require the verifier to trust the
requesting agent, the agent communication protocol, or any
intermediate agent. This is the property that answers the
hallucination concern of [I-D.rosenberg-agentproto-usecases]
Section 3.3.6: a fabricated confirmation cannot be produced without
the CS key, and a real confirmation cannot be redirected to a
different action or actor.
4.4. Confirmation Flows
Three flows are supported.
Variant A — Tool call, single agent (RA == AA):
1. AA determines the operation requires confirmation (from API
metadata, Section 10).
2. AA constructs the AD (Section 5) and CR (Section 6).
3. CS renders, collects the decision, signs the CE.
4. AA invokes the operation presenting the CE.
5. The API (or AA's enforcement point) verifies per Section 8.
Variant B — Delegated action (RA != AA):
1. AA (the invoked agent) constructs the AD and CR for its own
operation, including its own challenge and itself as audience.
2. AA sends the CR to RA over the agent communication protocol.
3. RA relays the CR to its CS. RA MUST NOT alter the AD or
challenge; the digest and challenge make alteration detectable.
4. CS renders to the user (RA's user is the confirming user if the
delegation carries user authority; see Section 9).
5. CS signs the CE; RA relays it back to AA.
6. AA verifies the CE (Section 8) before executing.
Liu Expires 6 May 2027 [Page 12]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
Variant C — Out-of-band confirmation:
When the user is not reachable on the current channel, the CR carries
channel requirements (Section 6); the CS delivers the confirmation
prompt through a pre-registered side channel (device push, SMS,
email), collects the decision out of band, and the result is returned
asynchronously. This variant addresses the reconnection and channel-
negotiation requirements discussed in
[I-D.feng-agentproto-session-requirements] and the resumption
semantics of [I-D.howe-agentproto-contact-center-usecases] (CC3-1,
CC3-4): an unobtainable confirmation is reported as a status outcome,
not as a denial (Section 9.3).
5. Action Descriptor
The Action Descriptor is the object the user actually confirms. It
is a JSON object conforming to the "authorization_details" entry
format of [RFC9396] Section 2, with the extensions defined in this
section. Reuse of the RAR structure is deliberate: it gives the
protocol a field-tested typed-descriptor model, an existing body of
deployment practice in open banking, and a documented set of pitfalls
(type design, consent-screen sanitization) that this profile inherits
and addresses.
5.1. Fields
type (string, REQUIRED) An identifier for the action type, as in
[RFC9396] Section 2.1. The value determines the allowable
contents of the descriptor. For interoperability across domains,
the value SHOULD be a URI under the control of the API provider,
following the collision-resistant namespace guidance of [RFC9396].
actions (array of strings, REQUIRED) The kinds of action requested,
e.g., "initiate", "update", "cancel".
locations (array of strings, OPTIONAL) The resource servers or
endpoints where the action will be executed, as in [RFC9396]
Section 2.2.
parameters (object, OPTIONAL) A map from field name to a parameter
object:
value (any, REQUIRED) The actual value for the operation
invocation.
confirm (boolean, OPTIONAL, default false) If true, this
parameter MUST be rendered to the user as part of the
confirmation. API metadata determines which parameters carry
confirm=true (Section 10).
render (object, OPTIONAL) User-visible rendering metadata for the
Liu Expires 6 May 2027 [Page 13]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
parameter: "label" (a short human-readable name), "value-label"
(a pre-formatted human rendering of the value), "format" (a
rendering hint such as "currency" or "date"), and "sensitive"
(if true, verifiers and logs SHOULD mask this parameter's
value, Section 12).
effect (string, OPTIONAL) One of "create", "update", "delete",
"transfer", "communication". Classifies the effect class of the
operation; used by policy. This field operationalizes the
distinction between an action and its effect identified by
[I-D.wadkins-agentproto-action-determinability].
reversible (boolean, OPTIONAL) Whether the operation's effect can be
undone by the same authority. When false or absent,
implementations SHOULD treat the operation as irreversible for
policy purposes.
expires (time, OPTIONAL) RFC 3339 timestamp after which the
descriptor itself is stale and a new confirmation is required
(e.g., fare validity).
Further fields MAY be added by action type definitions, as in
[RFC9396]. Unknown fields MUST be preserved by intermediaries and
included in digest computations.
5.2. Rendering Requirements
A conforming renderer (the CS) MUST construct the user-visible
confirmation from the AD as follows:
* Every parameter with confirm=true MUST be displayed, with its
render.label (or the field name if no label), and either its
render.value-label or a programmatic formatting of value under
render.format.
* The rendering set — the ordered sequence of (field, label,
rendered value) pairs actually displayed — is the input to the
rendering digest (Section 7.4).
* Rendering MUST occur in a non-LLM programmatic component. The AD,
its labels, and its values are untrusted display input: the
renderer MUST treat them as data, not markup, and MUST NOT
interpret formatting, links, or instructions within them. This
mirrors the consent-screen sanitization requirement noted in
[RFC9396] Section 2.1 and the rendering requirements of
[I-D.rosenberg-agentproto-usecases] Section 3.2.3.
* The renderer MUST present an explicit accept and reject control,
and MUST NOT default to acceptance.
Liu Expires 6 May 2027 [Page 14]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
5.3. Action Digest Computation
The action digest binds evidence to the exact action. To compute:
1. Construct the AD as a JSON object. The object MUST conform to
I-JSON [RFC7493] (no duplicate member names, no numbers that lose
precision).
2. Canonicalize using the JSON Canonicalization Scheme [RFC8785]
(JCS).
3. Compute SHA-256 [FIPS180-4] over the canonical form. The digest
is carried in binary in CBOR and base64url-encoded without
padding in JSON.
Verifiers MUST recompute this digest over the operation they are
asked to execute. To make recomputation deterministic, the
operation-to-AD mapping for each action type MUST be defined by the
action type's specification (how each API request field maps into AD
parameters). Section 10 defines how API metadata carries this
mapping.
5.4. CDDL Definition
The CDDL [RFC8610] definition of the action descriptor (JSON form):
; See Appendix A for the complete grammar
aacp-action-descriptor = { type: uri actions: [1* text] ? locations:
[1* uri] ? parameters: { * text => aacp-parameter } ? effect:
aacp-effect ? reversible: bool ? expires: time * $$aacp-ad-extension }
aacp-parameter = { value: any ? confirm: bool ? render: { ? label:
text ? value-label: text ? format: text ? sensitive: bool } }
aacp-effect = "create" / "update" / "delete" / "transfer" /
"communication"
6. Confirmation Request
The Confirmation Request is constructed by the Acting Agent.
{ "v": 1, "request-id": "<UUIDv4 [RFC9562]>",
"action-digest": "<base64url(SHA-256(JCS(AD)))>", "challenge":
"<base64url(16+ random octets)>", "lifetime": 300, "audience":
"<identifier of the Acting Agent>", "subject": "<identifier of
the Confirming User, if known>", ? "channel": { "min-loa": 2,
"modes": ["device-push", "sms"] }, ? "handoff": [ "<digest of signed
handoff offer>" ], ? "rendering-hint": { ... } }
Semantics:
request-id Unique identifier for this confirmation request,
Liu Expires 6 May 2027 [Page 15]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
generated as a UUID [RFC9562]. Used for replay tracking
(Section 8.3).
action-digest The digest defined in Section 5.3. The CR SHOULD also
carry the full AD so the CS can render without an additional
round-trip; the digest is authoritative.
challenge AA-generated random value, at least 128 bits. The CS MUST
include it in the signed evidence. This gives the AA a freshness
proof it controls: evidence for a stale or transplanted challenge
is detectable without any shared state between AA and CS.
lifetime Maximum age, in seconds, of an acceptable confirmation
measured from confirmed-at.
audience The identifier of the Acting Agent for which this evidence
is valid. Prevents context diversion per
[I-D.okutomi-session-bound-agent-identity]: evidence issued for
one delegation must not be usable for another.
subject The user whose confirmation is sought, when known to AA.
Binding of user identifiers is out of scope (Section 1.3), but the
field MUST be carried into the evidence when present.
channel Channel requirements for Variant C: minimum level of
assurance and acceptable out-of-band modes.
handoff Digests referencing the signed handoff offers through which
the task reached this agent, when the action flows from a
delegation chain [I-D.srivastava-agentproto-handoff-context]. See
Section 9.2.
7. Confirmation Evidence
7.1. Structure
The Confirmation Evidence records the user's decision:
{ "v": 1, "request-id": "<same as CR>",
"action-digest": "<same as CR>", "challenge": "<same as
CR>", "decision": "confirmed" / "denied", "audience": "<same as
CR>", ? "subject": "<same as CR>", "confirmed-at": "<RFC
3339 timestamp>", "auth-context": { "method": "<how the user
authenticated to the CS>", "loa": <integer 0..5>, ? "as":
"<authorization server identifier, if OAuth-bound>" }, ?
"rendering-digest": "<digest of rendered confirmation set>", ?
"handoff": [ "<same as CR>" ], ? "extensions": { ... } }
decision "confirmed" or "denied". Both are signed. A denied
Liu Expires 6 May 2027 [Page 16]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
decision MUST produce evidence, not silence: preserving negative
outcomes is the exercise requirement of
[I-D.he-agentproto-verifier-evidence] and the evaluation-state
requirement of [I-D.konda-agentproto-evaluation-state]. Absence
of evidence, in contrast, means no collection was attempted or
completed, and is reported by the separate status object of
Section 9.3.
auth-context How the user authenticated to the CS at confirmation
time: "method" (e.g., "passkey", "device-unlock", "knowledge-
proof", "oauth-session"), "loa" (a coarse level of assurance, 0-5,
scale defined by deployment policy), and optionally "as" (the
identity of the authorization server when the CS operates as part
of an OAuth deployment). This carries the authentication-
assurance notion discussed in [I-D.rosenberg-agentproto-usecases]
Section 3.2.2.2: verifiers can enforce that irreversible actions
require, e.g., a fresh device authentication rather than a
remembered session.
rendering-digest SHA-256 over the JCS-canonicalized rendering set
actually displayed (Section 5.2). Binds "what the user saw" to
the signed record, enabling a verifier to check that the fields
requiring confirmation were actually exercised (Appendix C, HE-1).
7.2. Signature and Canonicalization
The CE is a JWS [RFC7515] with compact serialization:
* Payload: the UTF-8 JCS [RFC8785] canonicalization of the CE JSON
object. JCS canonicalization makes the signature deterministic
across JSON serializers.
* Signing algorithms: ES256 or EdDSA (Ed25519) [RFC8032] MUST be
supported; RS256 MAY be supported. Algorithms MUST NOT be
negotiated by the signer; the CS key's registered algorithm set is
authoritative.
* The "kid" header parameter identifies the CS key; verifiers
resolve it through the CS's published key set (e.g., a JWK Set at
a well-known location, or enterprise key distribution). Key
discovery is deployment profile; this document requires only that
a verifier can resolve a CS key to a CS identifier and check its
freshness.
* Detached payload (RFC 7515 Appendix F) MAY be used when the CE is
conveyed alongside the already-known CR.
CBOR mapping: Appendix A defines the CBOR form; signatures in the
CBOR profile use COSE_Sign1 [RFC9052] with the same payload
semantics.
Liu Expires 6 May 2027 [Page 17]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
Key rotation: a CS MUST overlap old and new keys for at least the
maximum evidence lifetime it issues; verifiers MUST accept keys valid
at confirmed-at time, not only at verification time, to preserve
post-session verifiability (the
[I-D.wadkins-agentproto-action-determinability] requirement).
7.3. Authentication Context
The auth-context is an honest report by the CS of how the user
authenticated when the decision was collected. It is not a proof of
authentication; it is a claim by the CS, covered by the CS signature.
Verifiers apply policy to it:
* An operation classified irreversible by policy SHOULD require a
fresh method (device authentication, passkey with user
verification) rather than a carried session.
* A verifier MUST NOT infer more assurance than the auth-context
states: a "knowledge-proof" method with loa 1 records exactly
that, and policy for high-value actions may reject it. This
mirrors the verifier-side acceptance discipline of
[I-D.okutomi-session-bound-agent-identity]: what is accepted is
what was actually verified, no more.
7.4. Binding Rules
A CE is bound to:
1. The action, by action-digest. A verifier recomputes the digest
over the operation at hand (Section 8.1, step 3). Mismatch
invalidates the evidence for that operation. This prevents
confirmation swapping: evidence for booking flight X cannot be
replayed against booking flight Y even if all other fields agree.
2. The requesting session, by challenge. The AA generates the
challenge; only a CS that processed this CR signs a CE with this
challenge. The AA therefore knows the evidence was produced for
its current request, not retrieved from storage.
3. The acting agent, by audience. In delegated flows, evidence
names its consumer; other agents cannot use it.
4. The rendering, by rendering-digest, when present.
5. The delegation path, by handoff digests, when present
(Section 9.2).
Liu Expires 6 May 2027 [Page 18]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
The dependency-closure discipline of
[I-D.bu-agentproto-security-principal-binding] applies: a composed
verification result is no stronger than its weakest verified input.
A CE with an unresolvable key, an unknown method, or an unverifiable
digest yields an unverifiable row outcome, not a failure elsewhere to
be papered over by an otherwise-valid signature.
7.5. Lifetime and Freshness
Evidence is current when verified within "lifetime" seconds of
confirmed-at. Verifiers MAY additionally bound the age of the whole
chain (CR construction to verification) per local policy.
Freshness is anchored at the AA's challenge, not at CS clocks: the AA
does not need to trust CS time, only its own clock and its own
randomness. CS clock skew affects only the lifetime computation, for
which a conservative verifier margin is RECOMMENDED.
8. Verification Procedure
8.1. Verification Steps
A verifier (API gateway, enforcement point at AA, or later auditor)
processes a presented CE as follows. Steps are ordered; each
produces a row outcome (Section 8.2).
1. Presence. If the operation requires confirmation (per Section 10
metadata) and no CE is presented, outcome is "absent".
2. Signature. Validate the JWS against a resolvable CS key.
Invalid signature or unresolvable key: outcome "invalid" or
"unverifiable" respectively.
3. Action digest. Recompute the digest over the operation being
executed, using the operation-to-AD mapping from the action type
specification. Compare with CE action-digest. Mismatch: outcome
"mismatched".
4. Audience. The CE audience MUST equal the verifier's agent
identity (for AA) or the accepting party's identity. Mismatch:
"diverted".
5. Decision. decision MUST be "confirmed". "denied": outcome
"denied".
6. Freshness. Challenge MUST equal the challenge the verifier
issued (if the verifier is the AA); confirmed-at plus lifetime
MUST not be in the past; request-id MUST NOT have been seen
(Section 8.3). Violations: "stale" or "replay".
7. Policy. auth-context MUST satisfy the verifier's policy for the
effect class (Section 7.3). Violation: "insufficient-assurance".
Liu Expires 6 May 2027 [Page 19]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
8. Exercise (optional, RECOMMENDED for irreversible actions). If
the action type specification defines the required rendering set,
recompute the rendering digest and compare with CE rendering-
digest. Absent rendering-digest: the verifier cannot establish
that the user saw the required fields; outcome "unexercised" if
policy requires it.
All outcomes other than full success are terminal for the presented
CE. The verifier MUST NOT partially accept.
8.2. Outcome Matrix and Error Codes
Each row outcome maps to a distinct error signal. This distinct-
outcome model is the protocol-level realization of the requirements
in [I-D.konda-agentproto-evaluation-state] and CMN-12 of
[I-D.agentic-ai-usecases-requirements]: a verifier must be able to
determine whether a check failed or could not be completed, and the
two cases must produce different signals.
Liu Expires 6 May 2027 [Page 20]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
+======================+==========================+================+
|Row outcome |HTTP API error |Retry semantics |
+======================+==========================+================+
|absent |confirmation_required |Obtain a |
| | |confirmation |
+----------------------+--------------------------+----------------+
|invalid |confirmation_invalid |Do not retry |
| | |unchanged; alert|
+----------------------+--------------------------+----------------+
|unverifiable |confirmation_unavailable |Retry after key |
| | |or CS recovery |
+----------------------+--------------------------+----------------+
|mismatched |confirmation_mismatch |Regenerate: the |
| | |action differs |
+----------------------+--------------------------+----------------+
|diverted |confirmation_diverted |Evidence not |
| | |issued for this |
| | |verifier |
+----------------------+--------------------------+----------------+
|denied |confirmation_denied |Only user- |
| | |initiated retry |
+----------------------+--------------------------+----------------+
|stale |confirmation_stale |Re-request |
+----------------------+--------------------------+----------------+
|replay |confirmation_replay |Investigate; do |
| | |not auto-retry |
+----------------------+--------------------------+----------------+
|insufficient-assurance|confirmation_low_assurance|Re-authenticate |
| | |at higher LoA |
+----------------------+--------------------------+----------------+
|unexercised |confirmation_unexercised |Re-render with |
| | |required fields |
+----------------------+--------------------------+----------------+
|success |(accepted) |Execute |
+----------------------+--------------------------+----------------+
Table 2
Conflating these outcomes — for example, reporting "denied" for
"unobtainable", or "invalid" for "stale" — is a protocol violation.
Retry storms, alert misrouting, and audit ambiguity are precisely the
costs that motivated the evaluation-state requirements; the error
taxonomy exists to prevent them.
Liu Expires 6 May 2027 [Page 21]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
8.3. Replay Prevention
Replay state is keyed by request-id. The verifying party (AA or API)
MUST retain request-ids of accepted CEs for at least the CR lifetime
plus a margin. Because request-id is carried inside the signed
payload, an attacker cannot mint a fresh id for an old decision
without the CS key.
Challenge gives AA-side freshness without shared state: for the AA
verifier, step 6's challenge check subsumes replay checking for
cross-session transplants; request-id state additionally catches
same-session replay.
9. Multi-Agent Confirmation
9.1. Delegated Flow
In Variant B, the acting agent AA cannot reach the user; the
requesting agent RA holds the user dialog. The flow of Section 4.4
applies. Security properties:
* RA cannot fabricate evidence (no CS key).
* RA cannot alter the action: the AD digest is fixed by AA before RA
ever sees the request; alteration is detected by the CS (which
renders the AD it received and signs the digest) and by AA at
verification.
* RA cannot replay evidence: AA's challenge is fresh per request.
* RA cannot redirect evidence: audience binding names AA.
* RA cannot suppress a denial undetectably: a denial is signed
evidence; if RA returns nothing, AA sees "absent", which is
distinct from "denied" (Section 9.3). RA can, however, drop the
interaction entirely; the denial-signal property holds only for
interactions that complete. This residual risk is noted in
Section 11.
9.2. Handoff Chain Binding
When the task reached AA through a signed handoff chain
[I-D.srivastava-agentproto-handoff-context], the CR and CE carry the
digest(s) of the handoff offer chain. This binds the confirmation to
the delegation path, not merely to the final operation: a CE names
the chain of delegated authority under which the action will execute.
Verifiers with delegation policy (e.g., "this action may only execute
under a delegation chain rooted at enterprise X") check the chain
Liu Expires 6 May 2027 [Page 22]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
digest against their policy. The chain itself is carried by the
handoff protocol, not by AACP; AACP references it only by digest,
keeping this document's formats opaque to the transparency or logging
service behind the chain — the same opacity discipline as
[I-D.srivastava-agentproto-handoff-context], whose prior context is
named by digest only.
9.3. Denied, Unobtainable, and Stale Are Different Facts
AACP distinguishes:
* denied: the user decided against the action. Signed evidence
exists with decision "denied". This is a first-class fact; agents
SHOULD record it and MUST NOT silently retry.
* unobtainable: the confirmation could not be collected (user
unreachable on all channels, CS failure, dialog lifetime expired
before collection). Reported by the CS as an unsigned status
object:
{ "request-id": "...", "outcome": "unobtainable",
"reason": "channel-unreachable" / "dialog-expired" / "cs-error" /
"user-unreachable", "reported-at": "..." }
An unsigned status is deliberately weaker than evidence: it is a
report, not a decision. It maps to the "confirmation_unavailable"
error and to retry-after-recovery semantics. This separation is
exactly the konda requirement: collapsing "denied" and "could not
be asked" into one value corrupts retry behavior and audit
interpretation.
* stale: the user confirmed, but the evidence aged out before
execution. Maps to "confirmation_stale"; re-request is
appropriate. The dialog-interruption semantics of CC3-4 in
[I-D.howe-agentproto-contact-center-usecases] (distinguish an
interrupted dialog from a terminated one) are preserved here: an
interrupted confirmation flow yields "unobtainable" with reason
"dialog-expired", not a denial.
10. API Integration
APIs declare which operations require confirmation, and how their
request fields map to confirmable parameters, through metadata. For
OpenAPI-described APIs, this document defines the "x-aacp" extension
object:
Liu Expires 6 May 2027 [Page 23]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
"x-aacp": { "type":
"https://api.airlines.example.com/actions/flight_booking", "actions":
["book"], "confirm-parameters": ["flight_number", "fare_class",
"total_price"], "render": { "flight_number": { "label": "Flight" },
"fare_class": { "label": "Cabin", "value-map": { "economy": "Economy",
"business": "Business" } }, "total_price": { "label": "Total price",
"format": "currency" } } }
The extension carries: the action type (URI), the action verbs, the
list of request parameters that MUST be confirmed, and rendering
metadata per parameter. This is the API annotation machinery
required by [I-D.rosenberg-agentproto-usecases] Section 3.2.3: the
API owner — the only party able to judge the risk of the operation —
decides what requires confirmation and how it is presented.
Enforcement: an API whose metadata declares confirmation for an
operation MUST reject the operation with "confirmation_required" when
no valid CE accompanies it. The API is the last-line verifier;
agent-side enforcement alone MUST NOT be relied upon (an agent may be
compromised or hallucinating — which is the threat this protocol
exists to contain).
The API SHOULD also define its operation-to-AD mapping (which request
fields become which AD parameters, and their canonical serialization)
so that verifiers can recompute the action digest deterministically.
For REST APIs, the default mapping is: one AD per API request;
parameters map from request body fields by name; locations maps from
the endpoint URI.
11. Security Considerations
11.1. Threat Model
The protocol defends against:
Fabricated confirmation An intermediate or acting agent claims user
approval it never obtained. Defeated by the CS signature:
fabrication requires the CS key. Residual: CS compromise
(Section 11.4).
Confirmation swapping Real evidence for action A is applied to
action B. Defeated by the action digest; the verifier recomputes
over the operation at hand.
Replay Old evidence is re-presented. Defeated by challenge (AA-side
freshness), request-id tracking, and lifetime.
Diversion Evidence issued for one delegation is used for another.
Defeated by audience binding.
Downgrade / silent skip An agent bypasses confirmation for a
Liu Expires 6 May 2027 [Page 24]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
confirmation-required operation. Defeated by API-side enforcement
with fail-closed behavior.
Rendering attacks Malicious content in AD labels or values attacks
the confirmation UI (homoglyphs, crafted formatting, injection
into mark-up-capable renderers). Mitigated by the data-not-markup
rendering rule (Section 5.2), consistent with the consent-
sanitization guidance in [RFC9396]. Renderers MUST escape or
reject non-conforming content; homoglyph attacks on labels are
mitigated by recommending ASCII labels where practical and by
value-label pre-formatting for critical fields.
Prompt injection Injected instructions can still cause an agent to
CONSTRUCT an undesirable action descriptor; AACP does not prevent
this. What AACP guarantees is that the constructed action,
whatever it is, is shown to the user for an explicit, non-LLM
decision before irreversible execution. This bounds prompt-
injection blast radius to actions the user can see and reject.
This addresses the containment aspect (not the detection aspect)
of the prompt-injection discussion in
[I-D.rosenberg-agentproto-usecases] Section 3.3.7.
11.2. Residual Risks
RA interaction dropping In Variant B, RA can refuse to relay the CR
or the CE. AA sees "absent"/timeout and must not execute. The
user is not informed of the dropped interaction by AACP itself;
surfacing it is the surrounding dialog protocol's responsibility.
CS compromise A compromised CS can sign fabricated confirmations for
any action it is asked to confirm. Mitigations: CS keys SHOULD be
held in hardware or isolated confirmation UIs; deployment profiles
SHOULD scope CS acceptance (verifiers accept only CSes they have
policy reasons to trust); the auth-context records the method, so
fabricated "passkey" claims require attacking that infrastructure
too. CS compromise is a catastrophic failure mode and is not
further mitigated by this protocol.
User rubber-stamping Confirmation fatigue leads users to approve
without reading. A protocol cannot fix this; rendering
requirements (explicit controls, no defaults) are the available
mitigation. Action type specifications SHOULD minimize the
confirmable parameter set to what matters.
Time shifting CS clock skew can extend or shorten effective evidence
lifetime by the skew amount. Verifier margins are RECOMMENDED.
Liu Expires 6 May 2027 [Page 25]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
11.3. Algorithm Agility
This document fixes the digest (SHA-256) and requires ES256 or EdDSA
signatures. New algorithms enter through a CS key registration
update, not through protocol negotiation; signers MUST NOT offer
downgrade choices. If SHA-256 requires replacement in the future,
the version field "v" governs a revised digest profile; verifiers
MUST reject unknown versions.
11.4. Key Management
CS keys MUST rotate with overlap exceeding the maximum evidence
lifetime (Section 7.2). Verifiers MUST retain retired keys (or a
transparency record of them) at least as long as they must verify
past evidence — the post-session determinability requirement of
[I-D.wadkins-agentproto-action-determinability]. Long-horizon
verifiers (auditors) SHOULD anchor key history in an append-only
record, e.g., a SCITT-style transparency service
[I-D.ietf-scitt-architecture].
12. Privacy Considerations
Confirmation evidence records that a specific user (subject) approved
a specific action (descriptor digest) at a time. This is
intentionally disclosure-capable information. Considerations:
* The CE carries digests, not the descriptor itself. Third parties
cannot learn action parameters from a CE without the corresponding
AD. Entities that held both (the AA, the CS) already knew the
parameters.
* Parameters marked render.sensitive=true SHOULD be masked in logs
and SHOULD NOT be included in the rendering set stored alongside
evidence (the rendering digest commits to them without retaining
them).
* The auth-context describes method and assurance level, not
credentials; it carries no secrets.
* Variant C side-channel delivery necessarily reveals the
confirmation's existence and its label to the side-channel
provider; CR construction SHOULD minimize descriptor content on
such channels.
* Data minimization: verifiers SHOULD discard evidence after their
verification horizon unless retention is required for the action's
accountability period; retention policy is deployment-scoped.
Liu Expires 6 May 2027 [Page 26]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
13. IANA Considerations
13.1. Media Types
This document requests registration of:
application/aacp-confirmation-request+json Structure: Section 6;
encoding: UTF-8 JSON.
application/aacp-confirmation-evidence+json Structure: Section 7;
encoding: UTF-8 JSON; a JWS (RFC 7515) compact serialization whose
payload is the JCS-canonicalized CE object.
application/aacp-confirmation-status+json Structure: Section 9.3;
encoding: UTF-8 JSON.
A CBOR media type (application/aacp+cbor) is requested for the CBOR
profile of Appendix A, content-format TBD.
13.2. Confirmation Outcome Values Registry
IANA is asked to create a registry "AACP Row Outcomes" with the
values of Section 8.2 (absent, invalid, unverifiable, mismatched,
diverted, denied, stale, replay, insufficient-assurance, unexercised,
success). New values require Specification Required [RFC8126].
13.3. Error Code Allocation
The HTTP API error codes of Section 8.2 (confirmation_required,
confirmation_invalid, ...) are registered in a subregistry with the
same policy. Profiles that map outcomes to transport-specific errors
MUST preserve their distinctness.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
March 2015, <https://www.rfc-editor.org/info/rfc7493>.
Liu Expires 6 May 2027 [Page 27]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8785] Rundgren, A., Weber, S., and D. Johansson, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Language to
Express CBOR and JSON Data Structures", RFC 8610, June
2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, May 2015,
<https://www.rfc-editor.org/info/rfc7515>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, May 2024,
<https://www.rfc-editor.org/info/rfc9562>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[FIPS180-4]
NIST, "Secure Hash Standard", FIPS PUB 180-4, August 2015.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
14.2. Informative References
Liu Expires 6 May 2027 [Page 28]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
[I-D.rosenberg-agentproto-usecases]
Rosenberg, J. and C. Jennings, "Framework, Use Cases and
Requirements for AI Agent Protocols", Work in Progress,
Internet-Draft, draft-rosenberg-agentproto-usecases-00, 4
July 2026, <https://datatracker.ietf.org/doc/html/draft-
rosenberg-agentproto-usecases-00>. Work in Progress.
[I-D.bu-agentproto-security-principal-binding]
Bu, S., "Security Principal and Verifier Binding for Agent
Communication Protocols", Work in Progress, Internet-
Draft, draft-bu-agentproto-security-principal-binding-08,
13 October 2026, <https://datatracker.ietf.org/doc/html/
draft-bu-agentproto-security-principal-binding-08>. Work
in Progress.
[I-D.he-agentproto-verifier-evidence]
He, J. S., "Exercise and Completeness Evidence for Agent
Protocol Verifier Results", Work in Progress, Internet-
Draft, draft-he-agentproto-verifier-evidence-01, 18
October 2026, <https://datatracker.ietf.org/doc/html/
draft-he-agentproto-verifier-evidence-01>. Work in
Progress.
[I-D.konda-agentproto-evaluation-state]
Konda, G., "Preserving Evaluation State in Agent Protocol
Decisions", Work in Progress, Internet-Draft, draft-konda-
agentproto-evaluation-state-02, 19 October 2026,
<https://datatracker.ietf.org/doc/html/draft-konda-
agentproto-evaluation-state-02>. Work in Progress.
[I-D.wadkins-agentproto-action-determinability]
Wadkins, D., "Determinability of Agent Actions", Work in
Progress, Internet-Draft, draft-wadkins-agentproto-action-
determinability-00, 10 September 2026,
<https://datatracker.ietf.org/doc/html/draft-wadkins-
agentproto-action-determinability-00>. Work in Progress.
[I-D.okutomi-session-bound-agent-identity]
Okutomi, A., "A Verifier-Side Acceptance Profile for
Channel-Bound Agent Identity and Authorization", Work in
Progress, Internet-Draft, draft-okutomi-session-bound-
agent-identity-06, 30 July 2026,
<https://datatracker.ietf.org/doc/html/draft-okutomi-
session-bound-agent-identity-06>. Work in Progress.
[I-D.agentic-ai-usecases-requirements]
Reddy, T., Sarker, Z., and K. Yao, "Agentic AI Use Cases
and Requirements", Work in Progress, Internet-Draft,
Liu Expires 6 May 2027 [Page 29]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
draft-agentic-ai-usecases-requirements-05, 27 October
2026, <https://datatracker.ietf.org/doc/html/draft-
agentic-ai-usecases-requirements-05>. Work in Progress.
[I-D.srivastava-agentproto-handoff-context]
Srivastava, K., "Signed Handoff Context for Agentic
Dialogs", Work in Progress, Internet-Draft, draft-
srivastava-agentproto-handoff-context-00, 26 October 2026,
<https://datatracker.ietf.org/doc/html/draft-srivastava-
agentproto-handoff-context-00>. Work in Progress.
[I-D.feng-agentproto-session-requirements]
Feng, C., "Requirements for Agent Session Establishment,
Capability Negotiation, and Sessionless Interaction", Work
in Progress, Internet-Draft, draft-feng-agentproto-
session-requirements-02, 20 August 2026,
<https://datatracker.ietf.org/doc/html/draft-feng-
agentproto-session-requirements-02>. Work in Progress.
[I-D.howe-agentproto-contact-center-usecases]
Howe, T., "Contact Center Use Cases and Requirements for
Agentic Dialogs", Work in Progress, Internet-Draft, draft-
howe-agentproto-contact-center-usecases-00, 25 October
2026, <https://datatracker.ietf.org/doc/html/draft-howe-
agentproto-contact-center-usecases-00>. Work in Progress.
[I-D.ietf-scitt-architecture]
Birkholz, H., "An Architecture for Trust Services with
Strict Data Integrity", Work in Progress, Internet-Draft,
draft-ietf-scitt-architecture,
<https://datatracker.ietf.org/doc/draft-ietf-scitt-
architecture/>. Work in Progress.
[I-D.rosenberg-aiproto-cheq]
Rosenberg, J., White, P., and C. Jennings, "Confirmation
with Human in the Loop (HITL) Exchange of Quotations
(CHEQ)", Work in Progress, Internet-Draft, draft-
rosenberg-aiproto-cheq-00, 19 October 2025,
<https://datatracker.ietf.org/doc/draft-rosenberg-aiproto-
cheq/>. Work in Progress. Expired April 2026.
[I-D.liu-agent-operation-authorization]
Liu, D., Zhu, J., and S. Krishnan, "Agent Operation
Authorization", Work in Progress, Internet-Draft, draft-
liu-agent-operation-authorization-02, 15 March 2026,
<https://datatracker.ietf.org/doc/draft-liu-agent-
operation-authorization/>. Work in Progress. Expired
September 2026.
Liu Expires 6 May 2027 [Page 30]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
[I-D.emerson-oauth-user-mediated-delivery]
Emerson, C., "User-Mediated Credential Delivery as a
Complementary Authorization Primitive for AI Agents", Work
in Progress, Internet-Draft, draft-emerson-oauth-user-
mediated-delivery-01, 26 October 2026,
<https://datatracker.ietf.org/doc/draft-emerson-oauth-
user-mediated-delivery/>. Work in Progress.
[CHARTER] IETF, "Agent Communication Protocols (agentproto)
Charter", 8 October 2026,
<https://datatracker.ietf.org/wg/agentproto/charter/>.
Approved 8 October 2026.
[CIBA] OpenID Foundation, "OpenID Connect Client Initiated
Backchannel Authentication Flow - Core 1.0",
<https://openid.net/specs/openid-connect-client-initiated-
backchannel-authentication-core-1_0.html>.
[WebAuthn] World Wide Web Consortium, "Web Authentication: An API for
accessing Public Key Credentials, Level 2",
<https://www.w3.org/TR/webauthn-2/>. W3C Recommendation.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Complete CDDL Definition
The complete CDDL grammar for the three objects, in their CBOR forms
(the JSON forms differ only in encoding of binary values and map key
types; the JSON form uses base64url without padding and string keys):
Liu Expires 6 May 2027 [Page 31]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
start = aacp-confirmation-request /
aacp-confirmation-evidence / aacp-confirmation-status
aacp-action-descriptor = { type: uri actions: [1* text] ? locations: [1*
uri] ? parameters: { * text => aacp-parameter } ? effect: aacp-effect
? reversible: bool ? expires: time * $$aacp-ad-extension }
aacp-parameter = { value: any ? confirm: bool ? render: { ? label: text
? value-label: text ? format: text ? sensitive: bool } } aacp-effect =
"create" / "update" / "delete" / "transfer" / "communication"
aacp-confirmation-request = { v: 1 request-id: uuid-type action-digest:
digest challenge: bstr .size 16 lifetime: uint audience: text ? subject:
text ? channel: { ? min-loa: uint .le 5 ? modes: [1* text] } ? handoff:
[1* digest] * $$aacp-cr-extension } aacp-confirmation-evidence = { v: 1
request-id: uuid-type action-digest: digest challenge: bstr .size 16
decision: "confirmed" / "denied" audience: text ? subject: text
confirmed-at: time auth-context: { method: text loa: uint .le 5 ? as:
uri } ? rendering-digest: digest ? handoff: [1* digest] *
$$aacp-ce-extension } aacp-confirmation-status = { request-id: uuid-type
outcome: "unobtainable" reason: "channel-unreachable" / "dialog-expired"
/ "cs-error" / "user-unreachable" reported-at: time } digest = bstr
.size 32 ; SHA-256 uuid-type = bstr .size 16 ; RFC 9562 UUID, binary
form ; Extension points use CDDL sockets: $$aacp-ad-extension //= (?
aacp-ad-ext: any) $$aacp-cr-extension //= (? aacp-cr-ext: any)
$$aacp-ce-extension //= (? aacp-ce-ext: any)
Appendix B. Examples
B.1. Action Descriptor (flight booking)
{ "type":
"https://api.airlines.example.com/actions/flight_booking", "actions":
["book"], "locations": ["https://api.airlines.example.com/bookings"],
"parameters": { "flight_number": { "value": "UA123", "confirm": true,
"render": { "label": "Flight", "value-label": "United 123, New York
JFK to Los Angeles LAX" } }, "departure_date": { "value":
"2026-11-20", "confirm": true, "render": { "label": "Departure",
"value-label": "20 November 2026, 09:00 EST" } }, "passenger_name": {
"value": "A. Example", "confirm": true, "render": { "label":
"Passenger" } }, "fare_class": { "value": "economy", "confirm": true,
"render": { "label": "Cabin", "value-label": "Economy" } },
"total_price": { "value": { "currency": "USD", "amount": "412.00" },
"confirm": true, "render": { "label": "Total price", "format":
"currency" } }, "seat_preference": { "value": "window" } }, "effect":
"create", "reversible": false, "expires": "2026-10-31T12:00:00Z" }
Parameters with confirm=true (flight, date, passenger, cabin, price)
form the rendering set; seat_preference is part of the action digest
but not the confirmation display.
Liu Expires 6 May 2027 [Page 32]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
B.2. Confirmation Request
{ "v": 1, "request-id":
"f47ac10b-58cc-4372-a567-0e02b2c3d479", "action-digest":
"base64url(SHA-256(JCS(descriptor)))", "challenge": "base64url(16
random octets)", "lifetime": 300, "audience":
"agent:booking.airlines.example.com", "subject":
"user:alice@example.com" }
B.3. Confirmation Evidence (payload before JCS and signing)
{ "v": 1, "request-id":
"f47ac10b-58cc-4372-a567-0e02b2c3d479", "action-digest":
"base64url(SHA-256(JCS(descriptor)))", "challenge": "base64url(16
random octets)", "decision": "confirmed", "audience":
"agent:booking.airlines.example.com", "subject":
"user:alice@example.com", "confirmed-at": "2026-10-31T11:03:17Z",
"auth-context": { "method": "passkey", "loa": 4 }, "rendering-digest":
"base64url(SHA-256(JCS(rendering-set)))" }
B.4. Denied Evidence
The same structure with "decision": "denied" and the matching
confirmed-at. The acting agent MUST treat denial as a terminal
outcome for the request-id and MUST NOT re-request confirmation for
the same action-digest without a new user-initiated dialog turn.
B.5. Unobtainable Status
{ "request-id":
"f47ac10b-58cc-4372-a567-0e02b2c3d479", "outcome": "unobtainable",
"reason": "dialog-expired", "reported-at": "2026-10-31T11:59:02Z" }
Appendix C. Requirement Traceability Matrix
Each mechanism in this document traces to at least one requirement in
the agentproto document set or an external standard:
+=======+====================================================+=====+
| ID | Mechanism (section) | Src |
+=======+====================================================+=====+
| RR-1 | Programmatic, non-LLM rendering requirement for | 1 |
| | the CS (Sec 4.2, 5.2) | |
+-------+----------------------------------------------------+-----+
| RR-2 | API annotation of confirmation-required operations | 1 |
| | and field-level confirm flags (Sec 5.1, 10) | |
+-------+----------------------------------------------------+-----+
| RR-3 | User-visible rendering metadata (render labels, | 1 |
Liu Expires 6 May 2027 [Page 33]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
| | value labels, formats) (Sec 5.1, 10) | |
+-------+----------------------------------------------------+-----+
| RR-4 | Cryptographic assurance that confirmation | 1 |
| | originates from the user, in delegated flows (Sec | |
| | 4.4, 7, 9) | |
+-------+----------------------------------------------------+-----+
| BU-1 | Action evidence as a separated, digest-bound claim | 2 |
| | (Sec 7.1, 7.4) | |
+-------+----------------------------------------------------+-----+
| BU-2 | Evidence provenance via CS key identity and auth- | 2 |
| | context (Sec 7.2, 7.3) | |
+-------+----------------------------------------------------+-----+
| BU-3 | Freshness rules and lifetime bounds (Sec 7.5) | 2 |
+-------+----------------------------------------------------+-----+
| BU-4 | Distinct row outcomes with terminal processing, no | 2 |
| | partial acceptance (Sec 8) | |
+-------+----------------------------------------------------+-----+
| BU-5 | Dependency closure: unresolvable inputs yield | 2 |
| | unverifiable, never inflated outcomes (Sec 7.4, | |
| | 8.2) | |
+-------+----------------------------------------------------+-----+
| HE-1 | Exercise evidence: rendering-digest commits to the | 3 |
| | confirmation display the user actually saw (Sec | |
| | 5.2, 7.4, 8.1 step 8) | |
+-------+----------------------------------------------------+-----+
| HE-2 | Denied decisions produce signed evidence, not | 3,4 |
| | silence (Sec 7.1, 9.3) | |
+-------+----------------------------------------------------+-----+
| KO-1 | denied / unobtainable / stale as distinct outcomes | 4 |
| | with distinct errors (Sec 8.2, 9.3) | |
+-------+----------------------------------------------------+-----+
| WA-1 | Post-session verifiability: detached signatures, | 5 |
| | key-history retention rules (Sec 7.2, 11.4) | |
+-------+----------------------------------------------------+-----+
| WA-2 | Effect classification (effect, reversible) (Sec | 5 |
| | 5.1) | |
+-------+----------------------------------------------------+-----+
| CM-1 | Verify-at-the-time-authorized and distinguish- | 6 |
| | failed-vs-incomplete (CMN-12) (Sec 8.2) | |
+-------+----------------------------------------------------+-----+
| SV-1 | Handoff chain binding by digest (Sec 9.2) | 7 |
+-------+----------------------------------------------------+-----+
| OK-1 | Audience binding against context diversion (Sec | 8 |
| | 7.1, 8.1 step 4) | |
+-------+----------------------------------------------------+-----+
| HO-1 | Out-of-band confirmation with dialog-interruption | 9 |
| | semantics (Sec 4.4 Variant C, 9.3) | |
+-------+----------------------------------------------------+-----+
Liu Expires 6 May 2027 [Page 34]
Internet-Draft Agent Action Confirmation Protocol (AACP November 2026
| FE-1 | Channel requirements in the CR, async | 10 |
| | reconnection-compatible confirmation (Sec 6) | |
+-------+----------------------------------------------------+-----+
| RAR-1 | Descriptor structure derived from | 11 |
| | authorization_details (Sec 5.1) | |
+-------+----------------------------------------------------+-----+
| RAR-2 | Consent-display sanitization inherited (Sec 5.2, | 11 |
| | 11.1) | |
+-------+----------------------------------------------------+-----+
Table 3
Sources:
1. [I-D.rosenberg-agentproto-usecases] Sections 3.2.3, 3.3.6
2. [I-D.bu-agentproto-security-principal-binding] claims C-005,
C-007, C-008, C-009; row-outcome and closure rules
3. [I-D.he-agentproto-verifier-evidence]
4. [I-D.konda-agentproto-evaluation-state]
5. [I-D.wadkins-agentproto-action-determinability]
6. [I-D.agentic-ai-usecases-requirements] CMN-12
7. [I-D.srivastava-agentproto-handoff-context]
8. [I-D.okutomi-session-bound-agent-identity]
9. [I-D.howe-agentproto-contact-center-usecases] CC3-1, CC3-4
10. [I-D.feng-agentproto-session-requirements]
11. [RFC9396]
Appendix D. Acknowledgments
The requirement structure of this document is drawn from the
agentproto working group's document set; the author acknowledges the
authors of those documents for the analysis this protocol builds on.
The action descriptor design reuses the Rich Authorization Requests
structure of RFC 9396, whose authors' deployment experience informed
several profile decisions.
Author's Address
Meihui Liu
China Mobile
Email: liumeihui@chinamobile.com
Liu Expires 6 May 2027 [Page 35]