China Mobile

liumeihui@chinamobile.com

Individual submission 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 and the Agent Operation Authorization framework . The differences are summarized in Section 1.4.

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

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
	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)
	Claim separation (C-005 action evidence, C-007 evidence provenance, C-008 freshness); row-outcome semantics; failure handling (C-009)
	Exercise evidence: a result must report whether checks have been exercised into rejecting and unverifiable outcomes
	Evaluation state preservation: denied vs unobtainable vs stale are distinct facts with distinct protocol outcomes
	Post-session determinability: evidence remains verifiable after sessions, credentials, and agent instances are gone
	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
	Handoff chain: offers named by hash (chain binding of confirmation to delegation path)
	Context diversion: evidence must not be acceptable for a different actor, task, or authority boundary
	Cross-channel confirmation and dialog resumption semantics for out-of-band confirmation (CC3-1, CC3-4)

contains the full traceability matrix from mechanism to requirement.

In scope:

• A JSON action descriptor format, derived from and aligned with the "authorization_details" structure of OAuth 2.0 Rich Authorization Requests , 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 / COSE 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.
• 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 . 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 are protocol errors, which the charter places in scope.

Two prior individual Internet-Drafts addressed user confirmation of agent actions and have since expired without renewal: 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 () 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, and dependency-closure models of , the exercise requirements of , and the evaluation-state requirements of . Third, CHEQ couples confirmation with privacy-protected information collection; AACP separates concerns and defines only the confirmation exchange. The Agent Operation Authorization framework 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 (), 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 ) 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 , 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.

The terms "agent", "user", and "agent communication protocol" are used as in .

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

Confirmation Request (CR)

The message from AA to CS asking for confirmation of a specific action, as defined in .

Confirmation Evidence (CE)

The signed record of the user's decision, as defined in .

Verification

The procedure by which a verifier checks a CE against the operation it accompanies ().

Row outcome

As in : the verified status of a single claim row after verification processing, distinct from specification or implementation status.

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 when, and only when, they appear in all capitals, as shown here.

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

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 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 ().
• 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, ).
• MUST maintain replay state for the lifetime of each request ().

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).
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 ().
3. Is the evidence current? Established by the challenge (AA-generated nonce), the confirmed-at time, and the lifetime ().

A fourth property, aligned with , 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 (). 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 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.

Three flows are supported. Variant A — Tool call, single agent (RA == AA):

1. AA determines the operation requires confirmation (from API metadata, ).
2. AA constructs the AD () and CR ().
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 .

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 ).
5. CS signs the CE; RA relays it back to AA.
6. AA verifies the CE () before executing.

Variant C — Out-of-band confirmation: When the user is not reachable on the current channel, the CR carries channel requirements (); 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 and the resumption semantics of (CC3-1, CC3-4): an unobtainable confirmation is reported as a status outcome, not as a denial ().

The Action Descriptor is the object the user actually confirms. It is a JSON object conforming to the "authorization_details" entry format of 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.

type (string, REQUIRED)

An identifier for the action type, as in 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 .

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

render (object, OPTIONAL)

User-visible rendering metadata for the 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, ).

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 .

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 . Unknown fields MUST be preserved by intermediaries and included in digest computations.

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 ().
• 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 Section 2.1 and the rendering requirements of Section 3.2.3.
• The renderer MUST present an explicit accept and reject control, and MUST NOT default to acceptance.

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 (no duplicate member names, no numbers that lose precision).
2. Canonicalize using the JSON Canonicalization Scheme (JCS).
3. Compute SHA-256 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). defines how API metadata carries this mapping.

The CDDL 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"

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, generated as a UUID . Used for replay tracking ().

action-digest

The digest defined in . 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 : 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 (), 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 . See .

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 decision MUST produce evidence, not silence: preserving negative outcomes is the exercise requirement of and the evaluation-state requirement of . Absence of evidence, in contrast, means no collection was attempted or completed, and is reported by the separate status object of .

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 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 (). Binds "what the user saw" to the signed record, enabling a verifier to check that the fields requiring confirmation were actually exercised (, HE-1).

The CE is a JWS with compact serialization:

• Payload: the UTF-8 JCS canonicalization of the CE JSON object. JCS canonicalization makes the signature deterministic across JSON serializers.
• Signing algorithms: ES256 or EdDSA (Ed25519) 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: defines the CBOR form; signatures in the CBOR profile use COSE_Sign1 with the same payload semantics. 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 requirement).

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 : what is accepted is what was actually verified, no more.

A CE is bound to:

