Mastercard Agent PayAgent Pay and Verifiable Intent
Mastercard's bet is that the credential should carry the constraint and the record should carry the intent — enforcement at authorisation, evidence for the dispute.
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.
| Launched | 29 April 2025 |
|---|---|
| Credential | Agentic tokens, extending Mastercard's tokenisation service |
| Constraint dimensions | Agent, merchant, category, spend limit, timeframe, usage rules |
| Enforcement point | Network authorisation |
| Verifiable Intent | Published 5 March 2026; contributed to FIDO April 2026 |
| Trust Framework | Identity, intent, controls, execution, intelligence; announced 30 September 2026 |
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.
The Trust Framework and agent intelligence
On 30 September 2026 Mastercard organised Agent Pay around a Trust Framework of five elements: identity, intent, controls, execution and intelligence. Alongside it came trust and intelligence services that combine identity, intent, behavioural and fraud signals to support authorisation decisions. The first is a probability score for whether a transaction was initiated by an AI agent, being rolled out for testing in the US. Cloudflare contributes web-side signals about AI-driven payment activity, combined with network signals in privacy-preserving environments. Skyfire contributes Know Your Agent technology for identifying and verifying agents.
The framework separates questions that are often run together. Identity and intelligence ask whether the agent is who it claims to be and whether its behaviour looks legitimate. Intent asks what it was asked to do. Controls ask what it is allowed to do. A transaction can pass every identity and fraud test and still be outside what the agent was delegated. Within Agent Pay, the controls element is the agentic token's rules, enforced at authorisation.
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.
- The trust and intelligence services score whether an agent is involved and whether its activity looks legitimate. A trusted agent can still act outside its delegation; that is a question for the controls element, which on the network is the token's rules.
Where mnd8t sits relative to it
Partly overlapping, mostly complementary. Agentic tokens enforce a bounded set of constraints at the network; a policy engine on the delegator's side evaluates the richer, stateful ones before a transaction is ever attempted and produces its own evidence. Verifiable Intent and mnd8t's evidence receipts are addressing the same gap from opposite ends of the transaction. The Trust Framework's signals about identity and behaviour are inputs mnd8t does not try to reproduce. Where the delegating firm also pays by bank transfer or from a wallet, mnd8t evaluates the same versioned mandate whichever rail executes, and its Authority Record shows the authority decision. What the network, bank or merchant subsequently did is shown by their own records.
Last reviewed 3 October 2026. Corrections: hello@mnd8t.com.