Verifiable Intent: Mastercard Architecture | AXD

The Announcement

The specification was co-developed with Google, aligned with Google's Agent Payments Protocol (AP2) and Universal Checkout Protocol (UCP), and designed to be protocol-agnostic. It was published as an open-source draft (v0.1) under the Apache 2.0 licence at verifiableintent.dev, with a companion GitHub repository. Launch partners include Google, Fiserv, IBM, Checkout.com, Basis Theory, and Getnet. Jorn Lambert, Mastercard's Chief Product Officer, framed the announcement in terms this Institute has been using since September 2024: "As AI agents begin to act more independently, it's essential that user intent remains clear, provable, and protected."

Pablo Fourez, Mastercard's Chief Digital Officer, was more direct: "As autonomy increases, trust cannot be implied. It must be proven. And if something goes wrong, everyone needs facts, not guesswork." This is not marketing language. This is the language of delegation design. And it signals a fundamental shift in how the payments industry understands its role in the age of agentic AI.

"In this new payments paradigm, trust becomes the product." - Pablo Fourez, Chief Digital Officer, Mastercard

This essay is a technical examination of the Verifiable Intent specification. It analyses the architecture, evaluates the design decisions, maps the specification against the AXD Institute's frameworks, and identifies both what Mastercard has achieved and what remains unaddressed. The claim of this essay is specific: Verifiable Intent is the most important contribution to agentic commerce infrastructure since Mastercard Agent Pay itself - and it is important precisely because it moves the conversation from "how do agents pay?" to "how do we prove that agents were authorised to pay?"

What Verifiable Intent Actually Is

At its core, Verifiable Intent defines a layered SD-JWT (Selective Disclosure JSON Web Token) credential format that creates a cryptographically verifiable chain binding three elements: identity (who authorised this), intent (what they authorised), and action (what the agent actually did). The specification's own abstract states it precisely: "Verifiable Intent (VI) defines a layered SD-JWT credential format that creates a cryptographically verifiable chain binding an AI agent's commercial actions to an end-user's explicitly stated purchase intent."

This is not a payment protocol. It does not move money. It does not replace Mastercard Agent Pay, Stripe's x402, or Visa's Intelligent Commerce platform. It is a trust layer - a cryptographic proof system that sits alongside any payment protocol and answers three questions that no payment protocol has previously been designed to answer:

The architectural significance is in the separation. By decoupling the trust proof from the payment rail, Mastercard has created something that can work across protocols - not just Mastercard's own Agent Pay, but Google's AP2, Stripe's x402, and any future payment protocol that emerges. The specification explicitly states it provides "integration mappings for AP2, ACP, and UCP" and is "extensible to other protocols." This is not a proprietary lock-in strategy. It is a standards play. And it is the first time a major payment network has attempted to standardise trust rather than transactions.

The Five Shifts

The Verifiable Intent specification opens with a framing that will be immediately recognisable to anyone who has read this Institute's work. It identifies five fundamental shifts from traditional to agentic commerce - shifts that map directly to the conceptual architecture the AXD Institute has been building since its founding. The specification does not cite AXD. It does not need to. The convergence is the citation.

The convergence between Mastercard's five shifts and AXD's founding principles is not coincidental. It is inevitable. When you examine the problem of autonomous agents acting in commerce with sufficient rigour, you arrive at the same structural conclusions: identity must include delegation, consent must be durable and constrainable, scope must be explicit, visibility shifts from the human to the system, and confidence requires new signal architectures. The AXD Institute arrived at these conclusions through design theory. Mastercard arrived at them through engineering practice. The fact that both arrived at the same place from different starting points is the strongest possible validation that these are not opinions - they are structural properties of agentic commerce.

The specification's framing of the identity shift is particularly significant: "From 'who are you?' to 'who are you, and who authorised this agent?'" This is the delegation design question expressed in protocol language. It acknowledges that in agentic commerce, identity is not a property of the transacting entity alone - it is a property of the relationship between the human principal and the agent. This is exactly what the AXD Institute's Know Your Agent essay argued in Issue 026: that agent identity is relational, not intrinsic.

The Three-Layer Delegation Chain

The technical heart of Verifiable Intent is its three-layer delegation chain - a cryptographic structure that binds identity, intent, and action into a single verifiable record. Each layer is implemented as an SD-JWT (Selective Disclosure JSON Web Token), and each layer cryptographically references the one above it, creating a tamper-evident chain from the credential provider to the agent's commercial action.

The architecture is elegant. L1 establishes identity - the credential provider (typically a bank or digital wallet) signs a long-lived credential that binds the user's identity to a public key. This is the root of the trust chain. L2 captures intent - the user creates a key-bound SD-JWT containing mandates that express their purchase intent. In immediate mode, these are final values (buy this specific item at this specific price). In autonomous mode, these are constraints (spend up to £200 per week on groceries from these approved merchants). L3 records action - the agent creates short-lived credentials that prove it acted within the constraints set by L2, splitting the proof into a payment mandate (sent to the payment network) and a checkout mandate (sent to the merchant).

The cryptographic binding between layers is achieved through sd_hash claims - each layer contains a hash of the layer above it, creating a chain that cannot be modified without detection. If any layer is tampered with, the hash chain breaks and the entire credential is invalidated. This is the same principle that underlies blockchain technology, but applied to a specific, bounded problem: proving that an agent's commercial action was authorised by a specific human with specific constraints.

From an AXD perspective, the three-layer architecture maps directly to the Delegation Design Framework's three core questions: Who is delegating? (L1 - identity), What are they delegating? (L2 - intent), and What did the agent do with that delegation? (L3 - action). The framework's seven dimensions of delegation - scope, duration, authority level, domain, reversibility, transparency, and accountability - are partially addressed by the constraint architecture in L2 and the audit trail in L3. The word "partially" is important and will be examined in Section 9.

"The three-layer delegation chain is the first time a payment network has formalised the relationship between human intent and agent action as a cryptographic structure."

The selective disclosure mechanism deserves particular attention. SD-JWTs allow the holder to reveal only the minimum necessary information to each party. The merchant sees the checkout mandate (what was purchased) but not the full payment details. The payment network sees the payment mandate (how much was charged) but not the full shopping cart. Neither party sees the user's full identity credential. This is privacy by architecture, not privacy by policy - a distinction that matters enormously in a world where agents will transact across thousands of merchants on behalf of a single consumer. The privacy architecture aligns with what the AXD Institute has called signal clarity - giving each party exactly the information they need to make trust decisions, and no more.

The Constraint Architecture

The specification defines eight constraint types that can be embedded in L2 mandates to bound agent authority. These are the machine-readable rules that determine what an agent is permitted to do - the operational envelope within which the agent must operate. They are, in AXD terms, the designed boundaries of the delegation.

The constraint architecture is the most practically significant element of the specification. It transforms the abstract concept of "delegated authority" into concrete, machine-verifiable rules. A consumer does not simply "authorise their agent to shop." They authorise their agent to spend up to £50 per transaction, at Tesco, Sainsbury's, or Waitrose, on grocery items only, between Monday and Friday, with a weekly budget cap of £200, and with human re-confirmation required for any single item over £30. Every one of these constraints is cryptographically bound to the L2 mandate and verifiable by any party in the transaction chain.

The approval threshold constraint is particularly important from an AXD perspective. It is, in effect, a designed human agent interaction trigger - a point at which the system is architecturally required to re-engage the human. This maps directly to the Autonomy Gradient Design System's concept of escalation boundaries - the thresholds at which an agent must transition from autonomous operation to human-confirmed operation. The fact that Mastercard has embedded this concept into a cryptographic protocol means that escalation boundaries are no longer just a design recommendation - they are an enforceable architectural property.

What the constraint architecture does not address is constraint evolution. The eight types are static - defined at delegation time and fixed until the mandate expires. There is no mechanism for constraints to adapt based on agent performance, market conditions, or trust accumulation. A consumer who has delegated grocery shopping to an agent for six months with perfect execution still operates under the same constraints as on day one. The Delegation Design Framework's concept of earned autonomy - where an agent's operational envelope expands as it demonstrates competence - has no expression in the current specification. This is a design gap, not a technical limitation. The SD-JWT format could accommodate dynamic constraints. The specification simply does not define them.

Two Modes of Execution

Verifiable Intent defines two execution modes that correspond to fundamentally different trust relationships between human and agent. The distinction is not merely technical - it reflects two different positions on the Autonomy Gradient, and the specification's handling of each mode reveals both the sophistication and the limitations of the current design.

Immediate mode (user-confirmed) represents the lowest autonomy level. The user is present, approves the shopping cart, and authorises the specific transaction. The agent is essentially a sophisticated checkout assistant - it may have found the products, compared prices, and assembled the cart, but the human makes the final decision. In this mode, L2 contains final values rather than constraints: the exact items, the exact price, the exact merchant. L3 is not required because the agent does not act autonomously. The cryptographic chain proves that the user was present and approved the specific transaction.