1. The action, by action-digest. A verifier recomputes the digest over the operation at hand (, 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 ().

The dependency-closure discipline of 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.

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.

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

1. Presence. If the operation requires confirmation (per 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 (). Violations: "stale" or "replay".
7. Policy. auth-context MUST satisfy the verifier's policy for the effect class (). Violation: "insufficient-assurance".
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.

Each row outcome maps to a distinct error signal. This distinct-outcome model is the protocol-level realization of the requirements in and CMN-12 of : a verifier must be able to determine whether a check failed or could not be completed, and the two cases must produce different signals.

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

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.

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.

In Variant B, the acting agent AA cannot reach the user; the requesting agent RA holds the user dialog. The flow of 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" (). RA can, however, drop the interaction entirely; the denial-signal property holds only for interactions that complete. This residual risk is noted in .

When the task reached AA through a signed handoff chain , 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 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 , whose prior context is named by digest only.

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 (distinguish an interrupted dialog from a terminated one) are preserved here: an interrupted confirmation flow yields "unobtainable" with reason "dialog-expired", not a denial.

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

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

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 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 (), consistent with the consent-sanitization guidance in . 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 Section 3.3.7.

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.

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.

CS keys MUST rotate with overlap exceeding the maximum evidence lifetime (). 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 . Long-horizon verifiers (auditors) SHOULD anchor key history in an append-only record, e.g., a SCITT-style transparency service .

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.

This document requests registration of:

application/aacp-confirmation-request+json

Structure: ; encoding: UTF-8 JSON.

application/aacp-confirmation-evidence+json

Structure: ; encoding: UTF-8 JSON; a JWS (RFC 7515) compact serialization whose payload is the JCS-canonicalized CE object.

application/aacp-confirmation-status+json

Structure: ; encoding: UTF-8 JSON.

A CBOR media type (application/aacp+cbor) is requested for the CBOR profile of , content-format TBD.

IANA is asked to create a registry "AACP Row Outcomes" with the values of (absent, invalid, unverifiable, mismatched, diverted, denied, stale, replay, insufficient-assurance, unexercised, success). New values require Specification Required .

The HTTP API error codes of (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.

References Normative References NIST Informative References Work in Progress. Work in Progress. Work in Progress. Work in Progress. Work in Progress. Work in Progress. Work in Progress. Work in Progress. Work in Progress. Work in Progress. Work in Progress. Work in Progress. Expired April 2026. Work in Progress. Expired September 2026. Work in Progress. IETF Approved 8 October 2026. OpenID Foundation World Wide Web Consortium W3C Recommendation.

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

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

{ "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" }

{ "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)))" }

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.

{ "request-id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "outcome": "unobtainable", "reason": "dialog-expired", "reported-at": "2026-10-31T11:59:02Z" }

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 the CS (Sec 4.2, 5.2)	1
RR-2	API annotation of confirmation-required operations and field-level confirm flags (Sec 5.1, 10)	1
RR-3	User-visible rendering metadata (render labels, value labels, formats) (Sec 5.1, 10)	1
RR-4	Cryptographic assurance that confirmation originates from the user, in delegated flows (Sec 4.4, 7, 9)	1
BU-1	Action evidence as a separated, digest-bound claim (Sec 7.1, 7.4)	2
BU-2	Evidence provenance via CS key identity and auth-context (Sec 7.2, 7.3)	2
BU-3	Freshness rules and lifetime bounds (Sec 7.5)	2
BU-4	Distinct row outcomes with terminal processing, no partial acceptance (Sec 8)	2
BU-5	Dependency closure: unresolvable inputs yield unverifiable, never inflated outcomes (Sec 7.4, 8.2)	2
HE-1	Exercise evidence: rendering-digest commits to the confirmation display the user actually saw (Sec 5.2, 7.4, 8.1 step 8)	3
HE-2	Denied decisions produce signed evidence, not silence (Sec 7.1, 9.3)	3,4
KO-1	denied / unobtainable / stale as distinct outcomes with distinct errors (Sec 8.2, 9.3)	4
WA-1	Post-session verifiability: detached signatures, key-history retention rules (Sec 7.2, 11.4)	5
WA-2	Effect classification (effect, reversible) (Sec 5.1)	5
CM-1	Verify-at-the-time-authorized and distinguish-failed-vs-incomplete (CMN-12) (Sec 8.2)	6
SV-1	Handoff chain binding by digest (Sec 9.2)	7
OK-1	Audience binding against context diversion (Sec 7.1, 8.1 step 4)	8
HO-1	Out-of-band confirmation with dialog-interruption semantics (Sec 4.4 Variant C, 9.3)	9
FE-1	Channel requirements in the CR, async reconnection-compatible confirmation (Sec 6)	10
RAR-1	Descriptor structure derived from authorization_details (Sec 5.1)	11
RAR-2	Consent-display sanitization inherited (Sec 5.2, 11.1)	11

Sources:

1. Sections 3.2.3, 3.3.6
2. claims C-005, C-007, C-008, C-009; row-outcome and closure rules
6. CMN-12
9. CC3-1, CC3-4

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.