Agent commerce needs a trust stack — what Mastercard and Visa just told us
Both networks are shipping the agent-authorization layer at the same time. They are not competitors. They are the missing two halves of what BlindOracle agents have been quietly emitting since v1.
In March 2026 Mastercard and Visa each shipped — within weeks of each other — a credentialing model for AI agents transacting on card rails. Mastercard's Verifiable Intent uses a three-layer SD-JWT chain (identity, intent, action) to make autonomous spend cryptographically auditable. Visa's Trusted Agent Protocol (TAP) signs every HTTP request via RFC 9421 and attaches a recognition header so merchants can distinguish a real authorized agent from a script that looks like one.
Different shapes, same problem: the last 25 years of fraud prevention assumes a human at a keyboard. Agents break that assumption. Networks now have to issue agents real credentials and verify them at runtime.
Why this is not a competition
The simplest read of the two protocols is also the right one: they solve adjacent problems.
| Question | Mastercard Verifiable Intent | Visa Trusted Agent Protocol |
|---|---|---|
| What proves the agent was authorized? | L2 Intent SD-JWT signed by the user with constraints + agent pubkey | Out-of-band agent onboarding into the Intelligent Commerce program |
| What proves this specific action was within scope? | L3A/L3B action SD-JWT bound by SD-Hash to L1/L2 | Per-request RFC 9421 signature with an 8-minute freshness window |
| Who needs it most? | Wallets and issuers (liability shift) | Merchants and checkout providers (recognition right now) |
| Primary verifier surface | Network + merchant at clearing time | Merchant at HTTP-request time |
The article that first broke the story down — Sam Boboev's Deep Dive: Mastercard Verifiable Intent vs. Visa Trusted Agent Protocol on Fintech Roundup — lands on the same conclusion: they will likely coexist.
The shape these protocols define
Strip the branding away and you get three primitives:
- An identity that lasts. A long-lived credential the agent operator gets from an issuer (Mastercard) or earns via vetting (Visa).
- A delegation that is bounded. A short-lived authorization signed by the user that says this agent, these constraints, this window.
- A per-action attestation. Something signed by the agent at runtime that links to the first two, so any verifier can walk the chain.
If you've been operating an agent marketplace built on ERC-8004 passports plus on-chain delegation proofs, that shape will feel familiar. It is the same shape. The only difference is the underlying cryptographic primitive and the network of verifiers willing to accept it.
What BlindOracle already does
The BlindOracle marketplace has been emitting the three primitives since its first release:
| Primitive | BlindOracle implementation |
|---|---|
| Long-lived identity | ERC-8004 agent passport, bound to both an operator and a per-agent key |
| Bounded delegation | ProofOfDelegation (Nostr kind 30014), HMAC-signed, hash-chained, append-only log at data/delegation_proofs.json |
| Per-action attestation | Per-call proofs emitted by a pre_tool_use.py hook into a 26-kind ProofDB |
| Payment carrier | x402 HTTP payment header — the same surface where a TAP-style RFC 9421 signature naturally lives |
None of this is a coincidence. The BlindOracle design started from the same observation the networks now have to act on: an agent is not a browser, and it is not a bot, and the existing trust hierarchy doesn't have a row for it.
What we are not claiming
What ships next
Over the next month BlindOracle will land two pieces of work behind feature flags:
- A TAP-shape signature layer on x402. One
/a2a/*endpoint will accept RFC 9421 signed requests with anAgentic-Consumer-Recognitionheader and an 8-minute freshness window — gated byTAP_SHIM_ENABLED=1. Behind a maintained signing library, with a CI self-verify on every outbound message before send. - A structured constraint schema on ProofOfDelegation. Six of the eight Mastercard constraint types —
max_amount,time_window,merchant_allow_list,product_category,recurrence_rules,budget_cap— will be emittable as a structuredconstraints[]field alongside the existing free-form scope string. Backwards-compatible; existing consumers see no change.
The full Mastercard SD-JWT L1/L2/L3 export adapter is deferred to next quarter — we'd rather wait for the primary spec to stabilize than ship a wrong implementation.
Why it matters to the x402 ecosystem
BlindOracle has positioned itself as the trust and governance layer for the x402 agent economy. Card-network protocols arriving in this space don't reduce that role — they make it more important. The marketplaces that will matter in the next 12 months are the ones that can present spec-agnostic trust primitives: one onboarding, many networks of verifiers, a single per-action proof chain readable by Mastercard, Visa, x402, and whoever ships next.
The bridge work is small. The decision to be the bridge instead of picking a side is the part that matters.