Mastercard Agent PayAgent Pay and Verifiable Intent

Agent Pay and agentic tokens

Agent Pay, launched in April 2025 with Microsoft, IBM and Braintree as launch partners, lets a registered and authenticated agent transact using an agentic token rather than a card number. The token is an extension of the network's existing tokenisation service, which matters: it inherits provisioning, lifecycle management and cryptogram infrastructure that already runs at scheme volume.

What is new is what the token carries. An agentic token is tied to a specific user, registered to a specific agent, and constrained by rules the user sets — merchant, category, amount, timeframe, usage. Those constraints are enforceable by the network at authorisation time, because the network is in the path.

Verifiable Intent

In March 2026 Mastercard published Verifiable Intent: an open, standards-based framework that links a consumer's identity, their specific instruction, and the outcome of the transaction into a single tamper-resistant record, producing a cryptographic audit trail all parties can consult in a dispute. It is designed to work with AP2 and is being integrated into Agent Pay's intent APIs.

The sequence is telling. A network with the most capable constraint-carrying credential in the market published, eleven months later, a framework whose entire purpose is to record intent — and then contributed it to a standards body. The implication is that the credential alone was not sufficient: you can enforce a limit with a token, but you cannot reconstruct with a token why the human wanted the limit, what they actually asked for, or whether what happened matched it.

What the network position gets you, and what it costs

Being in the authorisation path is a genuine advantage. Rules inside the token are enforced whether or not the agent's own software is well-behaved, whether or not the merchant integrated anything, and whether or not the agent was compromised. No customer-side policy engine can make that claim about a card transaction; a compromised agent can simply not call it.

The cost is expressiveness and reach. Token constraints are as rich as the token format allows and no richer; they apply to transactions on that scheme's rails; and the delegating firm does not own the evaluation, cannot version it as a policy document, and cannot get a rule-by-rule explanation of a decision made inside someone else's authorisation stack. For consumer card spend, that trade is often worth it. For a firm that must show an auditor which version of which policy authorised a payment, it is not sufficient on its own.

What it does not do

• Scheme-scoped: it governs transactions on Mastercard rails, not bank transfers, stablecoin settlement, or internal ledger movements.
• Constraint expressiveness is bounded by the token format; conditional and stateful rules do not fit cleanly inside a credential.
• The delegating firm does not hold the evaluation and cannot independently replay it.
• Verifiable Intent is early: published March 2026, contributed to FIDO the following month, with real-world adoption still building.

Where mnd8t sits relative to it