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 31 EVM 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