How is authenticity enforced?

[yannick-cw]

Authenticity: How can a merchant be sure an agent's request accurately reflects the user's true intent, without errors or AI "hallucinations"?

This is one of the core principals, how does that work, e.g. if we are in human present mode.
Let's say I ask my agent to list prices in € but the original prices are in $. And it hallucinates some wrong currency conversion.
Based on that I approve the cart and buy it.

[kudzaishezharare]

for the human present mode, its the cart mandate generated and signed by the Merchant agent that contains contains the merchant-supplied USD amount, and that’s what the user approves, not hallucination the shopping agent displays.

a deterministic FX tool can be added to the shopping agent to display correct Euro values, but even if it miscalculates, the still shows the verifiable real USD total, so no hallucinated value can be approved.

[douglasborthwick-crypto]

One approach to the authenticity problem for on-chain data: rather than trusting the agent'''s representation of token balances or loyalty status, you can verify it server-side against the actual chain state.

We built InsumerAPI for this. An agent (or merchant) can call POST /v1/attest to get an ECDSA-signed boolean verification that a wallet actually holds a specific token on any of 37 chains. The signature is cryptographically verifiable, so even if the agent hallucinates a balance, the attestation endpoint returns ground truth.

This doesn'''t solve the currency conversion example you raised, but for any checkout flow involving on-chain loyalty tokens, memberships, or credentials, server-side attestation removes the agent from the trust equation entirely. The chain is the source of truth, not the agent'''s interpretation.

OpenAPI spec | MCP server

[chopmob-cloud]

@kudzaishezharare has the core AP2 answer right: the user approves the merchant-signed Cart Mandate, not the shopping agent's display, so a hallucinated FX value never becomes the approved amount. Two production additions that close the gap further, both live:

1. Verify chain state server-side, not the agent's claim. AlgoVoi payment verification checks the actual on-chain transaction against the requirement rather than trusting what the agent reports, across 8 chains. If an agent hallucinates a balance, a price, or a settlement, the server-side check fails it (same instinct as @douglasborthwick-crypto's approach).
2. Bind the receipt to the approved mandate bytes. At execution AlgoVoi emits a signed compliance receipt whose request_digest (RFC 9530 Content-Digest, signed under RFC 9421) is SHA-256 bound to the Payment/Cart Mandate. The executed action is provably the one the user approved; a value swapped in after approval breaks the digest and the receipt will not verify.

Authenticity in human-present mode is therefore two layers: the merchant signs what is true (the mandate), and a signed receipt proves the executed action matched it. The hallucinated display can never be the thing that settles.

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/protocols/ap2