What Is Mandate Repudiation?
Mandate repudiation is a descriptive name for a dispute in which a person denies a purchase that an AI agent made inside the authority they gave it, either by claiming the agent acted on its own or by denying they granted that authority at all. The purchase fell within the mandate; the claim says it did not. The claim can come from regret, a forgotten standing instruction or bad faith. It looks identical to a genuine case of agent error or overreach, and only evidence of the mandate, its status at the time of purchase and what the agent did against it tells the two apart.
Updated
What is mandate repudiation?
The phrase is not a defined term in the AP2 or Verifiable Intent specifications, or in the US payment rules quoted below. This page uses it to name a dispute pattern built from two established ideas.
Repudiation is an old security term. NIST SP 800-53 Rev. 5 defines non-repudiation as "Protection against an individual who falsely denies having performed a certain action" (NIST CSRC glossary). In agentic commerce the action being denied is delegation: the user granted a mandate, the agent acted on it, and the user later says otherwise.
Payments teams know the older version as friendly fraud. Reshmi Suresh, head of agentic commerce at Worldpay, lists the agent version among merchants' exposures in a July 2026 article: a false "my agent went rogue" claim, "Friendly fraud with a new excuse." The article adds: "Without evidence tying the agent's action to a specific authorized instruction, merchants have no way to challenge it." Not every repudiation is dishonest. A user can forget a standing reorder set up months earlier and dispute the charge in good faith.
Agent payment protocols aim to produce the evidence such a claim is tested against. Google's Agent Payments Protocol (AP2) promises "non-repudiable proof of intent from the user," and the AP2 specification says that in a dispute the mandates and their receipts "can be brought together to provide a non-repudiable picture of the transaction." Mastercard's Verifiable Intent takes the same approach with a signed credential chain.
How mandate repudiation works
A repudiation claim is tested against four records, and each has to exist from the moment of purchase:
| Question | Record that answers it |
|---|---|
| Did the user grant this mandate? | The signed mandate: who signed, when, with which key |
| What did it allow? | Its constraints: items, merchants, amount per purchase, total budget, expiry |
| Was it still in force? | Its status when the agent acted: not revoked, not expired, budget remaining |
| Did the purchase fit? | The order and authorization, compared with the constraints |
An illustrative case, with constructed numbers: a user sets up a monthly pet-food reorder capped at USD 80 and, three months later, disputes the October order, saying the agent bought it without asking. The platform produces the signed mandate, a decision record showing the mandate was active with USD 80 remaining when the agent ordered USD 64 of the same product, and the confirmation it sent the user. The claim is a repudiation. If the record instead showed that the user had cancelled the reorder the day before, the same words would describe a true claim, and the case would be agent overreach.
The third row is the hard one. A signed mandate proves what was allowed when it was signed, not that it was still active, or still had room, at the moment of purchase. Only a record written at decision time shows that.
Why mandate repudiation matters in real-time systems
Evidence is only as good as the moment it describes. If an agent checked mandate status against a copy refreshed every few minutes, its decision record can say "active" for a mandate the user cancelled thirty seconds earlier, and in a dispute that record works against the platform that wrote it. Write the decision record in the same transaction as the check, from the same rows the check read, and attach the mandate identifier the payment carries so the record can be joined to the issuer's.
For mandates, limits and decision records held in Tacnode, the check and the record commit together under full transactions, so the record describes exactly the state the agent acted on. The dispute itself runs through the network and issuer as it does today. Why agent decisions need transactional reads and writes is covered in ACID for agents.
FAQ
Related terms
Agent overreach names an AI agent acting beyond the authority it was given: wrong item, over budget, unapproved merchant, or after the mandate was revoked.
An agent mandate is a signed record of what a user authorized an AI agent to buy: one exact purchase, or constraints such as a budget the agent must keep to.
Mastercard Verifiable Intent is an open spec for signed proof of what a user let an AI agent buy, with limits that merchants and payment networks can check.
A decision ledger is an append-only record of automated decisions: what was decided, on what inputs, under which policy and authority, and what changed.
Authorization-time context is everything a payment or purchase decision must read when it authorizes: mandate status, remaining budget, limits and recent spend.
Agent hijacking is an attack that redirects an AI agent to an attacker's goals through instructions hidden in content it reads, such as a web page or email.