Summary

  • A 2 November individual Internet-Draft proposes that a programmatic Confirmation Service show a user the marked parameters of an agent’s side-effecting action and sign the user’s decision outside LLM inference.
  • The acting endpoint would check that signature against the exact operation, its intended audience and a fresh challenge. The draft gives a signed refusal a different outcome from a user who could not be reached.

An agent can produce an immaculate sentence: “The user approved the payment.” The sentence has no hands, no button and no way to prove which amount was on the screen. The new Agent Action Confirmation Protocol draft puts the missing witness at the point of action. Before a booking, transfer, record change or delegated task reaches its target, a Confirmation Service must present the operation’s marked fields through a programmatic interface, collect an explicit yes or no, and sign the result. The service may live in the user’s app, an enterprise authorization system or a dedicated confirmation app. Its crucial property is that the decision path runs outside the agent’s language model.

The proposal gives the acting agent a job too: assemble a typed Action Descriptor for the operation it plans to perform. Each parameter that requires human confirmation carries a confirm=true mark and a user-visible label. The Confirmation Service must display every marked parameter before offering accept and reject controls. The descriptor is treated as untrusted display data; labels and values cannot become markup or instructions in the confirmation interface. An agent’s fluent paraphrase therefore cannot quietly replace the amount, destination or action that the human was asked to approve.

After the click, the Confirmation Service signs Confirmation Evidence. The verifier—an agent enforcement point or the API about to execute—recomputes a digest over the actual operation and compares it with the signed evidence. It also checks the service key against its own trust policy, the intended acting audience, the agent’s fresh challenge, lifetime and replay state. A receipt for one operation or one delegate cannot be carried into another. For irreversible actions, the draft recommends checking a rendering digest that records the fields shown to the user.

That extra test asks a sharper question than whether somebody clicked: what did the screen make visible before the click?

The draft is unusually strict about refusal. A signed denied decision means the user rejected the action and permits a retry only when the user starts one. Unobtainable means the service could not collect a decision and is reported as an unsigned status. Stale, replayed, mismatched, diverted and unverifiable evidence each receive their own outcome. These differences matter to a payments or records system: a missing phone, a changed amount and a human refusal demand different responses. The verifier cannot partially accept a failed receipt.

The IETF Datatracker lists this 2 November text as an individual submission. It specifies a proposed wire format and verification procedure; it offers no deployed transaction or interoperability result. The decisive next evidence would be an implementation in which an independent verifier rejects altered action fields, an omitted confirmation field and replayed evidence. Until then, the draft has put the right question on the table: whose signed record, tied to which exact action, lets the target believe the user said yes?