What Is AACP? The Beginner's Guide to the Agent Action Confirmation Protocol (IETF Draft)

CodexFuse Team · 2026-11-05T12:45:58.607Z · 25 min read min read

What Is AACP? The Beginner's Guide to the Agent Action Confirmation Protocol (IETF Draft)

AI agents can now book flights, move money, and delete files on your behalf. The danger is not that they act, but that they act on a guess: a wrong parameter, a hallucinated approval, or a middle agent inventing the words "the user said yes." If you searched for what is aacp, the short answer is this: AACP, the Agent Action Confirmation Protocol, is a proposed IETF protocol that makes a human explicitly confirm an agent's side-effecting action — outside the LLM — and produces signed proof of that confirmation that any later agent or API can verify.

The aacp ietf draft, published on 2 November 2026, is three days old as of today, 5 November 2026. It is an individual-submission Internet-Draft, version -00, written by Meihui Liu of China Mobile. That makes it work in progress, not an IETF standard, and it expires on 6 May 2027 — 185 days after publication, with 182 days remaining — unless a newer version replaces it.

The draft's core idea is simple to state and hard to build: confirmation must happen programmatically, outside of LLM prompt inference, and the proof must be checkable by the agent that finally acts. Every confirmation is bound to the exact action by a SHA-256 digest — the same kind of digest a SHA-256 hash generator produces — so evidence for booking flight X cannot be replayed against booking flight Y even if every other field agrees.

This guide is agent action confirmation explained from the draft itself: what AACP is, the problem it solves, how its action descriptors and signed evidence work, and what it deliberately leaves out. Every fact comes from the draft text, and the draft's own limits are stated where they belong.

The protocol runs to 35 pages, and it sits in the IETF's agentproto orbit: the agentproto working group's charter was approved on 8 October 2026, 25 days before this draft appeared. Agents usually run on rented infrastructure, and the same discipline that goes into picking VPS hosting applies to picking a confirmation service: the trust anchor has to be auditable.

What Is AACP?

AACP is an agent action confirmation protocol: a proposed wire-level protocol and evidence format that defines what an AI agent must get confirmed, how the confirmation is bound to the action, and how a verifier processes and reports the result. It covers four pieces: 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 for JSON over HTTP with JWS signatures. A CBOR/COSE mapping is defined for constrained environments. A requirement traceability matrix in the draft maps each mechanism to its source requirement in the agentproto document set.

The draft calls itself "the missing piece" and positions itself deliberately 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 try to redesign how agents talk to each other.

No independent explainer of AACP exists yet. The draft text is the only page on the exact phrase, which is why this guide quotes the draft's own definitions and works through its own flight-booking example.

The Problem AACP Solves

AI agents invoke operations with side effects: writes to resources, creation of durable records, financial transactions, and delegated actions on remote systems. The draft names two properties of current agent architectures that make unconfirmed side-effecting operations hazardous. The first is fallible inference, and the second is untrustworthy intermediaries.

Fallible inference means 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, but side-effecting operations may not be. A wrong read costs a retry; a wrong wire transfer costs the money.

Untrustworthy intermediaries matter in multi-agent delegation, where 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 requirement documents already state the fix at the requirements level: confirmation for side-effecting operations must happen programmatically, outside of LLM prompt inference. APIs must be annotated with which operations require confirmation, and the annotation must carry user-visible names and descriptions of the attributes requiring confirmation, plus their mapping into the operation's JSON payload.

The same requirements extend to inter-agent communication: the invoked agent must be able to trust that the confirmation actually came from the end user, and not from a hallucination generated by the invoking agent. That needs protocol machinery that provides cryptographic assurances, not just a convention.

The gap AACP claims to fill is that the requirement documents deliberately stop at the requirements level. The security-focused documents explicitly decline to define the evidence format, and no document in the current set defines a protocol, message format, or evidence format that satisfies these requirements. This is the problem of human confirmation ai agent side effects: without a wire format, every agent vendor invents its own approval, and none of them can be checked by anyone else.

What Is an 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 RFC 9396, Section 2, with the extensions defined in the AACP draft. Reuse of the Rich Authorization Requests 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 that this profile inherits and addresses.

RFC 9396, OAuth 2.0 Rich Authorization Requests, was published in May 2023 as a Standards Track RFC by Torsten Lodderstedt, Justin Richer, and Brian Campbell. It introduced the authorization_details parameter because the OAuth scope parameter cannot express fine-grained requests such as "transfer 45 euros to Merchant A" or "give me read access to directory A and write access to file X." Its worked example is a payment_initiation object for a credit transfer of EUR 123.50 to Merchant A. The RFC is 3 years and 6 months old, and AACP builds directly on its shape.

AACP takes the typed-descriptor shape — a REQUIRED type field, actions, locations, and type-specific fields — and adds confirmation-specific metadata. The additions are per-parameter confirm flags, render metadata with labels and value-labels, effect and reversible classification, an expires timestamp, the action digest, and the signed evidence plus verifier model. AACP is explicitly not bound to the OAuth authorization-code flow.

Each parameters entry carries a REQUIRED value, an OPTIONAL confirm flag that defaults to false, and OPTIONAL render metadata. When confirm is true, that parameter MUST be rendered to the user as part of the confirmation. The render object holds a short human-readable label, a pre-formatted value-label, a format hint such as "currency" or "date", and a sensitive flag: when true, verifiers and logs SHOULD mask the value.

Rendering has strict rules. Every parameter with confirm set to true MUST be displayed with its label and either its value-label or a programmatic formatting of the value. Rendering MUST occur in a non-LLM programmatic component, and the descriptor, 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 inside them.

The renderer MUST present an explicit accept and reject control, and MUST NOT default to acceptance.

The action digest ties the descriptor to the evidence. The descriptor is built as I-JSON, canonicalized with the JSON Canonicalization Scheme (JCS, RFC 8785), and hashed with SHA-256. The digest is carried base64url-encoded without padding in JSON, and in binary in CBOR.

Verifiers MUST recompute this digest over the operation they are asked to execute, so a descriptor that was altered after confirmation no longer matches.

The Four Roles Behind Every Confirmation

AACP defines four roles, and the split between them is the whole security model. The confirming user is the human whose decision the evidence records. The Confirmation Service is the component that renders the action descriptor to the user through a non-LLM programmatic path, collects the decision, and signs the evidence.

The acting agent is the agent that will invoke the side-effecting operation and must present evidence that it was confirmed. The requesting agent is the agent in whose dialog with the user the confirmation is collected.

The Confirmation Service is the only role that holds a signature key in the base protocol. That 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 service 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 through a programmatic interface, not by embedding the request in an LLM prompt. A service that forwards the confirmation decision through an LLM inference step does not conform. It MUST render every parameter marked confirm as true with its user-visible label before presenting the decision control, MUST sign evidence with a key bound to a discoverable identifier, MUST NOT sign evidence for a decision it did not itself render and collect, and MUST maintain replay state for the lifetime of each request.

How the Confirmation Flow Works

The confirmation flow has six steps, and the same shape holds whether one agent or two are involved. The draft defines three variants of this flow: a single-agent tool call, a delegated action between two agents, and an out-of-band confirmation when the user is not reachable on the current channel.

1. The user asks the agent to do something with side effects, such as booking a flight or moving money.
2. The agent builds an action descriptor: exactly what will happen, with the key parameters flagged for display.
3. The agent sends a confirmation request to the Confirmation Service, carrying the action digest, a fresh challenge, and a lifetime.
4. The Confirmation Service shows the action to the human through a normal programmatic interface — never inside an LLM prompt — with explicit accept and reject controls.
5. The human decides, and the Confirmation Service signs the decision as confirmation evidence.
6. The agent presents the signed evidence with the operation, and the API or acting agent verifies it before executing.

In the single-agent variant, the requesting agent and the acting agent are the same entity: the agent determines the operation requires confirmation from API metadata, constructs the descriptor and the confirmation request, and invokes the operation presenting the evidence. In the delegated variant, the acting agent constructs the descriptor and request for its own operation, sends the request to the requesting agent over the agent communication protocol, and the requesting agent relays it to its Confirmation Service without altering the descriptor or the challenge. The digest and the challenge make alteration detectable.

The confirmation request travels over whatever agent communication protocol is in use. In a dialog managed by what PACE is — a dialog context that tracks one task's conversation — the confirmation request is one more message inside that dialog, while AACP supplies the confirmation object itself.

The request carries a UUID version 4 request-id, the action digest, a challenge of at least 128 bits generated by the acting agent, a lifetime in seconds, and an audience naming the acting agent. The draft's example lifetime is 300 seconds, which is 5 minutes.

The out-of-band variant covers the case where the user is not reachable on the current channel. The request carries channel requirements, such as a minimum level of assurance and acceptable modes like device push or SMS, and the Confirmation Service delivers the prompt through a pre-registered side channel and collects the decision asynchronously. An unobtainable confirmation is reported as a status outcome, not as a denial, and the next section explains why that distinction matters.

What Is Signed Confirmation Evidence?

Confirmation evidence is the signed record of the human's decision, and it is the object the acting agent presents with the operation. It carries the version, the same request-id, action digest, and challenge as the confirmation request, a decision of "confirmed" or "denied", the same audience and subject, a confirmed-at timestamp, and an authentication context describing how the user authenticated to the Confirmation Service at confirmation time. It may also carry a rendering digest and the digests of the handoff chain through which the task reached the acting agent.

Both decisions are signed. A denied decision MUST produce evidence, not silence, so a middle agent cannot hide a refusal by returning nothing. The authentication context reports the method — for example "passkey", "device-unlock", or "oauth-session" — and a level of assurance from 0 to 5, which is 6 levels in total.

It is an honest report by the Confirmation Service, covered by its signature, and verifiers MUST NOT infer more assurance than it states.

Only the Confirmation Service signs. The evidence is a JSON Web Signature (JWS) in compact serialization, and the payload is the UTF-8 JCS canonicalization of the evidence object, so the signature is deterministic across JSON serializers. ES256 or EdDSA signatures MUST be supported, and RS256 MAY be supported.

Algorithms MUST NOT be negotiated by the signer; the Confirmation Service key's registered algorithm set is authoritative. A CBOR mapping uses COSE_Sign1 with the same payload semantics.

That record is what signed confirmation evidence agent actions means in practice: every side-effecting call carries its own signed proof, bound to the action, the session, the acting agent, the rendering, and the delegation path. The binding rules are fivefold. The action digest binds the evidence to the action, so evidence for one booking cannot be replayed against another.

The challenge binds it to the requesting session, since only a service that processed this request signs evidence with this challenge. The audience binds it to the acting agent, so other agents cannot use it. The rendering digest, when present, binds it to what the user actually saw.

The handoff digests, when present, bind it to the delegation path.

Receipts and confirmations are different jobs. To see the contrast, read what AER-1 is: a receipt format that records what happened, while AACP evidence proves the user approved the action before it happened. The two complement each other, and AACP evidence is designed to be referenceable by audit systems by digest, not to replace them.

Freshness is anchored at the acting agent's challenge, not at Confirmation Service clocks: the acting agent does not need to trust service time, only its own clock and its own randomness. Evidence is current when verified within the lifetime seconds of the confirmed-at time. Key rotation rules protect old evidence: a Confirmation Service MUST overlap old and new keys for at least the maximum evidence lifetime it issues, and verifiers MUST accept keys valid at confirmed-at time, not only at verification time, so evidence stays verifiable after the session ends.

