# Mastercard Verifiable Intent AI agents are taking on commerce decisions that used to require human review. [Mastercard Agent Pay](https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html), launched in 2024, established the infrastructure for registering and authenticating AI agents on Mastercard's network. [Verifiable Intent (VI)](https://verifiableintent.dev), the latest addition to Agent Pay, adds a cryptographic proof of authorization that travels with each transaction. Co-developed with Google and aligned with AP2 and UCP, VI is open-source and protocol-agnostic. ICME Preflight extends this stack with formal verification of enterprise policy compliance at the action level. Verifiable Intent proves user-to-agent delegation. Preflight proves enterprise-to-agent compliance. Together they form a complete chain of cryptographic accountability from user intent through agent execution to payment settlement. ### Architecture VI defines three layers: * **Layer 1**: The credential issuer (typically a payment network like Mastercard) signs the user's identity and public key. * **Layer 2**: The user signs their transaction constraints and binds the agent's key. * **Layer 3**: The agent signs the final fulfillment values that satisfy those constraints. Preflight inserts at Layer 3. Before the agent finalizes its L3 credential, it submits the proposed action to Preflight for formal verification against enterprise policy. Preflight returns a cryptographic proof receipt. The agent embeds that receipt in the L3 as an `agent_attestation` claim of type `urn:icme:preflight-receipt`. When the L3 credential reaches the merchant or payment network, both the VI delegation chain and the Preflight compliance proof travel together. ```mermaid sequenceDiagram participant Issuer as Mastercard (L1 Issuer) participant User participant Agent participant Preflight participant Verifier as Merchant / Network Issuer->>User: L1 (identity + key binding) User->>Agent: L2 (constraints + agent key) Agent->>Preflight: Verify proposed action Preflight->>Agent: SAT + zkML proof receipt Agent->>Verifier: L3 with agent_attestation Verifier->>Verifier: Verify VI chain Verifier->>Verifier: Verify Preflight proof ``` ### When to use this The combined Verifiable Inent + Preflight chain delivers the most value in commerce contexts where compliance must be provable, not merely logged: * **Regulated industries**: Financial services, healthcare, and insurance agents must demonstrate policy compliance to regulators and auditors without revealing the underlying policy or trusting the operator's logs. * **Enterprise procurement**: Purchasing agents operating under enterprise spending limits, approved vendor lists, and budget controls need provable enforcement before payment, not reconciliation after. * **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 operating in one organization can prove policy compliance to a counterparty in another organization without exposing the policy itself, thanks to the privacy-preserving proof receipt. * **Audit-grade dispute resolution**: VI provides the evidence chain (who authorized what). Preflight provides the compliance proof (the action satisfied stated policy). Together they support both new VI dispute categories that Mastercard has introduced: agent overreach and mandate repudiation. ### What this protects against The combined VI + Preflight chain is designed to defeat five failure modes that single-layer compliance cannot: **1. Agent overreach.** An AI agent acts within the user's stated constraints (VI) but violates enterprise policy. For example, 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 solver. There is no language to speak that changes the result. **3. Mandate repudiation.** A user 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 zkML proof receipts are cryptographically bound to the policy and the action. Any third party can verify them without trusting ICME, the operator, or the agent. **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. Preflight's zero-knowledge proof receipt confirms compliance without disclosing the policy. The verifier learns the result, not the rule. Each protection requires both layers. VI without Preflight cannot block agent overreach or defeat adversarial prompting. Preflight without VI cannot defeat mandate repudiation. Together, they form a complete chain of cryptographic accountability from user intent through agent execution to payment settlement. ### Quickstart The integration is a three-step pattern any agent platform implementing Verifiable Intent can adopt. #### 1. Verify the proposed action Before constructing your L3 credential, submit the proposed transaction to Preflight: ``` curl -s -X POST https://api.icme.io/v1/verifyPaid \ -H 'Content-Type: application/json' \ -d '{ "policy_id": "your-enterprise-policy-id", "action": "Send 250 USDC to vendor_2391 for invoice_88421" }' | jq . ``` Response: ```json { "check_id": "90484dac-f41e-47ee-9758-a2f63a4900b7", "result": "SAT", "blocked": false, "proof": "zk-proof-receipt-abc123..." } ``` A `SAT` result means the action satisfies enterprise policy. `UNSAT` means the action would violate policy. On UNSAT the agent must abort and not construct an L3. #### 2. Embed the proof receipt in the L3 credential If verification succeeds, embed the proof receipt as an `agent_attestation` in your Verifiable Intent Layer 3 credential: ```json { "iss": "agent_platform_id", "sub": "agent_id", "iat": 1717012345, "sd_hash": "...", "delegate_payload": [...], "agent_attestation": { "type": "urn:icme:preflight-receipt", "value": { "check_id": "90484dac-f41e-47ee-9758-a2f63a4900b7", "policy_id": "your-enterprise-policy-id", "result": "SAT", "proof": "zk-proof-receipt-abc123..." } } } ``` Per Verifiable Intent specification section 9.2, verifiers that do not recognize the attestation type are required to ignore the claim, not reject the credential. The integration is non-breaking. Standard VI verifiers continue to function. Preflight-aware verifiers gain the additional compliance signal. #### 3. Present to merchant and payment network When the agent presents L3, the recipient verifies the Verifiable Intent chain as defined in the spec (signature checks, sd\_hash bindings, key delegation, constraint satisfaction). A Preflight-aware verifier additionally validates the embedded proof receipt using the open-source JOLT-Atlas verifier or by calling Preflight's verification endpoint. Both checks succeed before the transaction settles: * 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 full schema for the `urn:icme:preflight-receipt` attestation type: | Field | Type | Description | | ----------- | ----------------- | --------------------------------------- | | `check_id` | string (UUID) | Unique identifier for this verification | | `policy_id` | string (UUID) | Enterprise policy that was evaluated | | `result` | string | `SAT` (allowed) or `UNSAT` (blocked) | | `proof` | string | Base64-encoded zkML proof receipt | | `timestamp` | string (ISO 8601) | When the verification ran | The `proof` field is independently verifiable. A merchant, payment network, auditor, or counterparty can confirm the verification result without trusting Preflight, the agent, or the agent's operator. ### Why this matters Pablo Fourez, Chief Digital Officer at Mastercard, framed the trust requirements for agent commerce: consumers need verifiable evidence that agents will follow instructions while maintaining privacy, merchants need assurance that an agent is authorized to transact, issuers must distinguish legitimate activity from fraud, and if something goes wrong, everyone needs facts, not guesswork. Verifible Intent gives the contract: the user's intent and the agent's authority. Preflight gives the enforceable proof that the agent's specific action complies with that contract. For regulated buyers, agent-to-agent commerce, or any cross-organization transaction, this matters because trust is no longer a single-party assertion. The user's intent, the agent's authority, and the enterprise's policy are each cryptographically bound and independently verifiable. The combined chain is portable across organizations, jurisdictions, and protocols. ### Reference implementation A reference implementation is in the works. It will include: * A wrapper that handles the Preflight call and L3 attestation embedding * Test fixtures with mock VI credentials * An end-to-end example: VI credential → user constraint signing → agent action → Preflight verification → L3 with embedded receipt → merchant verification ### Resources * [Verifiable Intent specification](https://verifiableintent.dev) * [Verifiable Intent on GitHub](https://github.com/agent-intent/verifiable-intent) * [Mastercard Agent Pay overview](https://www.mastercard.com/global/en/business/issuers/mastercard-agent-pay.html) * [Preflight API reference](https://docs.icme.io) --- # Agent Instructions: 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: ``` GET https://docs.icme.io/documentation/agentic-commerce/mastercard-verifiable-intent.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.