Autonomous mode (agent-delegated) represents higher autonomy levels. The user is absent. The agent acts within delegated constraints, making purchasing decisions on the human's behalf. L2 contains constraints rather than final values, and L3 is required - the agent must create short-lived credentials proving that its actions fell within the delegated authority. L3 splits into L3a (payment mandate, sent to the payment network) and L3b (checkout mandate, sent to the merchant), each containing only the information relevant to that party.

The two-mode architecture is a pragmatic design decision. It acknowledges that agentic commerce is not binary - it exists on a spectrum from fully human-controlled to fully autonomous. But the specification only defines two points on that spectrum. The Autonomy Gradient Design System identifies four canonical levels: supervised (agent recommends, human decides), guided (agent acts, human confirms), autonomous (agent acts within constraints), and anticipatory (agent acts proactively based on learned preferences). Verifiable Intent's immediate mode maps to the supervised/guided levels. Its autonomous mode maps to the autonomous level. There is no provision for the anticipatory level - the level at which agents begin to act based on inferred intent rather than explicit delegation.

This is not a criticism. It is a statement of scope. Version 0.1 of a specification should not attempt to solve every problem. But it is worth noting that the anticipatory level is where the most consequential trust challenges will emerge - and where the most significant commercial value will be created. An agent that can only act on explicit instructions is useful. An agent that can anticipate needs based on accumulated trust is transformative. The design of that transition - from explicit delegation to earned anticipation - is one of the central challenges of Agentic Experience Design.

The Open-Source Gambit

Mastercard's decision to open-source the Verifiable Intent specification under the Apache 2.0 licence is the most strategically significant aspect of the announcement - more significant than the technical architecture itself. By publishing the specification on GitHub and inviting developers, merchants, and payment enablers to contribute, Mastercard is making a bet: that broad participation will make the trust standard stick, and that the company that defines the standard will shape the market even if it does not own the standard.

This is the TCP/IP strategy applied to trust. When Vint Cerf and Bob Kahn published the TCP/IP specification, they did not attempt to monetise the protocol itself. They understood that the value would accrue to the services built on top of an open, universally adopted standard. Mastercard appears to be making the same calculation: if Verifiable Intent becomes the universal trust layer for agentic commerce, Mastercard's Agent Pay - which will integrate Verifiable Intent into its intent APIs - becomes the reference implementation. The standard is open. The best implementation is Mastercard's.

The partner list supports this reading. Google's alignment is critical - AP2 (Agent Payments Protocol) is the most widely adopted agent payment protocol, and Google's Stavan Parikh explicitly stated that "strong, interoperable trust infrastructure like Verifiable Intent that is compatible with Agent Payments Protocol is a natural accelerator for scaling agentic commerce." IBM plans to align Verifiable Intent with its orchestration layer. Checkout.com called it "an important move to ensure the right parties can cryptographically validate intent without oversharing sensitive data." Fiserv noted it "enables merchants to proactively reduce fraud, strengthen dispute outcomes, and maintain customer trust."

The competitive implications are significant. Visa's Intelligent Commerce platform has taken a different approach - building proprietary infrastructure rather than open standards. Stripe's x402 is open but focused on the payment rail rather than the trust layer. Neither has published anything comparable to Verifiable Intent's cryptographic proof architecture. If Verifiable Intent achieves broad adoption, it could become the trust standard that all payment protocols must support - including Visa's. This would give Mastercard a structural advantage not through market share but through standards influence.

"The company that defines the trust standard shapes the market - even if it does not own the standard."

What Verifiable Intent Gets Right

Before examining the gaps, it is important to acknowledge what Verifiable Intent achieves. This is not a marginal improvement. It is a category-defining contribution to agentic commerce infrastructure, and it gets several fundamental things right that no previous specification has addressed.

First, it separates trust from payment. Every previous approach to agent payments has embedded trust assumptions within the payment protocol itself. Stripe's x402 uses HTTP 402 status codes to negotiate payment terms. Visa's Intelligent Commerce uses tokenised credentials within its proprietary network. Mastercard's own Agent Pay uses intent APIs to communicate purchase parameters. All of these approaches conflate the question "can this agent pay?" with the question "should this agent be trusted to pay?" Verifiable Intent separates these questions architecturally. The payment protocol handles the transaction. Verifiable Intent handles the proof that the transaction was authorised. This separation is the single most important design decision in the specification.

