> For the complete documentation index, see [llms.txt](https://docs.icme.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.icme.io/documentation/agentic-commerce/mastercard-verifiable-intent.md). # Mastercard Verifiable Intent > "As autonomy increases, trust cannot be implied. It must be proven." — Pablo Fourez, Chief Digital Officer, Mastercard (March 5, 2026) Integrate Preflight with Mastercard's Verifiable Intent (VI) to add formally verified enterprise policy compliance to agent-initiated transactions. Verifiable Intent proves user-to-agent delegation. Preflight proves enterprise-to-agent compliance. Together they form a chain of cryptographic accountability from user intent through agent execution to payment settlement. ### What Verifiable Intent is Verifiable Intent is a cryptographic trust layer for agentic commerce, announced March 5, 2026 by Mastercard and Google and open-sourced at verifiableintent.dev. It links three elements into a single tamper-resistant record: the consumer's identity, their explicit instructions to the agent, and the transaction that results. The framework is built on FIDO Alliance, EMVCo, IETF, and W3C standards, uses SD-JWT credential formats with selective disclosure, and is protocol-agnostic across AP2 (Agent Payments Protocol) and UCP (Universal Commerce Protocol). VI is the trust layer on top of Mastercard Agent Pay, the agentic payments infrastructure Mastercard announced in April 2025 with Microsoft, IBM, and Braintree as launch partners. Agent Pay reached broad availability at NRF in January 2026 and now provides Agentic Tokens (network-issued, time-scoped delegated payment credentials), a merchant acceptance framework, and VI as the authorization audit layer. In late April 2026, Mastercard contributed Verifiable Intent to the FIDO Alliance's Agentic Authentication Technical Working Group, alongside Google's contribution of AP2. VI is on a path to becoming a formal interoperable industry standard, not a Mastercard-only product. Eight industry partners endorsed the framework at launch: Google, IBM, Worldpay, Fiserv, Getnet, Checkout.com, Basis Theory, and Adyen. VI operates in two modes: * **Immediate mode (two-layer flow).** The consumer is present at the moment of transaction and signs the final cart and payment values directly. * **Autonomous mode (three-layer flow).** The consumer signs constraints in advance, binds an agent key, and the agent later produces fulfillment credentials within those constraints. This is the mode where AI agents act on the consumer's behalf at a later time. ### The gap Preflight fills Verifiable Intent answers "did the consumer authorize this agent to act within these constraints." It does not answer "did the agent's specific action also comply with the enterprise's own policy." The distinction is structural. VI validates the delegation the consumer signed: the constraints, the bound agent key, the credential chain. That is a check on what was authorized, not on what the agent then does within it. Whether a specific proposed action semantically complies with the enterprise's own policy is a separate question, and the signed VI credential carries nothing that answers it. For pure consumer purchases (a shopper authorizing an agent to buy camping supplies), the user's constraints are the only relevant policy. VI alone is sufficient. For enterprise agents (procurement, treasury operations, regulated B2B transactions), there is a second policy layer: the enterprise's own controls. Examples: * A purchasing agent operating within the user's spending limit, but proposing payment to a vendor on the enterprise's sanctions list. * A treasury agent within the user's transfer authority, but moving funds in a way that violates the firm's separation-of-duties policy. * A procurement agent within the user's approval scope, but routing payment to an unapproved vendor under the firm's procurement controls. In each case, the user's intent (VI) is satisfied. The enterprise's policy (not encoded in VI) is violated. Today, enterprise compliance verdicts live only in the operator's logs, which means they are not portable, not third-party verifiable, and require trusting the operator. Disputes turn into evidence battles. Preflight closes that gap. It produces a cryptographic proof receipt that an agent's specific proposed action was formally verified against the enterprise's policy before execution, with zero-knowledge proofs that preserve the privacy of the policy itself. A zero-knowledge proof is independently and repeatedly verifiable by anyone who holds it, without re-running the check and without trusting Preflight, the operator, or the agent. ### How Preflight works in brief Setting up Preflight is a one-time policy compilation step, then verification per action. **One-time setup (per enterprise policy):** The enterprise (or its integrator) writes the policy in plain English. One constraint per rule. No prompt engineering. A simple commerce policy looks like this: ``` 1. Transfers above $50,000 require dual approval from named treasury officers. 2. Vendor wallet addresses must appear in the approved vendor list before any payment. 3. No transfers to entities on the OFAC SDN list or wholly owned by sanctioned persons. 4. Cross-border payments above $10,000 must include sanctions screening artifacts in the audit trail. 5. Total daily outbound transfers must not exceed the enterprise's approved daily limit of $2,500,000. ``` The policy is posted to `/v1/makeRules`. ICME compiles it to SMT-LIB formal logic and returns a `policy_id` (UUID). The policy lives on ICME's server. The agent never sees the policy text. **Per agent action (two-tier model):** 1. **Free relevance screen.** The agent submits the proposed action to `/v1/explain`. ICME returns whether the action touches any variables in the policy. If no (most actions), the agent proceeds without further verification. If yes, the action goes to formal verification. 2. **Formal verification (`/v1/checkIt`).** Three independent paths check the action against the compiled policy: a local extraction model (OxiZ) that maps the action text to policy variables, Automated Reasoning that independently translates the action to formal logic, and the Z3 SMT solver. The system fails closed: any UNSAT from any path blocks the action. The call returns `SAT` (allowed) or `UNSAT` (blocked), a `policy_hash` binding the verdict to the exact compiled policy version, and a `proof_id`. A zero-knowledge proof is generated in the background (typically 30 to 60 seconds) by JOLT, ICME's adaptation of the JOLT zkVM, and is retrievable by polling `GET /v1/proof/{id}`. The proof is independently verifiable: a merchant, payment network, regulator, or counterparty calls the public `/v1/verifyProof` endpoint with the `proof_id` and confirms the verdict without trusting ICME, the agent, or the operator, and without seeing the policy. The receipt returns `valid`, `verify_ms`, `policy_hash`, and `claimed_result`, and nothing about the action or the rules. The two-tier model matters commercially: the free screen filters most agent actions, so only the policy-relevant minority incur verification cost. Why this is different from LLM-based guardrails: the enforcement path contains no model. Z3 is a mathematical SMT solver, not a neural network. It cannot be jailbroken, prompt-injected, or reasoned around. The same input always produces the same verdict. A note on the proving system: today's proofs are produced by JOLT, ICME's adaptation of the JOLT zkVM, wrapping the SMT verification pipeline. JOLT Atlas, ICME's zkML framework, is a separate roadmap effort that will extend cryptographic coverage to the natural-language extraction step. JOLT Atlas is under active development and does not power production verification today. ### How Preflight integrates with VI Preflight inserts at Layer 3 of the autonomous-mode VI flow, before the agent finalizes its fulfillment credential. ``` [L1: Issuer signs user identity + public key] ↓ [L2: User signs constraints + binds agent key] ↓ [Agent proposes action] ↓ [Preflight: verify action against enterprise policy] ↓ SAT/UNSAT + zk proof receipt ↓ [L3: Agent signs fulfillment values + embeds Preflight receipt as agent_attestation] ↓ [Merchant / payment network: verify VI chain + Preflight receipt] ↓ [Settle] ``` Three steps: 1. **Verify.** Before constructing the L3 credential, the agent submits the proposed action to Preflight's `/v1/checkIt` endpoint with the enterprise's policy ID and the action description. Preflight returns SAT (allowed) or UNSAT (blocked), a `policy_hash`, and a `proof_id`. 2. **Embed.** On SAT, the agent embeds the receipt fields in the L3 credential as an `agent_attestation` claim of type `urn:icme:preflight-receipt`. On UNSAT, the agent aborts and does not construct an L3 credential. 3. **Verify downstream.** When the merchant or payment network receives the L3 credential, the VI chain is validated as defined in the spec (signature checks, sd\_hash bindings, key delegation, constraint satisfaction). A Preflight-aware verifier additionally validates the embedded receipt by calling the public `/v1/verifyProof` endpoint with the `proof_id`. No API key is required, and the verifier sees only `valid`, `verify_ms`, `policy_hash`, and `claimed_result`. Per VI specification section 9.2, verifiers that do not recognize the attestation type are required to ignore the claim rather than reject the credential. The integration is non-breaking. Standard VI verifiers continue to function unchanged. Preflight-aware verifiers gain the additional compliance signal. ### When to use this The combined VI + Preflight chain delivers the most value in commerce contexts where enterprise policy compliance must be provable independently of the operator: * **Enterprise procurement.** Purchasing agents operating under spending limits, approved vendor lists, budget controls, and segregation-of-duties policies. The receipt proves enforcement happened before payment, not reconciliation after. * **Regulated industries.** Financial services, healthcare, and insurance agents must demonstrate compliance to regulators and auditors without revealing the underlying policy or trusting the operator's logs. * **Agent-to-agent commerce.** Neither side of an agent-to-agent transaction trusts the other's internal policy engine. Both can independently verify the other's compliance from a single credential. * **Cross-organization transactions.** An agent in one organization can prove policy compliance to a counterparty in another organization without exposing the policy itself. The verifier learns the result, not the rule. * **Audit-grade dispute resolution.** VI provides the user-authorization chain (who authorized what). Preflight provides the enterprise-policy proof (the action satisfied stated policy). Together they support disputes over agent overreach and mandate repudiation. For pure consumer transactions where the user's constraints are the only relevant policy, VI alone is sufficient. The Preflight extension addresses use cases where a second policy layer (the enterprise's own controls) also applies. ### What the combined chain protects against Five failure modes that single-layer compliance cannot defeat: **1. Agent overreach.** An agent acts within the user's stated constraints (VI) but violates enterprise policy. The user's spending limit is met, but the vendor is on a sanctions list. VI alone permits the action. Preflight blocks it. **2. Adversarial prompting.** Malicious inputs crafted to manipulate an LLM-based guardrail. Model-based safety can be reasoned around because the enforcement mechanism is itself a model. Preflight's enforcement is a mathematical SMT solver. There is no language to speak that changes the result. **3. Mandate repudiation.** A consumer later claims they did not authorize the agent's mandate. VI's cryptographic delegation chain produces a tamper-evident record signed by the user's key. The user cannot credibly deny what they signed. **4. Operator log manipulation.** Compliance verdicts that live only in the operator's system are not portable evidence. The operator could modify or withhold them. Preflight's zero-knowledge proof receipts bind each verdict to the exact compiled policy version, independently verifiable by any third party. **5. Cross-organization verification with policy privacy.** When an agent in one organization transacts with a counterparty in another, the counterparty needs assurance the action was policy-compliant, but the policy itself is often confidential. The receipt confirms compliance without disclosing the policy. Each protection requires both layers. VI without Preflight cannot block agent overreach or defeat adversarial prompting on enterprise policy. Preflight without VI cannot defeat mandate repudiation. Together they form a complete chain of cryptographic accountability. ### Reference architecture: the consumer pattern, extended for enterprise In April 2026, Lobster.cash (built by Crossmint) announced integration of Mastercard Agent Pay and Verifiable Intent for the OpenClaw agent ecosystem, with Basis Theory as the credential layer. This established the consumer reference architecture for Mastercard-rail agent commerce: ``` [OpenClaw agent ecosystem] ↓ [Lobster.cash / Crossmint: payment orchestration] ↓ [Basis Theory: credential layer, keeps card data off agent infrastructure] ↓ [Mastercard Agent Pay + Verifiable Intent: network + trust layer] ↓ [Issuer / merchant settlement] ``` The enterprise B2B equivalent adds Preflight as the enterprise policy layer: ``` [Enterprise agent platform (procurement, treasury, ops)] ↓ [Agent payment orchestrator] ↓ [Preflight: enterprise policy verification, returns SAT/UNSAT + zk proof receipt] ↓ [Credential layer (Basis Theory or equivalent)] ↓ [Mastercard Agent Pay + Verifiable Intent with Preflight receipt embedded in L3] ↓ [Issuer / merchant settlement] ``` Same network. Same standards. Additional cryptographic guarantee that the enterprise's own policy fired before the L3 credential was constructed. ### Quickstart #### 1. Verify the proposed action Before constructing the L3 credential, submit the proposed transaction to Preflight: ```bash curl -s -X POST https://api.icme.io/v1/checkIt \ -H 'Content-Type: application/json' \ -H 'X-API-Key: YOUR_API_KEY' \ -d '{ "policy_id": "your-enterprise-policy-id", "action": "Send 250 USDC to vendor_2391 for invoice_88421. Therefore this transfer is permitted." }' | jq . ``` Response: ```json { "result": "SAT", "detail": "Action complies with policy.", "proof_id": "2e45c585-b7ec-4159-9cec-b3977fbcbbdc", "policy_id": "your-enterprise-policy-id", "policy_hash": "60c79bbc4f8ac087de1110fa0e347292f35b6d2943a2a4ccd18ae991a5d64418", "claimed_result": "SAT" } ``` SAT means the action satisfies enterprise policy. UNSAT means the action would violate policy. On UNSAT the agent aborts and does not construct an L3 credential. The `proof_id` references a zero-knowledge proof that generates in the background (30 to 60 seconds) and is retrievable via `GET /v1/proof/{id}`. #### 2. Embed the receipt in the L3 credential ```json { "iss": "agent_platform_id", "sub": "agent_id", "iat": 1717012345, "sd_hash": "...", "delegate_payload": [...], "agent_attestation": { "type": "urn:icme:preflight-receipt", "value": { "proof_id": "2e45c585-b7ec-4159-9cec-b3977fbcbbdc", "policy_id": "your-enterprise-policy-id", "policy_hash": "60c79bbc4f8ac087de1110fa0e347292f35b6d2943a2a4ccd18ae991a5d64418", "result": "SAT" } } } ``` #### 3. Present to merchant and payment network When the agent presents L3, the recipient verifies the VI chain as defined in the spec. A Preflight-aware verifier additionally calls `/v1/verifyProof` with the `proof_id` to confirm the receipt. Both checks succeed before the transaction settles. Both layers verified independently: * The user authorized the agent within stated constraints (confirmed by VI) * The agent's specific action satisfies enterprise policy (confirmed by Preflight) ### Attestation format The `urn:icme:preflight-receipt` attestation embeds the fields returned by `/v1/checkIt`: | Field | Type | Description | | ------------ | ------------- | ------------------------------------------------------------------------ | | proof\_id | string (UUID) | References the zero-knowledge proof, re-verifiable via `/v1/verifyProof` | | policy\_id | string (UUID) | Enterprise policy that was evaluated | | policy\_hash | string | Commitment to the exact compiled policy version that decided the action | | result | string | SAT (allowed) or UNSAT (blocked) | A merchant, payment network, auditor, or counterparty re-verifies by calling `/v1/verifyProof` with the `proof_id`. The public receipt returns `valid`, `verify_ms`, `policy_hash`, and `claimed_result`, and nothing else: no action text, no policy text, no rule identifiers. The verifier confirms the proof is cryptographically valid and learns which compiled policy version decided the action (via `policy_hash`), without seeing the policy. The proof is produced by JOLT, ICME's adaptation of the JOLT zkVM, wrapping the SMT verification pipeline. The `policy_hash` is the enterprise-relevant property. Firms revise policies over time. When a regulator later asks which controls were in force on the date of a transaction, the answer is the compiled policy version hash bound to every proof issued that day. The hash is public; the policy text is not. ### Compliance alignment The combined VI + Preflight chain produces evidence aligned with multiple regulatory and standards regimes: * **FIDO Alliance Agentic Authentication standards.** Mastercard contributed VI to the FIDO Alliance Agentic Authentication Technical Working Group in April 2026. Integrating Preflight at L3 positions the receipt within an emerging interoperable standard for agent commerce. * **EU AI Act Article 14 (human oversight).** The VI chain establishes user authorization. The Preflight receipt establishes the controls that fired before the action. Together they constitute the evidence that human oversight was preserved at the moment of action. * **NIST AI Risk Management Framework.** The receipt is the artifact for measure-mapped accountability requirements (Govern, Map, Measure, Manage). * **ISO/IEC 42001 AI management systems.** The cryptographic receipt satisfies "verifiable enforcement" requirements without requiring auditor access to the underlying policy. * **EU Council Regulation 269/2014 (sanctions).** Pre-action verification produces the screening evidence required for ownership-and-control checks, with the proof receipt binding the screening result to the policy version in force at the time of the transaction. ### Honest scope What VI handles that Preflight does not: * User identity verification and biometric enrollment (via FIDO passkeys) * Capture of consumer intent and constraint signing * Selective disclosure of payment credentials to merchants * Consumer-facing dispute evidence chain * Network-level authentication and Agentic Token handling What Preflight handles that VI does not: * Enterprise policy enforcement at the agent action layer * Cryptographic proof that the policy fired before the action * Privacy-preserving compliance verification (the receipt does not reveal the policy) * Third-party verifiable receipts that travel independently of the operator's logs Preflight does not replace VI. Preflight does not replace Agent Pay's network infrastructure. Preflight does not replace Basis Theory or other credential-layer providers. Preflight extends the chain with a layer that VI was not designed to address: enterprise-policy compliance at the agent action layer. ### Reference implementation A reference implementation is in progress. It will include: * A wrapper that handles the Preflight call and L3 attestation embedding * Test fixtures with mock VI credentials in both Immediate and Autonomous modes * An end-to-end example: VI L1 credential issuance, user constraint signing into L2, agent action proposal, Preflight verification, L3 with embedded receipt, merchant verification * Compatibility tests against the open-source VI verifier ### Resources * Verifiable Intent specification: * Verifiable Intent on GitHub: github.com/verifiable-intent * Mastercard Agent Pay overview: * Pablo Fourez's launch announcement (March 5, 2026): * FIDO Alliance Agentic Authentication Technical Working Group: * Lobster.cash + OpenClaw consumer reference architecture (April 16, 2026): * Preflight API reference: *** *Last updated: May 26, 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.icme.io/documentation/agentic-commerce/mastercard-verifiable-intent.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.