How Verification Works: Eight Checks, Eleven Outcomes

Verification runs in eight ordered steps, and each step produces a row outcome. First, presence: if the operation requires confirmation and no evidence is presented, the outcome is "absent". Second, signature: the JWS is validated against a resolvable Confirmation Service key, with an invalid signature giving "invalid" and an unresolvable key giving "unverifiable".

Third, action digest: the verifier recomputes the digest over the operation being executed, and a mismatch gives "mismatched". Fourth, audience: the evidence audience MUST equal the verifier's agent identity, or the outcome is "diverted".

Fifth, decision: the decision MUST be "confirmed", and a "denied" decision gives the outcome "denied". Sixth, freshness: the challenge MUST equal the challenge the verifier issued, the confirmed-at time plus the lifetime MUST not be in the past, and the request-id MUST NOT have been seen before, with violations giving "stale" or "replay". Seventh, policy: the authentication context MUST satisfy the verifier's policy for the effect class, or the outcome is "insufficient-assurance".

Eighth, exercise: for irreversible actions, the verifier may recompute the rendering digest and compare it, and a missing rendering digest gives "unexercised" when policy requires it.

All outcomes other than full success are terminal for the presented evidence, and the verifier MUST NOT partially accept. Conflating outcomes — for example, reporting "denied" for "unobtainable", or "invalid" for "stale" — is a protocol violation. The 8 verification steps produce 11 possible row outcomes, which is 3 more outcomes than steps, because the freshness and signature checks each split into two distinct failures.

Replay prevention is keyed by request-id. The verifying party MUST retain request-ids of accepted evidence for at least the confirmation request lifetime plus a margin. Because the request-id is carried inside the signed payload, an attacker cannot mint a fresh id for an old decision without the Confirmation Service key.

Denied, Unobtainable, and Stale Are Three Different Facts

Denied means the user decided against the action. Signed evidence exists with the decision "denied", agents SHOULD record it, and they MUST NOT silently retry. 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.

Unobtainable means the confirmation could not be collected: the user was unreachable on all channels, the Confirmation Service failed, or the dialog lifetime expired before collection. It is reported by the Confirmation Service as an unsigned status object, with a reason of "channel-unreachable", "dialog-expired", "cs-error", or "user-unreachable". An unsigned status is deliberately weaker than evidence: it is a report, not a decision, and it maps to confirmation_unavailable with retry-after-recovery semantics.

Stale means the user confirmed, but the evidence aged out before execution. It maps to confirmation_stale, and re-requesting is appropriate. The draft's own example of an unobtainable status uses a dialog-expired reason, reported at 11:59:02 UTC on 31 October 2026 for a request that was never answered.

These three facts must never be collapsed into one error. A user who said no, a user who could not be reached, and a confirmation that expired are different events with different correct responses, and the draft makes confusing them a protocol violation. That discipline is what lets an API gateway, an acting agent, and a human support desk all read the same failure and agree on what happened.

How APIs Declare Confirmation With x-aacp

APIs declare which operations require confirmation through metadata. For OpenAPI-described APIs, the draft defines an "x-aacp" extension object. The draft's example is a flight booking action with confirm-parameters for flight_number, fare_class, and total_price, plus render labels such as "Flight", "Cabin", and "Total price", with the total price formatted as currency.

Enforcement sits at the API, not just at the agent. An API whose metadata declares confirmation for an operation MUST reject the operation with confirmation_required when no valid evidence accompanies it. The API is the last-line verifier, and agent-side enforcement alone MUST NOT be relied upon, because an agent may be compromised or hallucinating — which is the threat this protocol exists to contain.

The draft's worked example makes the whole protocol concrete, and its values are illustrative placeholders, not real data. The action descriptor books flight UA123 from New York JFK to Los Angeles LAX, departing 20 November 2026 at 09:00 EST, for a passenger named A. Example, in economy, at a total price of USD 412.00.

The parameters flagged for display are the flight, the date, the passenger, the cabin, and the price, while the seat preference — a window seat — is part of the action digest but not part of the confirmation display. The example's own expires timestamp, 31 October 2026, predates the draft's publication date, which is a reminder that the example is illustrative, not a live booking.

The default REST mapping is one action descriptor per API request. Parameters map from request body fields by name, and locations maps from the endpoint URI. That keeps the protocol adoptable without a new transport: any JSON-over-HTTP API can declare confirmation in its existing OpenAPI document.

AACP vs CHEQ vs the Agent Operation Authorization Framework

AACP is not the first attempt at human confirmation of agent actions. The draft positions itself against two prior individual submissions that addressed user confirmation and have since expired: CHEQ, and the Agent Operation Authorization framework. Both are cited context, not rivals, and the draft states its differences from each precisely.

CHEQ — Confirmation with Human in the Loop Exchange of Quotations — lets humans confirm decisions and actions proposed by AI agents before those decisions are acted upon, and it also lets humans provide information required for tool invocation without disclosing that information to the agent. AACP differs in three ways the draft names: CHEQ is transport-embedded but verifier-implicit, with no verifier-side processing model; CHEQ predates the agentproto document set and does not trace to its requirements; and CHEQ couples confirmation with privacy-protected information collection, while AACP separates the concerns and defines only the confirmation exchange.

The Agent Operation Authorization framework enables verifiable delegation of actions from human principals to autonomous agents with fine-grained authorization, in two phases: a structured proposal converted to a JWT without the user's original natural language input, then an authorization token recording confirmed authorization for a specific operation. AACP differs because it is not bound to the OAuth authorization-code 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. AACP evidence is verified at action time against the operation's parameters, not presented as a bearer credential.

A related draft, on user-mediated credential delivery, places authorization decisions and credential delivery in the user's trusted context at the OAuth grant layer. The AACP draft calls that work complementary, not a rival: it operates at the grant layer, while AACP defines the confirmation object, binding rules, and verification semantics for the agent communication layer.

What AACP Does Not Do

AACP defines no new transport, discovery, or agent-identity mechanisms. It rides on existing or emerging agent communication protocols and API invocation mechanisms, presumes agent authentication is solved by the surrounding protocol, and requires only that identifiers be nameable. It also does not define how users authenticate to the Confirmation Service: it carries an authentication context describing how the user authenticated, not the authentication mechanism itself.

AACP does not stop prompt injection. Injected instructions can still cause an agent to construct an undesirable action descriptor, and AACP does not detect or prevent injection attacks. What it guarantees is that the constructed action, whatever it is, is shown to the user for an explicit, non-LLM decision before irreversible execution.

That bounds the blast radius of prompt injection to actions the user can see and reject.

AACP is not an audit system either. Its evidence is designed to be referenceable by audit systems by digest, not to replace them, and that is the job of audit trails such as what TRAIL is: TRAIL records agent calls after the fact, while AACP confirms them before they happen. The draft also leaves human-to-agent user interface design and client rendering of agent outputs out of scope; its rendering requirements are constraints on API metadata and on programmatic processing of that metadata, not interface design.

The residual risks are stated bluntly. A compromised Confirmation Service can sign fabricated confirmations for any action it is asked to confirm, and the draft calls that a catastrophic failure mode that is not further mitigated by the protocol. Suggested mitigations are hardware-held service keys, scoped acceptance, and auth-context recording.

Confirmation fatigue is also real: users approve without reading, and a protocol cannot fix that. CodexFuse has not built an AACP tool, and this guide promises none.

AACP Is Not the Other ACP

The name invites exactly one confusion, so here it is, once: AACP is not IBM and BeeAI's Agent Communication Protocol. That ACP was launched in March 2025 to power the BeeAI platform, was donated to the Linux Foundation later that month, and in August 2025 its team announced it was merging into the Agent2Agent protocol and winding down its own development. Its repository is now archived and read-only, its last SDK release was version 1.0.3 on 21 August 2025, and BeeAI now speaks A2A.

