Never confuse a published standard with a deployed one.
As of this writing there are five parallel schemes claiming to authenticate AI agents at the point of payment: Visa TAP, Mastercard Verifiable Intent, Mastercard Agentic Tokens, Skyfire KYAPay, and Google AP2. Four are documented in enough detail to audit. The fifth is named only as a count — "five parallel approaches" — and never identified. My working assumption is that it is either the Agentic Commerce Protocol or Coinbase's x402. I cannot verify that. Nobody can, and that is itself the finding.
Here is what the disclosures do not contain. No latency figures. No throughput figures. No revocation propagation delay. No offline degradation policy. No directory pricing. No disclosed transaction volume. Not a single number that would let a risk committee size the operational exposure of adopting any one of the five.
Here is what they do contain, buried three layers down in partner lists: Cloudflare co-developed Visa TAP. F5, Fastly, and Akamai are Skyfire partners. Four edge vendors, two protocols, one physical fact — TLS terminates at the edge, HTTP headers are readable at the edge, rate and behavioral governance already runs at the edge. Agent identity will be enforced where the packets already stop.
That is the tell. This trust layer is being marketed as cryptography. It is being built as a directory, and it will be enforced at a chokepoint.
Context
Know Your Agent is the authorization middleware sitting between an autonomous agent and a payment rail. The problem it addresses is real and old. OAuth bearer tokens and SAML assertions answer one question: does this credential exist and is it valid? They do not answer the question that actually matters when a machine spends money on your behalf — who delegated this authority, within what boundary, and until when. A bearer token that leaks is a bearer token that spends. Every agentic commerce failure mode I have audited traces back to that gap.
The primitive stack is unremarkable. RFC 9421 HTTP Message Signatures, Ed25519, SD-JWT, JWT, and the legacy OAuth/SAML/OIDC family. The agent-facing orchestration layers are MCP and ACP. The settlement rails are Base, stablecoin transfer, and 16-digit network tokens. Nothing here is novel cryptography. All of it is mature, audited, boring. That matters for the conclusion I reach later.
Participation is where the story lives. Stripe, Shopify, Adyen, Worldpay, Microsoft, Coinbase, PayPal, Fiserv, Checkout.com, J.P. Morgan, PayOS, Firmly, VGS, Cloudflare, F5, Fastly, Akamai, and Experian all appear across the five schemes' ecosystems. Visa TAP launched with six partners. Mastercard's Verifiable Intent is open-sourced with four signatories. KYAPay has an IETF draft. AP2 was donated to the FIDO Alliance and carries 60-plus partners.
I spent 2026 chairing a working group on autonomous trading compliance. We wrote a standard requiring any agent executing more than 1,000 trades daily to hold risk reserves proportional to transaction frequency, with real-time human oversight in the loop. Two Hong Kong exchanges adopted it. What I learned in those rooms is that the hard constraint is never the signature scheme. It is who holds the revocation list, who is liable when the list is stale, and who pays for the directory. Those three questions are not answered in any of these five documents.
Core
The real technical question in this cycle is not cryptography. It is trust root ownership and revocation semantics. Every one of these schemes uses primitives in the acceptable security band. The divergence is in who operates the key directory, who carries revocation liability, and who defines the constraint vocabulary.
Visa TAP signs HTTP messages with Ed25519 and anchors trust in an agent public key directory that Visa operates. That is centralized, and centralized is not automatically wrong — it is accountable. There is a legal entity to serve, a regulator to answer to, and a commercial relationship to terminate. The cost is that the same directory becomes a single point of failure and a single point of commercial censorship. Visa also runs KYB/KYC on registered operators with public identity disclosure and annual re-certification. That is expensive and it is the correct expense.
Mastercard Verifiable Intent uses SD-JWT with key binding claims and anchors to the existing card network trust root plus the issuer. The substantive part is not the token format. It is the eight machine-verifiable constraint types — amount ceilings, merchant allowlists, budget caps, recurrence terms, and the rest. That is where the actual authorization semantics live. A signature that says "this agent may act" is worthless. A signature that says "this agent may spend up to X at merchants in set Y, no more than N times, until timestamp Z" is a contract.
Skyfire KYAPay issues a three-layer JWT — human principal, agent platform, agent instance — and is the only open-standard route with explicit stablecoin settlement support. It carries an IETF draft, which means it is the only one of the five with an external review process. That is a genuine quality signal and also a speed penalty. IETF consensus is slow, and slow is fatal when card networks are shipping.
Google AP2 issues signed Intent, Cart, and Payment mandates, covers cards, ACH, real-time payments, and Base stablecoin settlement, and has been donated to the FIDO Alliance. Google gave up control to buy adoption. That is a rational trade and it also means the governance body now owns a roadmap it did not design and cannot commercially prioritize.
The most valuable technical judgment in this entire cycle is the shift from proof-of-identity to proof-of-authorization, and it is directionally correct. Explicit, machine-checkable delegation constraints at the transaction boundary are a genuine fix for a known defect, not a rebrand. But I want to be precise about what it does and does not buy you, because the marketing does not make the distinction.
What it buys: a signed envelope that binds an agent instance to a principal, a scope, and a time window. What it does not buy: any guarantee that the relying party interprets that envelope's fields the way the issuer intended. Signature validity and semantic correctness are different properties. Only one of them is solved by Ed25519.
That distinction has a direct on-chain analogue, and this is where I think the most under-priced structural development sits. Mastercard's eight constraint types are functionally isomorphic to account abstraction session keys and scoped permissions — the ERC-4337 and ERC-7715 family. Both solve the same problem: bounded delegated authority with a revocation path. Both require the relying contract or merchant to enforce the boundary rather than assume it. These two authorization models are converging on the same interface from opposite directions, one from card network rails and one from smart contract rails, and the eventual interop point between them is worth more than any single protocol in this list. Alpha hides in the friction between chains. It hides in the friction between authorization models too.
The verification code that actually matters is not the signature check. It is the constraint audit, and almost nobody publishes theirs. Here is the shape of the one I run against any KYA envelope before I let a client's agent near a settlement rail: