Signed Mandates and Agent Accountability
Why logs written by the agent cannot settle a dispute about what a user authorised, and how cryptographically signed mandates plus a hash-chained action record turn "the agent did it" into evidence someone can be held to.
A customer disputes a £180 charge. Your agent placed the order; your logs show it did; the customer says they never asked for it. Now decide who pays. Everything in the log was written by the process being questioned, from a conversation it summarised itself, so it is a claim rather than evidence. If the agent were compromised, or simply wrong, the log would look the same.
This is the accountability problem, and it is distinct from authorisation. Authorisation asks whether the action was permitted at the time. Accountability asks whether you can prove, afterwards, to somebody who does not trust you, what was authorised by whom. Agent systems broke the old answer because the old answer was that a human pressed a button in a session bound to their credentials, and now nobody pressed anything.
Mandates make intent a signed object
AP2, announced by Google on 16 September 2025 with more than sixty partners including Mastercard, PayPal, American Express and Adyen, addresses exactly three problems it names as authorisation, authenticity and accountability: proving the user gave the agent authority for a particular purchase, letting the merchant be sure the request reflects the user's intent, and determining who is accountable when a transaction is wrong (Google Cloud, 2025, Announcing Agent Payments Protocol (AP2)).
Its mechanism is the mandate: a tamper-proof, cryptographically signed digital contract, carried as a verifiable credential, that serves as proof of the user's instructions. Two are worth understanding as a pair. An intent mandate is signed before the agent acts, and for an unattended task it states the rules of engagement: price limits, timing, conditions. A cart mandate is signed after the agent has assembled a concrete basket and creates an unchangeable record of the exact items and price, so what the user saw is what they pay. The published specification has since renamed the second to checkout mandate and added a separate payment mandate shared with the network and issuer, which is a reasonable reminder that this is a moving standard rather than a settled one (AP2 glossary).
The architectural claim underneath is the part worth carrying into systems that have nothing to do with payments: transactions should be anchored to deterministic, non-repudiable proof of intent rather than to an interpretation of a conversation. A signature over a structured object survives disagreement. A transcript does not.
The competing standard takes a narrower cut. The Agentic Commerce Protocol, maintained by OpenAI and Stripe under Apache 2.0 and launched with ChatGPT Instant Checkout on 29 September 2025, standardises the checkout interaction and a delegated payment API in which a scoped payment token passes from buyer to merchant through the agent, so the agent never handles raw card details (Agentic Commerce Protocol). ACP constrains what the agent can do with a credential; AP2 records what the user meant. They answer different halves of the question.
What an action record has to contain
Outside commerce there is no standard, so the burden falls on the log. For an action to be attributable later, one record has to bind together facts that usually live in five systems:
- the workload identity and build digest of the process that acted,
- the user or mandate on whose authority it acted, and the audience-bound token it presented,
- the session and the parent action, so a sub-agent's call resolves to the request that spawned it,
- the model, model version and the exact tool call arguments,
- the content hash of every untrusted input in context at decision time,
- and the response from the enforcing system, not the agent's account of it.
That sixth item is what makes the record adversarial rather than self-reported. The payment service says a payment happened; the agent's claim that one happened is hearsay. The fifth is what lets you answer the question that always follows an incident, which is what did it read that made it do that.
Making the record hard to edit
Non-repudiation needs the log to resist the party who wrote it. The standard construction is a hash chain: each entry includes the hash of the previous one, so altering any record invalidates every later hash, and periodically publishing the head to a system with a different administrator makes silent rewriting detectable rather than merely difficult. Signing each entry with the workload's own SVID key binds authorship to an attested identity rather than to a service account shared across the fleet.
None of this is novel; it is what financial and certificate transparency systems have done for years. What is new is needing it for ordinary application actions, because the ordinary application action is now taken by something that reads attacker-controlled text.
When it breaks
A signature proves authorisation, not comprehension. A user who signs an intent mandate with a £500 ceiling after a persuasive agent summary has authorised £500. Mandates move the dispute from "did they agree" to "was the agreement informed", which is a better question to be arguing about but is not the same as safety.
Key custody decides who is really liable. If the mandate is signed by a key the agent platform holds on the user's behalf, the platform can produce a valid mandate for anything. The evidentiary value tracks how far the signing key sits from the agent, which is why wallet-held or device-held keys matter more than the signature format.
Logs are a disclosure surface. A record complete enough to reconstruct a decision contains the prompt, the retrieved documents and the arguments, which is regulated personal data plus, frequently, secrets. Retention and access control on the audit store are part of the design, not an afterthought.
Cross-organisation attribution needs a shared root. Inside one company, correlating agent actions is an engineering problem. Across a buyer's agent, a merchant and a payment network, it needs agreed identifiers and verifiable credentials, which is the actual reason AP2 and ACP exist and the reason two incompatible answers to it is a problem worth watching.
References and further reading
Every source this page cites, in the order it cites them. All of them open in a new tab.
- Google Cloud, 2025, Announcing Agent Payments Protocol (AP2) cloud.google.com
- AP2 glossary github.com
- Agentic Commerce Protocol github.com
7 flashcards for this concept
Click a card to reveal the answer.