Why Agent Identity Is the Missing Layer in Agentic Payments
Agent identity is the missing layer in agentic payments because commerce infrastructure still assumes a human is accountable for every sale, while software now initiates transactions on its own. A joint Visa and Artemis report, reported by Cryptopolitan, warns that when an attacker redirects an agent’s spending, responsibility may lie with the user, the platform, the model provider, or the merchant — a four-way ambiguity nobody has resolved.
That ambiguity is not theoretical. Chargeback rules were designed for human-speed transactions, not thousands of machine-to-machine transactions per minute, according to the same Visa and Artemis findings. When the payer is software, the entire accountability model inherited from card-present commerce needs re-examination.
This guide maps the frameworks that have emerged to answer that question: Know-Your-Agent (KYA), Visa’s Trusted Agent Protocol (TAP), Mastercard’s Verifiable Intent, and the x402 Foundation. It is written for developers evaluating agent-payment integrations who need a mental model before they ship autonomous spending flows.
The NIST Concept Paper: What Regulators Want to Know
NIST released its concept paper “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization” on 2026-02-05, formally asking for more detail on identification, authorization, auditing, non-repudiation of AI agents, and controls to prevent or mitigate prompt-injection attacks, according to the NIST concept paper listing.
The NIST’s announcement frames the same set of asks. Four of them are structural: identification, authorization, auditing, and non-repudiation. The fifth — prompt-injection mitigation — is treated as a first-class security concern rather than an afterthought, which matters enormously in payment contexts where a manipulated agent can move real money.
The public comment period closed 2026-04-02. Industry responded with the frameworks covered in this guide, each of which addresses some but not all of NIST’s asks.
Know-Your-Agent: The Interoperability Framework
Know-Your-Agent (KYA) is an interoperability framework announced on 2026-09-09 by Ant International, Mastercard, and Visa, focused on operator traceability, shared certification requirements, and continuous transaction monitoring, developed through the BuildFin.ai platform convened by the Monetary Authority of Singapore, according to TechNode.
KYA is a coordination effort, not a payment rail. Its stated goal is to help card networks, digital wallets, agent platforms, and online marketplaces identify and onboard trusted AI agents while preserving each network’s own verification and risk-control processes, as reported by Cryptopolitan.
Three pillars carry the framework: operator traceability, shared certification, and continuous monitoring. The named reference points are Visa’s Trusted Agent Protocol, Mastercard’s Verifiable Intent, and Ant International’s Agentic Mobile Protocol. KYA describes what coordination should look like across ecosystems; it does not replace authorization, checkout protocols, or settlement infrastructure.
Visa Trusted Agent Protocol: Signing Agent Identity Into Every Request
Visa’s Trusted Agent Protocol (TAP) is an open specification that signs an AI agent’s identity into HTTP request headers using HTTP Message Signatures (RFC 9421) with Ed25519 signatures and a Visa-operated directory of agent public keys, so merchants can cryptographically verify an agent is legitimate before checkout, per Visa’s developer documentation.
TAP builds on the Web Bot Auth pattern. Agents are vetted through Visa’s Intelligent Commerce program and each is issued a unique key. Visa describes the resulting signatures as merchant-specific, purpose-specific, time-bound, and non-replayable and non-relayable, which is a meaningful distinction from bearer tokens that can be lifted and reused.
The implementation repository and a protocol summary confirm TAP is an identity wrapper that sits in front of any payment rail, layering on top of agent-commerce protocols such as ACP and UCP. Visa states the product remains in the process of development and deployment — the specification is open, but the deployed surface is still maturing.
Mastercard Verifiable Intent: From “Who Are You?” to “Who Authorized You?”
Mastercard’s Verifiable Intent, announced 2026-03-05 and co-developed with Google as part of Mastercard Agent Pay, shifts the framing from “who are you?” to “who are you, and who authorized this agent?”, using three layers — Identity, Intent, and Action — with SD-JWT delegation chains where each layer cryptographically constrains the next, according to pymnts.
The Draft v0.1 specification describes eight machine-verifiable constraint types, including amount bounds, merchant allowlists, budget caps, and recurrence terms — all cryptographically bound rather than merely asserted in a policy document. Consent becomes a durable artifact verifiable after the fact, and scope must be explicit and enforceable across merchants over days or weeks, not just at a single checkout.
Selective disclosure is the default: data stays private unless revealed to the right party at the right time. The framework publishes protocol-agnostic integration mappings for AP2, ACP, and UCP, so it can sit alongside existing agent-commerce flows rather than replacing them.
x402 Foundation: Agent Payments Without Accounts or Cards
The x402 Foundation was declared operationally live by the Linux Foundation on 2026-07-14, formalizing what Coinbase and Cloudflare co-originated in September 2025 into a vendor-neutral governance body with 40 member organizations, reviving the HTTP “402 Payment Required” status code so agents can pay per call with no accounts, subscriptions, or card entry, per the launch report.
Seventeen premier members hold governing board seats, among them Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, MoonPay, Ripple, Shopify, Stripe, and Visa. The official x402 site documents the flow: an agent hitting a paid endpoint gets a 402 response, pays, and retries. For a deeper walkthrough of that loop, see how x402 pay-per-call flows work.
The reference implementation is Apache 2.0 and the specification is payment-method agnostic, though real settlement today runs mainly on USDC on Base. x402 answers “how does an agent pay for access to this resource?” — it does not by itself establish who operates the agent or whether a user authorized the payment.
x402 On-Chain Adoption: What the Data Shows
Chainalysis reported on 2026-06-03 that x402 agentic transactions on Base grew from near-zero in Q3 2025 to well over 100 million cumulative transactions through Q1 2026, with early growth driven partly by the PING meme-coin experiment, according to Chainalysis.
PING, a pay-to-mint experiment using 1 USDC per mint, processed over 150,000 transactions in its first month and saw weekly transaction growth of over 10,000%, per the same Chainalysis report. The report notes transactions of $1 or more now represent 95% of total value transferred, up from 49% in early 2025 — a signal of maturation beyond micro-speculation. For a broader look at how settlement stacks compare, see our deep dive on agent payments settlement stacks.
The Chainalysis data also describes agentic-payment operators as typically younger wallets that hold 550% more asset types but carry smaller balances than typical Base users. Growth moderated in Q1 2026 as speculation cooled. Galaxy’s research coverage offers a secondary read on the same trend. The honest conclusion: usage metrics demonstrate activity, not safety, reliability, consumer protection, or resolved liability.
Comparing the Three Protocols: TAP vs. Verifiable Intent vs. x402
Each protocol answers agent-trust questions differently: TAP focuses on cryptographically signing agent identity into HTTP requests for merchant verification, Verifiable Intent layers identity with user-set intent constraints using SD-JWT delegation chains, and x402 eliminates accounts entirely by using HTTP 402 for pay-per-call settlement, per Visa’s documentation, the Verifiable Intent spec, and the x402 Foundation launch report.
Protocol Comparison: Visa TAP vs. Mastercard Verifiable Intent vs. x402 Foundation
| Dimension | Visa Trusted Agent Protocol (TAP) | Mastercard Verifiable Intent | x402 Foundation |
|---|---|---|---|
| Announced | 2026 (with Visa Intelligent Commerce) | 2026-03-05 | Formalized 2026-07-14 (origin Sep 2025) |
| Primary focus | Cryptographic agent identity in HTTP headers | Identity + user intent + action scope | Pay-per-call settlement via HTTP 402 |
| Transport / format | HTTP Message Signatures (RFC 9421), Ed25519 | SD-JWT delegation chains with key-confirmation | HTTP 402 status code; reference impl Apache 2.0 |
| Scope mechanism | Merchant-specific, purpose-specific, time-bound signatures | Eight constraint types (amount, merchant allowlist, budget cap, recurrence, etc.) | Endpoint-level access; payment-method agnostic |
| Identity model | Visa-operated directory of agent public keys | Issuer-signed credential (Identity layer) | No account model; wallet-based |
| User consent model | Agent vetted via Intelligent Commerce program | Durable consent artifact, verifiable after the fact | Implicit: agent pays to proceed |
| Privacy | Merchant sees signed agent identity | Selective disclosure; private by default | Transaction visible on-chain |
| Protocol compatibility | Layers on top of ACP, UCP | Mappings for AP2, ACP, UCP | Payment-method agnostic |
| Governance | Visa | Mastercard + Google | Linux Foundation; 40 orgs, 17 premier |
| Current status | In development and deployment | Draft v0.1 spec published | Operationally live; USDC on Base primary |
Where each sits in the stack matters more than which “wins.” TAP is an identity wrapper. Verifiable Intent is a consent-and-scope artifact. x402 is a payment rail. They are complementary, not competing — KYA explicitly aims to unify the interoperability layer across all three.
Mapping NIST’s Authorization Asks to Each Protocol’s Mechanisms
NIST’s concept paper asks for identification, authorization, auditing, and non-repudiation controls plus prompt-injection mitigations, and each protocol answers differently: TAP provides cryptographic identification and non-repudiation via Ed25519 signatures, Verifiable Intent addresses authorization and non-repudiation via SD-JWT delegation chains, and x402 provides a settlement-level audit trail on-chain, per the NIST concept paper.
NIST Authorization Asks → Protocol Mechanisms
| NIST Ask | Visa TAP | Mastercard Verifiable Intent | x402 | Coverage Gap |
|---|---|---|---|---|
| Identification | Ed25519 key + Visa directory lookup | Issuer-signed identity credential (SD-JWT) | Wallet address (implicit) | x402 lacks formal agent identity binding |
| Authorization | Agent vetted via Intelligent Commerce | SD-JWT delegation chain with 8 constraint types | HTTP 402 pay-to-proceed (no delegation model) | x402 has no explicit delegation or scope binding |
| Auditing | Request-level signature log | Verifiable consent artifact post-transaction | On-chain transaction record | TAP and Verifiable Intent audit trails are off-chain; x402 is transparent but pseudonymous |
| Non-repudiation | Ed25519 signatures are non-replayable, non-relayable | Cryptographic binding across Identity/Intent/Action layers | Blockchain finality | TAP and Verifiable Intent are strongest here |
| Prompt-injection mitigation | Not addressed in TAP spec | Not addressed in Verifiable Intent spec | Not addressed in x402 spec | No current protocol addresses this; remains open |
The gap is the headline. No single protocol yet covers all five NIST asks end-to-end, and prompt-injection mitigation is unaddressed across all three. Combining protocols gets closer to full coverage: TAP for identification, Verifiable Intent for authorization and non-repudiation, x402 for settlement-level auditing.
The Liability Gap: Who Pays When an Agent Gets It Wrong?
The liability gap remains unresolved: a joint Visa and Artemis report warns that if an attacker redirects an agent’s spending, responsibility may lie with the user, the platform, the model provider, or the merchant, and chargeback rules were designed for human-speed transactions, not thousands of machine-to-machine transactions, reported by Cryptopolitan.
Existing chargeback infrastructure breaks at autonomous-agent scale because it assumes a disputing human on one end and a merchant on the other. When software initiates the transaction and a model provider sits in the middle, the dispute chain has no clean owner. For practical defenses on the wallet side, see securing agentic wallets against attack vectors.
NIST is studying the same identity, authority, and accountability problem from the governance side. Meanwhile Anthropic’s September 2026 threat intelligence report shows adversaries already using AI across the cyber kill chain, which expands the attack surface agent-payment systems must defend. Builders should record the agent, operator, user authorization, constraints, and transaction context — a successful cryptographic payment does not automatically establish liability.
Market Context: How Big Is the Problem We Are Solving?
Market context matters because agent identity is a prerequisite, not a nice-to-have, for scaling agentic payments: TRM Labs puts global retail crypto activity at roughly $979 billion for Q1 2026, reported by Cryptopolitan.
The Bank for International Settlements published a working paper showing general-purpose AI can perform high-level intra-day liquidity management in a hypothetical wholesale payment setting while stressing reliability requirements, also reported by Cryptopolitan. The signal is that AI-driven payment management is feasible but reliability is the gating factor — and reliability depends on knowing which agent acted and under whose authority. For the wallet-infrastructure angle, see how Cloudflare wallets plug into x402.
Practical Next Steps for Builders
Builders evaluating agent-payment deployments today should map their use case to the right protocol or combination of protocols, implement the KYA checklist as it matures through BuildFin.ai, and design for the liability ambiguity rather than assuming it will be resolved soon, per TechNode.
A rough decision tree: if you only need to prove which agent sent a request, TAP covers identity-only. If you need identity plus user intent and enforceable scope, Verifiable Intent adds the authorization layer. If you need pay-per-call access without accounts, x402 handles settlement. Most production-grade flows will be hybrid.
Monitoring is a stated KYA pillar, so plan for continuous transaction monitoring from day one rather than bolting it on. And stay current: TAP is still in development and deployment, Verifiable Intent is Draft v0.1, and x402 is operationally live but evolving. Treat implementation status, deployment scope, and liability outcomes as open questions.
FAQ
What is Know-Your-Agent (KYA)? KYA is an interoperability framework announced on 2026-09-09 by Ant International, Mastercard, and Visa, focused on operator traceability, shared certification requirements, and continuous transaction monitoring for AI agents in payment ecosystems, developed through the BuildFin.ai platform convened by the Monetary Authority of Singapore, per TechNode.
How does Visa’s Trusted Agent Protocol verify an AI agent? TAP signs an AI agent’s identity into HTTP request headers using HTTP Message Signatures (RFC 9421) with Ed25519 keys, per Visa’s documentation. A Visa-operated directory stores agent public keys. Agents are vetted through Visa’s Intelligent Commerce program, and signatures are merchant-specific, purpose-specific, and time-bound so they cannot be replayed or relayed.
What makes Mastercard Verifiable Intent different from traditional card authorization? Verifiable Intent shifts the framing from “who are you?” to “who authorized this agent and for what scope?” Using SD-JWT delegation chains, it binds identity, user intent, and agent action into a single privacy-preserving record with eight constraint types, making consent a durable artifact verifiable after the fact, per the Draft v0.1 spec.
How does x402 work without accounts or subscriptions? x402 revives the HTTP “402 Payment Required” status code. When an agent hits a paid endpoint, the server responds with 402, the agent pays (currently mainly USDC on Base), and retries the request, per the official site. No accounts, subscriptions, or card entry are needed. The reference implementation is Apache 2.0 and the spec is payment-method agnostic.
Who is liable if an AI agent makes an unauthorized payment? A joint Visa and Artemis report identifies a liability gap: if an attacker redirects an agent’s spending, responsibility may sit with the user, the platform, the model provider, or the merchant, reported by Cryptopolitan. Chargeback rules were built for human-speed transactions and do not map cleanly to autonomous agent flows.
Can these three protocols be used together? Yes. TAP provides agent identity verification at the HTTP layer, Verifiable Intent adds user-delegated authorization with constraint binding, and x402 handles settlement. The KYA framework explicitly references all three as complementary reference points and aims to unify interoperability across them while preserving each network’s own verification and risk-control processes, per TechNode.
The Bottom Line
Agent payments need a layered trust architecture, not a single silver-bullet protocol. Prove which agent is acting (TAP), prove what the user authorized and under which constraints (Verifiable Intent), then select a rail for settlement (x402). KYA is the coordination layer working to make those pieces interoperate across card networks, wallets, and agent platforms, though it does not replace any of them.
The unresolved problem is liability. Until chargeback rules and dispute chains adapt to machine-speed commerce, builders should log the agent, operator, user authorization, constraints, and transaction context for every flow. No protocol currently addresses prompt-injection mitigation, and that gap is the one most likely to bite early deployments.
How This Guide Was Built
This guide is based on official documentation, specification drafts, vendor announcements, and reporting — we did not run any of these payment rails or agent-identity frameworks hands-on. Primary sources include Visa’s Trusted Agent Protocol documentation, the Verifiable Intent Draft v0.1 specification, the x402 official site, the NIST concept paper, and Chainalysis’s x402 adoption report.
Secondary reporting includes TechNode on the KYA framework, pymnts on Mastercard Verifiable Intent, the x402 Foundation launch report, and Cryptopolitan’s summary of the Visa and Artemis liability findings plus TRM Labs and BIS figures. Implementation status, deployment scope, and liability outcomes remain open questions across all three protocols.
📖 Related Reads
- ToolBrain — tool reviews, LLM comparisons, and AI workflow guides
Cross-links automatically generated from NiteAgent.
← Back to all posts
