There's a good argument going around right now that an agent's log tells you what it did but keeps no record of what it meant to do — so you can't tell a bad decision from a manipulated one, because every operation an attacker needs is an operation the agent performs all day. The proposed fix is a declared-intent record, written before the call, that something can diff the action against.

I've been circling the same gap from a different side, and I think the two halves click together. The missing record isn't only what the agent meant. For any action a human approves, it's what the human saw.

The gap: displayed ≠ dispatched

Agents increasingly render UI — through A2UI, AG-UI, MCP-UI / MCP Apps, OpenAI's Apps SDK. The pattern is the same: the agent supplies structure, the client renders it, the human clicks, and an action fires. What none of these bind is the thing shown to the human and the payload that runs.

They're separate fields. A button's label is one thing; the dispatched params / context / args are another. The displayed amount comes from a data-model path; the charged amount need not reference it. So this is expressible in a fully conformant surface:

  • show "$1,188.00", settle "$11,880.00"
  • show "Open the invoice PDF", open a look‑alike host

No log is wrong afterward. The action log faithfully records the action that ran. There's just no artifact proving what the human was looking at when they approved it. For agentic payments and commerce, that's not a corner case — it's the surface.

The displayed surface and the dispatched payload are separate fields with nothing binding them; the action log records what ran but not what the human saw

The fix: bind consent to what was displayed

A small, additive primitive — a consent binding:

  1. At a user-activated action, after the surface resolves, derive a deterministic digest over the displayed content (labels, amounts, payee, the action's resolved target).
  2. Carry it — optionally signed — with the human's decision.
  3. The verifier recomputes the surface it's about to act on and refuses on mismatch.

That's "what you see is what you sign" (WYSIWYS), from trusted-path and hardware-wallet security, applied to agent tool-calls. It isn't anomaly detection and it isn't a guardrail that guesses at bad text. It's a join: recompute and diff. A record that isn't diffed is just a second log agreeing with the first.

The flow: displayed surface to consent digest signed by the human, carried with the action, verifier recomputes — match is Bound, mismatch is Refused

Why this is the strong record

Here's the part that matters, and it's why the two halves fit.

A declared-intent record is written by the agent — the party whose value is in question. A compromised agent writes a matching one and the check goes quiet. That's a known, honest limit.

A consent binding over what the human saw is signed by the human — the party that does not benefit from its value, on a surface they actually looked at. That's exactly the separation payments has leaned on for forty years: the authorization is written by a party that cannot also perform the settlement.

Agent-declared intent is signed by the agent (weak evidence); human consent is signed by the human, the party that does not benefit (strong evidence) — they compose

Google's AP2 (now continuing in the FIDO Alliance) builds this in as a "Trusted Surface" — the user authorizes a tamper-evident mandate on a non-agentic surface, with the agent treated as a potential attacker.

So the records compose rather than compete:

  • Fully autonomous (no human in the loop): a declared-intent record + chain-of-thought — weaker, agent-signed, but the only thing available.
  • Human in the loop: a consent record signed over the displayed surface — stronger, because the authorizer can't also perform the action.

AP2 defines this for payments and assumes a non-agentic Trusted Surface. What it doesn't define is how an agent-rendered surface becomes one. That's where this primitive lives: it's the binding that lets an A2UI / AG-UI / MCP-Apps surface be a verifiable approval surface, and it generalizes the property to every consequential action, not just payments.

Being honest about the limits

  • It doesn't catch the agent whose intent was the problem (emergent, not talked-into). Nothing on the human-consent side does; that's the autonomous-record's job, and it has the symmetric hole.
  • Reversal is unsolved in general. When a re-gate says no halfway through a sequence: the reversible prefix can be compensated (sagas), the irreversible tail has to be ordered last behind a final gate rather than undone, and the case that's both irreversible and mid-sequence has to be designed out — or it's exactly where a human belongs. The consent-bound, append-only record is what makes compensation precise (you can't compensate what you can't attribute); it isn't the reversal.
  • It costs a digest (and optionally a signature) on the approval path. Cheap, but not free.

Where it is

I wrote it up as a protocol-neutral draft with a normative byte layout and conformance vectors, and a runnable reference:

And I've opened it as a proposal with the ecosystems it touches — AG-UI (ag-ui-protocol/ag-ui discussion #3309) and AP2 (google-agentic-commerce/AP2 discussion #394), framed as define what the signature covers / how an agent-rendered surface meets the Trusted Surface bar.

If you build agent UI or agent payments: do you have anything that binds what the human saw to what runs — or only the action that ran? Feedback and per-protocol proposals welcome.

— Cleiton Augusto Correa Bezerra (github.com/cleitonaugusto)

Open to consulting and collaboration on agent security — threat modeling, consent/trusted-path design, and guardrail audits. If your team builds agent UI or agent payments and this is on your roadmap, I'd be glad to talk (async/written works best for me).