Second, it makes delegation explicit. In traditional commerce, authorisation is implicit - the cardholder's presence (physical or digital) implies authorisation. In agentic commerce, the cardholder is absent. Verifiable Intent makes the delegation explicit, cryptographic, and auditable. The L1-L2-L3 chain creates a record that can answer the question "who authorised this, and what exactly did they authorise?" at any point after the transaction. This is not just a fraud prevention mechanism - it is a dispute resolution architecture. When an agent makes a purchase the consumer did not intend, the Verifiable Intent chain provides the evidence to determine whether the agent exceeded its constraints (agent fault) or the constraints were poorly specified (human fault).

Third, it respects privacy by architecture. The selective disclosure mechanism ensures that each party in the transaction chain sees only the information relevant to their role. This is not a privacy policy bolted onto an existing system - it is a structural property of the credential format. In a world where agents will transact with thousands of merchants on behalf of a single consumer, this architectural privacy is essential. Without it, the aggregation of transaction data across merchants would create surveillance capabilities that no consumer would accept.

Fourth, it is protocol-agnostic. By designing Verifiable Intent as a trust layer rather than a payment protocol, Mastercard has created something that can work across the fragmented landscape of agent payment standards. The specification explicitly provides integration mappings for AP2, ACP, and UCP, and is extensible to other protocols. This means that a single trust standard could provide consistent authorisation proof regardless of which payment rail the agent uses - a critical requirement in a market where protocol proliferation is creating interoperability challenges.

What Verifiable Intent Does Not Address

The four gaps identified in the AXD Institute's KYA regulation analysis - agent competence assessment, dynamic authority, multi-agent lineage, and cross-jurisdictional identity - remain open in the Verifiable Intent specification. This is not a failure of the specification. It is a statement of its scope. But it is essential to understand what Verifiable Intent does not do, because the gaps define the next generation of work required to make agentic commerce trustworthy at scale.

Agent competence is not assessed. Verifiable Intent proves that an agent was authorised to act. It does not prove that the agent was competent to act. An agent with a valid L1-L2-L3 chain could still make poor purchasing decisions - overpaying for products, selecting inappropriate substitutions, or failing to apply available discounts. The specification verifies authority. It does not verify capability. The AXD Institute's Trust Architecture identifies competence trust as the foundational layer - the layer without which no other form of trust is meaningful. Verifiable Intent addresses authorisation trust (Layer 2 in the AXD model) without addressing the competence trust (Layer 1) that should precede it.

Authority is static. The constraint architecture defines eight types of boundary, but all are set at delegation time and remain fixed until the mandate expires. There is no mechanism for constraints to adapt based on context. If a consumer's financial situation changes mid-week, the agent's spending authority does not automatically adjust. If an agent demonstrates consistent competence over six months, its operational envelope does not expand. The Delegation Design Framework's concept of earned autonomy - where trust accumulates and authority evolves - has no expression in the current specification. Dynamic authority would require L2 mandates that can be updated without invalidating the L1-L2 chain - a technically feasible extension that the specification does not currently define.

Multi-agent chains are not supported. The L1-L2-L3 architecture assumes a single agent acting on behalf of a single human. But the emerging reality of agentic commerce involves multi-agent systems - a personal assistant delegating to a shopping agent, which delegates to a negotiation agent, which interacts with seller agents. The Verifiable Intent chain binds one human to one agent. It does not address how authority attenuates through a delegation chain, how accountability is distributed across multiple agents, or how the original human's intent is preserved through successive delegations. Google's Agent-to-Agent protocol and Anthropic's Model Context Protocol are creating the infrastructure for multi-agent orchestration. Verifiable Intent does not yet provide the trust layer for that infrastructure.

Cross-jurisdictional recognition is undefined. A Verifiable Intent credential issued in the UK may not be recognised or enforceable in the EU, the US, or China. The specification does not address mutual recognition frameworks, jurisdictional equivalence, or the concept of trust portability that the AXD Institute identified in the KYA regulation essay. As agentic commerce is inherently global - an agent shopping across international merchants on behalf of a consumer - the absence of cross-jurisdictional provisions is a significant gap that will need to be addressed as the specification matures.

"Verifiable Intent answers the question 'was this authorised?' It does not yet answer the question 'should this have been trusted?' The distance between those two questions is the design space of AXD."

The Competitive Landscape After Verifiable Intent

Verifiable Intent reshapes the competitive dynamics of agentic commerce infrastructure. The identity schism between Mastercard and Visa - Agent Pay's tokenised delegation versus Intelligent Commerce's embedded intelligence - now has a new dimension. Mastercard has moved from building a payment protocol to defining a trust standard. This is a different kind of competitive advantage.