The two protocols share three letters and nothing else. IBM's ACP was a general agent-to-agent messaging protocol over REST, while AACP is a narrow confirmation and evidence protocol for human approval of side-effecting actions. They have different purposes, different authors, and different venues, and the IETF draft is three days old while the other ACP is already archived.

Sources

Meihui Liu, "Agent Action Confirmation Protocol (AACP)", Internet-Draft draft-liu-agent-action-confirmation-00, 2 November 2026. https://datatracker.ietf.org/doc/html/draft-liu-agent-action-confirmation-00

Meihui Liu, "Agent Action Confirmation Protocol (AACP)", plain-text version, 2 November 2026. https://www.ietf.org/archive/id/draft-liu-agent-action-confirmation-00.txt

Torsten Lodderstedt, Justin Richer, and Brian Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, May 2023. https://www.rfc-editor.org/rfc/rfc9396.html

Jonathan Rosenberg, Pat White, and Cullen Jennings, "Confirmation with Human in the Loop (HITL) Exchange of Quotations (CHEQ)", Internet-Draft draft-rosenberg-aiproto-cheq-00, 19 October 2025. https://datatracker.ietf.org/doc/draft-rosenberg-aiproto-cheq/

Dapeng Liu, Judy Zhu, and Suresh Krishnan, "Agent Operation Authorization Framework", Internet-Draft draft-liu-agent-operation-authorization-02, 15 March 2026. https://datatracker.ietf.org/doc/draft-liu-agent-operation-authorization/

IETF Datatracker, "draft-liu-agent-action-confirmation-00" bibliography entry, fetched 5 November 2026. https://datatracker.ietf.org/doc/draft-liu-agent-action-confirmation/00/bibtex/

IETF Author Tools, idnits check for draft-liu-agent-action-confirmation-00, fetched 5 November 2026. https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-liu-agent-action-confirmation-00.txt

IBM and BeeAI Agent Communication Protocol merge into A2A, announced 25 August 2025, verified through secondary reporting this run (no primary announcement page fetched).

Frequently Asked Questions

Is AACP an official IETF standard yet?

No. AACP is an individual-submission Internet-Draft, version -00, published on 2 November 2026. It is work in progress, not an RFC, not a standard, and not a working-group draft.

Its stated intent is the Standards Track, but that is an aim, not an approval, and the draft expires on 6 May 2027 unless a newer version replaces it.

Does AACP replace MCP or A2A?

No. AACP is a narrow confirmation and evidence layer that rides on existing agent communication protocols and API invocation mechanisms. It defines what must be confirmed, how the confirmation is bound to the action, and how a verifier processes the result, while MCP carries tool calls and A2A carries agent-to-agent messages.

The two layers compose rather than compete.

What is the difference between AACP and TRAIL?

AACP confirms before, and TRAIL records after. AACP produces signed evidence that a human approved a specific action before it ran, and the acting agent or API verifies that evidence before executing. TRAIL is an audit trail that records agent calls once they have happened.

One gates the action, and the other keeps the record.

Can an intermediate agent fake a confirmation?

Not without the Confirmation Service key. The action digest fixes the action before any middle agent sees the request, the fresh challenge gives the acting agent a freshness proof it controls, and the audience binding names the acting agent, so evidence cannot be diverted to another agent. The residual risks are a compromised Confirmation Service, which the draft calls catastrophic, and a middle agent that drops the interaction entirely, which the acting agent sees as an absent confirmation and must not execute on.

Does AACP stop prompt injection?

No. Injected instructions can still cause an agent to construct an undesirable action descriptor, and AACP does not detect or prevent injection attacks. What it guarantees is that the constructed action is shown to the user for an explicit, non-LLM decision before irreversible execution, which bounds the blast radius to actions the user can see and reject.