What Is Mastercard Verifiable Intent?

What is Mastercard Verifiable Intent?

Mastercard introduced Verifiable Intent on March 5, 2026 as "a new open, standards-based trust layer for agentic commerce," built with Google and "Aligned with Google's Agent Payments Protocol (AP2) and Universal Commerce Protocol (UCP)." The announcement says it "creates a tamper-resistant record of what a user authorized when an AI agent acts on their behalf," and that it will be integrated into Mastercard Agent Pay's intent APIs "In the coming months."

The specification, open-sourced the same day, carries the status line "Draft (v0.1). Maintained by Mastercard; open to multi-stakeholder contribution." Its README states the problem: "When a human delegates a purchase to an AI agent, no party in the transaction can verify that the agent's actions actually reflect the user's wishes." A card authorization proves the credential, not the instruction behind it. Verifiable Intent adds that record as a chain of SD-JWT credentials, with selective disclosure so each party sees only what its role needs.

How Verifiable Intent works

In Immediate mode the user confirms an exact cart, and the chain has two layers. In Autonomous mode the user signs constraints and the agent builds the purchase inside them, which takes three:

1. 1.L1, signed by the credential provider, binds the user's identity and device key. Stated lifetime: about a year.
2. 2.L2, signed by the user's device key, carries the constraints and the agent's public key. Autonomous lifetime: 24 hours to 30 days.
3. 3.L3a and L3b, signed by the agent, carry the final payment values to the network and the final checkout to the merchant. Lifetime: about five minutes. Both carry the same hash of the checkout, so the payment provably refers to the checkout the merchant received.

The merchant verifies L3b and the network verifies L3a. Constraints are typed, and the constraints spec gives this example, which allows up to 10 purchases during March 2026, each between $10 and $50, with total spend capped at $500 (amounts are in cents):

{
  "constraints": [
    { "type": "mandate.payment.agent_recurrence", "frequency": "ON_DEMAND",
      "start_date": "2026-03-01", "end_date": "2026-03-31", "max_occurrences": 10 },
    { "type": "mandate.payment.amount_range", "currency": "USD", "min": 1000, "max": 5000 },
    { "type": "mandate.payment.budget", "currency": "USD", "max": 50000 }
  ]
}

An amount range can be checked against the purchase in hand. A budget or a purchase count can't: it depends on every purchase made before. The spec overview calls these network-enforced constraints and says they "cannot be verified by a stateless verifier — the payment network maintains cumulative state." The constraints spec's normative line is direct: "Payment networks MUST maintain stateful tracking of cumulative spend per L2 mandate pair when a mandate.payment.budget constraint is present."

Why Verifiable Intent matters in real-time systems

Verifiable Intent settles what the user allowed, not what has already happened under that allowance. Its security model states: "Transaction count and budget enforcement cannot be done cryptographically within VI alone — they require stateful tracking by the payment network." The network's running total covers the purchases it has authorized. It does not cover a purchase the agent platform has committed to but not yet submitted, a budget spread across several mandates, or a cancellation the user made in the platform's own app. The document also lists known limits of v0.1: it "does not define a credential-layer revocation protocol," and it "provides no mechanism to detect agent misbehavior within authorized bounds."

So an agent platform needs its own state when it decides to sign L3: budget net of purchases in flight, caps that span mandates, the mandate's current status and the agent's recent behavior. If that state lags, the network declines a budgeted mandate's overspend after the agent has built the cart, and nothing declines spend against a budget the network never sees. Mastercard's network and the issuer keep their own checks. Tacnode can hold the platform's side of the loop: mandate budgets, reservations and decision records, with transactional writes, so two agent workers cannot both reserve past one cap. The steps a shopping agent goes through are covered in how shopping agents buy.

FAQ