Visa now faces a strategic choice. It can develop its own trust standard - risking fragmentation in a market that desperately needs convergence. It can adopt Verifiable Intent - ceding standards influence to Mastercard. Or it can propose an alternative framework through a standards body like EMVCo or W3C - a slower path but one that avoids both fragmentation and capitulation. The identity schism documented in Issue 041 has deepened. It is no longer just about how agents authenticate. It is about who defines what trust means in agentic commerce.

Stripe's position is more nuanced. The x402 protocol is complementary to Verifiable Intent - x402 handles the payment negotiation, Verifiable Intent handles the trust proof. A Stripe agent could use x402 to negotiate and execute a payment while using Verifiable Intent to prove the payment was authorised. The two specifications are not competitors. They are layers. Stripe's decision to adopt or ignore Verifiable Intent will signal whether the company sees its role as a payment rail (x402 is sufficient) or a commerce platform (trust proof is required).

For the broader ecosystem - merchants, fintechs, agent developers - Verifiable Intent creates both opportunity and urgency. The opportunity is clear: a universal trust standard reduces the integration burden for supporting agent-initiated transactions. The urgency is equally clear: as Verifiable Intent gains adoption, merchants and payment providers that do not support it will be unable to accept agent transactions that require cryptographic proof of authorisation. In a market where PYMNTS Intelligence reports that 43% of CFOs expect high impact from agents for dynamic budget reallocation, being unable to accept agent transactions is a competitive disadvantage that will compound rapidly.

Verifiable Intent: Implications for Practitioners

Verifiable Intent is not just a payment specification. It is a design material. For practitioners of Agentic Experience Design, it provides the first concrete, implementable infrastructure for several concepts that have previously existed only as design principles. The implications are practical and immediate.

Delegation is now designable at the protocol level. The eight constraint types provide a vocabulary for expressing delegation in machine-verifiable terms. AXD practitioners designing agent experiences can now specify delegation not just as a user interface pattern (sliders, toggles, permission screens) but as a cryptographic structure that is enforced by the payment infrastructure itself. The delegation interface becomes a mandate authoring tool. The design challenge shifts from "how do we show the user what the agent can do?" to "how do we help the user express their intent in constraint-compatible terms?"

Trust transparency has a new mechanism. The tamper-evident audit trail created by the L1-L2-L3 chain provides the infrastructure for the trust architecture's transparency layer. AXD practitioners can now design trust dashboards that show consumers not just what their agent did, but cryptographic proof that the agent acted within its delegated authority. This transforms trust transparency from a reporting feature to a verifiable property - the consumer does not need to trust the agent's self-report because the cryptographic chain provides independent proof.

Escalation boundaries are now enforceable. The approval threshold constraint type means that human agent interaction triggers can be embedded in the payment infrastructure itself. An AXD practitioner designing a grocery shopping agent can specify that purchases over £30 require human confirmation - and this constraint is not just a UI rule that the agent can override, but a cryptographic boundary that the payment network enforces. The escalation boundary becomes an architectural property rather than a design guideline.

The design gap is now precisely defined. Verifiable Intent addresses authorisation, constraint enforcement, and audit trails. It does not address competence assessment, dynamic authority, multi-agent lineage, or cross-jurisdictional trust portability. These four gaps are the design space of AXD - the problems that cannot be solved by cryptographic protocols alone and require the designed, dynamic, contextual management of trust relationships. The AXD practitioner's role is now clearer than ever: to design the trust experiences that sit on top of the trust infrastructure that Verifiable Intent provides.

"Verifiable Intent provides the cryptographic proof that an agent was authorised. AXD provides the design that determines whether the agent should have been trusted. Infrastructure without design is plumbing without architecture. Both are necessary. Neither is sufficient alone."

March 5, 2026 will be remembered as the day a payment network published a trust specification. Not a payment specification. A trust specification. Mastercard did not simply enable agents to pay. It formalised the relationship between human intent and agent action as a cryptographic structure - and then open-sourced it. The architectural significance is not in the technology. It is in the recognition that in the age of agentic commerce, trust is not a feature of the payment system. It is the product the payment system must deliver.

The specification is version 0.1. It is a draft. It has gaps - significant ones that this essay has documented. But the direction is unmistakable. The payments industry is moving from "how do we process agent transactions?" to "how do we prove that agent transactions were trustworthy?" That question - the question of designed, verifiable, architecturally enforced trust - is the question that Agentic Experience Design was founded to answer.

Sources