Verifiable Intent

Verifiable intent is cryptographic proof that a person really authorised what an artificial intelligence (AI) agent did on their behalf, such as buying a product within a set budget from an approved shop. It ties together who the user is, what they told the agent it could do, and what the agent actually did, in a record that merchants, banks and card networks can check without having to trust the agent's own account of events.

The phrase is used in two ways. In general, it describes a goal shared by most agentic commerce designs, including the signed mandates of the Agent Payments Protocol (AP2). Since 5 March 2026 it is also the name of a specific open specification, Verifiable Intent (VI), which Mastercard announced and co-developed with Google. It is related to, but narrower than, an agentic mandate, which is the permission itself rather than the proof of it.

Picture a signed delivery note. You write down that a courier may collect up to three parcels for you, from one named depot, this week. You sign it, the depot checks your signature, and when the courier collects, the depot keeps a copy showing exactly what was handed over. If there is an argument later, the note settles it.

Verifiable intent does the same for AI shopping. When you tell an assistant to buy a tennis racket under a certain price, your phone signs that instruction with a key only you control. The assistant then signs what it actually chose. Anyone along the chain can check the two match, without seeing more of your personal details than they need. It does not stop an agent from making a bad choice within your rules; it proves what the rules were.

Card payment systems assume a person is present when a purchase is made, either at a till or typing details into a checkout page. Fraud checks, strong customer authentication under the EU's PSD2, and chargeback rules are all built around that assumption. When an AI agent shops alone, nobody in the chain can easily tell whether it followed the user's wishes, overspent or picked the wrong item. The specification's own documentation lists the resulting risks: merchants face disputes they cannot rebut, networks face unclear liability, and agent platforms carry blame without evidence either way.

Mastercard published the specification and a reference implementation on GitHub and at verifiableintent.dev under the Apache 2.0 licence. As of November 2026 it is marked Draft v0.1, maintained by Mastercard and open to contributions from others. It defines a chain of three linked credentials, each signed with a digital signature and each binding the key of the party below it:

1. Identity. The credential provider, such as a card issuer, issues a credential to the user that links their identity and payment card to a key held on the user's device.
2. Intent. The user signs a mandate with that device key, setting the agent's limits: amount range, approved merchants, allowed items, budget caps or recurrence.
3. Action. The agent signs the final checkout and payment details with its own key, proving they fall within the user's limits. One part goes to the merchant and one to the payment network, and the two cross-reference each other.

The specification has two modes. In immediate mode the user confirms the exact basket and only the first two layers are used. In autonomous mode the user sets limits in advance and the agent adds the third layer when it buys. The credentials use selective disclosure, a technique that lets each party see only the fields its role requires, so a merchant need not see the full card details and the network need not see every product description.

Mastercard said Verifiable Intent builds on work from the FIDO Alliance, EMVCo, the IETF and the W3C, and that it would be built into Mastercard Agent Pay. The specification includes mappings for AP2, the Agentic Commerce Protocol (ACP) and Google's Universal Commerce Protocol, so it is designed to travel inside those protocols rather than replace them. It sits alongside credential schemes such as network tokenization: the token protects the card number, while verifiable intent records what the token was allowed to buy. Visa's approach in Visa Intelligent Commerce pursues a similar aim through passkey-approved payment instructions.

The specification is explicit about what it does not cover:

• Disputes. Dispute resolution is out of scope. The record can show what was authorised, but card network rules still decide who pays when something goes wrong.
• Infrastructure. Key management, enrolment of credential providers and transport between parties are left to other systems.
• Regulation. References to PSD2 and strong customer authentication are informational only, and the authors make no claim that using it meets any legal requirement.
• Adoption. As a draft version 0.1, it may change, and it works only if issuers, agents, merchants and networks all implement compatible versions.

It also cannot make a user's instruction wise. An agent that buys a poor product within a properly signed budget has still acted with verifiable intent, which makes clear rules for delegated authority as important as the cryptography.

• Verifiable Intent specification
• Verifiable Intent on GitHub