Verifiable Intent & AP4M support
The Decision Trust Protocol verifies Mastercard/Google Verifiable Intent (VI) credential chains inside the authorization decision, and enforces them statefully on the issuer side. This page documents what is implemented, how it maps to Agent Pay for Machines (AP4M), and the current certification status.
Mandate implements the open Verifiable Intent v0.1 specification (published by Mastercard, co-developed with Google, June 2026). Mandate is not a certified AP4M participant and does not claim Mastercard certification or endorsement. Scheme certification is being pursued via Mastercard Engage. VI chain verification is available in the engine and gated by configuration (see Configuration).
Why this layer exists
Verifiable Intent proves authorization integrity: a cryptographic, point-in-time record that an agent's action was within the scope a human delegated. It answers "was this action authorized?" — statelessly. It does not answer "has this agent already spent its budget today?" or "is this agent behaving like itself?". Those are stateful, behavioral questions an issuer must still answer at decision time.
DTP sits exactly there: it verifies the VI chain and then enforces it against live state — velocity, behavioral trust, geography, and the issuer's own thresholds — before returning APPROVE / DECLINE / STEP UP. VI and DTP are complementary by design: VI travels with the transaction; stateful enforcement lives with the issuer.
What is verified
When a caller presents a VI chain on POST /api/v1/authorize (field vi_chain), the engine runs the full normative VI v0.1 verification procedure as an inline pipeline step, before mandate and velocity evaluation. All checks below are mandatory; a presented-but-invalid chain is a hard decline, never a soft signal.
| Stage | What it checks |
|---|---|
| Layer 1 — credential | Issuer signature verified against a configured trusted-issuer JWKS; ES256 (EC P-256); expiry; well-formed vct; extraction of the user key from cnf.jwk. |
| Layer 2 — delegation | User signature verified against the L1 cnf.jwk; sd_hash binding to the presented L1; mandate reconstruction from SD-JWT disclosures; mode inference (Immediate vs Autonomous); cnf presence rules; checkout↔payment mandate pairing. |
| Layer 3 — execution | Agent signature verified against the L2 mandate cnf.jwk by kid match (self-asserted header keys rejected); selective sd_hash binding; checkout_hash / transaction_id cross-binding recomputed from the disclosed checkout_jwt. |
| Constraints | All eight registered VI constraint types evaluated against the fulfillment (see below), in STRICT or PERMISSIVE mode. Unknown constraint types in an open mandate are rejected regardless of mode. |
Registered constraint types
The verifier implements every constraint type registered in VI v0.1:
mandate.checkout.allowed_merchants mandate.payment.amount_range mandate.checkout.line_items mandate.payment.budget mandate.payment.allowed_payees mandate.payment.recurrence mandate.payment.reference mandate.payment.agent_recurrence
Agent key binding (proof of possession)
VI chains bind to agent keys; Mandate binds those keys to agent identities. At registration, an agent may supply a public key (public_key_jwk, EC P-256 or Ed25519) accompanied by a registration_proof — a compact JWS signed with the matching private key, carrying a fresh timestamp (±300s, replay-bounded) and an algorithm-confusion-hardened header. The verified key's RFC 7638 thumbprint is stored on the agent record.
When vi_require_agent_key_binding is enabled, a VI chain only verifies if the L2 mandate cnf.jwk matches that registered thumbprint. This is the difference between "a valid chain" and "a valid chain from this agent" — it prevents a well-formed credential from being replayed under a different, unverified identity.
Decision outcomes
VI verification contributes to the standard authorization response. The chain must also describe this transaction — the L3a payment amount and currency must match the request, or the transaction is declined. Three VI-specific reason codes can appear:
| Reason code | Meaning |
|---|---|
VI_VERIFICATION_FAILED | Chain structure, signature, or hash binding invalid. |
VI_CONSTRAINT_VIOLATION | L2 constraints not satisfied by the L3 fulfillment (e.g. amount over range, payee not allowed). |
VI_AGENT_KEY_MISMATCH | L2 cnf.jwk does not match the registered agent's proof-of-possession key. |
A verified chain sets vi_verified: true and vi_mode (immediate or autonomous) on the response, alongside the existing KYA score, risk assessment, and reason codes.
Mapping to Agent Pay for Machines (AP4M)
AP4M defines four capabilities. Mandate is an issuer-side decisioning layer, so it implements the Authorize capability fully, consumes credentials from the Discover capability, contributes to Execute-time verification, and intentionally defers Settle to the rails:
| AP4M capability | Mandate |
|---|---|
| Authorize implemented | VI chain verification + stateful enforcement of user-defined limits (per-transaction, velocity, MCC, geography, time) before APPROVE / DECLINE / STEP UP. |
| Discover consumes | Consumes credentialed agent identity (VI L1/L2, agent PoP key, DID). The KYA registry is an issuer-side trust cache, not a network credential issuer. |
| Execute partial | Verifies the agent-signed L3 execution layer and amount/currency binding at decision time. Voucher/micro-batch verification is on the roadmap. |
| Settle deferred | Out of scope by design — settlement and multi-rail guarantee remain with the network and issuer processors. |
Configuration
VI verification is off by default and controlled per deployment:
| Setting | Effect |
|---|---|
vi_trusted_issuer_jwks | JWKS of trusted L1 credential-provider keys. Empty (with verification required) ⇒ any presented VI chain is declined. Populate with the network's published L1 keys to accept chains. |
vi_constraint_mode | STRICT (default — unknown constraint types reject) or PERMISSIVE (unknown types skipped; known types still enforced). Open-mandate unknown types reject in both. |
vi_require_agent_key_binding | Default true. Require the L2 cnf.jwk to match the registered agent's PoP key. |
vi_allow_unverified_l1 | Default false. Test environments only — never enabled in production. |
Independent verification
The complement to verifying inbound VI chains is publishing verifiable outbound trust. Mandate's KYA trust certificates are compact JWS (EdDSA), and the signing keys are published as a JWKS at /.well-known/jwks.json — any party can verify a Mandate-issued agent trust certificate offline with standard JOSE tooling, no callback required. See the trust model.
Verifiable Intent v0.1 is built on SD-JWT (RFC 9901), JWS / JWK, and RFC 7800 key confirmation — no novel cryptography. Mandate's verifier uses the same primitives and is validated by an automated test suite that constructs complete issuer→user→agent chains with real P-256 keys and exercises tamper, rogue-issuer, expiry, constraint-violation, and key-mismatch cases.
Production issuer deployments are sales-led and certified via the Mandate integration program. Book a demo to discuss VI/AP4M alignment for your program.