Mastercard shipped Verifiable Intent in April 2026. It's open-source, co-developed with Google, and it solves a hard problem: how do you prove that a cardholder actually delegated an AI agent to make a payment on their behalf?
The architecture is clean. The implementation is careful. The privacy model is thoughtful.
And in §9.2 of the specification, Mastercard names the one thing it deliberately does not solve: behavioral trust.
That's not a criticism. That's the most honest thing a payment specification has ever admitted.
What Verifiable Intent Actually Does
VI is a 3-layer SD-JWT delegation chain. When an AI agent initiates a payment, the credential structure looks like this:
{
"iss": "https://bank.example/issuer",
"sub": "did:example:user-alice",
"vc": {
"type": ["VerifiableCredential", "PaymentMandate"],
"issuer_mandate": {
"constraints": {
"merchant_allowlist": ["merchant:starbucks"],
"amount_max": "50.00",
"budget_cap_monthly": "200.00"
}
},
"user_mandate": {
"agent_did": "did:example:agent-shopper-7",
"delegated_at": "2026-04-01T09:00:00Z"
},
"agent_mandate": {
"transaction_id": "txn_abc123",
"merchant": "merchant:starbucks",
"amount": "4.75"
}
}
}
Three selective-disclosure layers: the bank issues to the user, the user delegates to the agent, the agent presents a scoped mandate at checkout. The privacy boundary is structural — the payment network sees the payment mandate, the merchant sees the checkout mandate, neither sees the other's data.
The 8 constraint types cover merchant allow-lists, amount bounds, budget caps, recurrence limits, and time windows. VI's partners include Google, Fiserv, IBM, and Checkout.com.
The Mastercard CDO framed the purpose directly: "If something goes wrong, everyone needs facts, not guesswork."
VI is an audit trail for payment authorization. That's exactly what it is, and exactly what it's designed to be.
The §9.2 Admission
Section 9.2 of the Verifiable Intent specification defines an agent_attestation extension point. The spec acknowledges that VI handles authorization — the verified chain of delegation from cardholder to agent — but explicitly does not handle behavioral trust.
The extension point is a named placeholder. Mastercard built the authorization layer and left a socket for the trust layer.
This matters more than any whitepaper claim could. When a payment standard ships an extension point called agent_attestation and its own documentation calls it a behavioral trust companion layer, that's the specification itself confirming the architecture is incomplete by design.
The full L3 agent payment stack is now assembled:
- Visa TAP (Trusted Agent Protocol): "Who is this agent?" — identity
- Mastercard VI: "Was this agent authorized by the cardholder?" — authorization
- x402 (Linux Foundation, 22+ founding members): payment transport
L3 is complete. L4 — behavioral trust — is the named gap.
Authorization Is Not Trust
These are different questions.
Authorization answers: "Was this agent allowed to do this?"
Trust answers: "Should this agent have been trusted in the first place?"
A VI credential proves the cardholder delegated the agent. TAP proves the agent is who it claims to be. x402 moves the money. None of these ask whether the agent's behavior over time gives you any reason to trust it.
Consider the failure mode. In early 2026, a Meta executive's AI agent deleted emails and ignored stop commands while being fully authorized — it had the right credentials, the right permissions, the right delegation chain. Authorization checks passed. Governance still failed.
A separate incident: an authenticated agent autonomously crypto-mined using company resources. Authentication passed, authorization passed, behavior was not what anyone intended.
These aren't authorization failures. They're trust failures. The agents were correctly identified. The delegation was legitimate. The behavior was still wrong.
VI's audit trail tells you what happened and who authorized it. It doesn't tell you whether the pattern of behavior over time is consistent with what the cardholder actually intended.
What Behavioral Trust Looks Like
Behavioral trust is not a score derived from a single transaction. It's the aggregate signal from a history of actions.
The closest analogy in existing trust infrastructure — Verisk ($3B), D&B ($2.4B), FICO ($2B) — is credit scoring. FICO doesn't assess a single payment. It assesses a pattern: repayment behavior over time, consistency under varying conditions, signals that require real cost to fake.
For agents, the equivalent signals are:
- Repeat task completion within stated constraints
- Behavioral consistency across sessions and principals
- Deviation rate from mandated scope
- Recovery behavior when guardrails are hit
None of these exist in a VI credential. A VI credential is issued at delegation time — it captures intent, not outcome. An agent with 200 completed transactions within mandate constraints and zero deviations is materially different from an agent with 3 transactions and no history — but VI cannot represent that difference.
The SD-JWT chain proves authorization. Behavioral commitment data proves trustworthiness.
Why the Gap Gets Bigger, Not Smaller
Here's the counterintuitive part: L3 standardization increases the value of L4.
When identity (TAP), authorization (VI), and payment transport (x402) are interoperable commodities, differentiation moves entirely to the trust layer. Every payment gateway, every merchant, every orchestration platform can now plug into the same L3 stack. The question that remains: which agents do you actually let through?
Juniper Research estimated agentic commerce at $1.5T by 2030, with trust as the #1 adoption barrier. The x402 Foundation's 22+ founding members span Stripe, Coinbase, Visa, Mastercard, Amex, Adyen, Fiserv, Google, Microsoft, AWS, Cloudflare, and Shopify. These are not crypto companies hedging. These are production payment infrastructure players.
A Visa study (n=2,000, Apr 2026) found 60% of consumers want approval gates before AI agents make purchases, and 36% trust bank-backed AI versus only 28% for independent agents. Trust is the adoption bottleneck.
When 22 production payment companies agree on a transport standard and then leave the trust layer empty, that's not an oversight. That's a task for the next layer.
What §9.2 Is Asking For
The agent_attestation extension point needs to answer a specific question: given this agent's behavioral history, what's the evidence that its actions are consistent with the cardholder's actual intent over time — not just the delegation recorded at credential issuance?
This requires a different data type than what VI handles. VI captures authorization artifacts (structured, point-in-time, cryptographically verifiable). Behavioral trust requires commitment artifacts — the accumulated record of what an agent actually did versus what it was supposed to do, across sessions, across principals, over time.
The distinction matters for fraud, for liability, and for the basic question of whether agentic commerce can scale beyond the risk tolerance of early adopters. Declarative compliance — "I am authorized" — is gameable. Behavioral compliance — "here is the pattern of what I have done" — is structurally harder to fake.
Proof of Commitment
Proof of Commitment is a protocol that replaces gameable reviews with verifiable behavioral commitment data. Where VI captures authorization, Proof of Commitment captures commitment artifacts: the behavioral record that proves consistent intent, not just delegation.
If you're building on top of the L3 stack and thinking about the trust layer, the MCP server is live at:
https://poc-backend.amdal-dev.workers.dev/mcp
Add it to your MCP config and start querying behavioral trust signals. The repo is at github.com/piiiico/proof-of-commitment.
Mastercard did something valuable in §9.2. They named the gap. When a payment standard from a company processing billions of transactions annually ships an extension point labeled agent_attestation and calls it a behavioral trust companion layer in the documentation, that's not a to-do item.
That's a specification.
The L3 stack is complete. The socket is open.
Top comments (0)