AI Agent Identity and How to Prove Whose Agent Is Paying

2 hours ago

9 min read

Signed requests, onchain registries, and mandates each answer a different part of who is paying.

AI agent identity cover: 3 stacked cards for which agent sent the request, who approved it, and what history it has

Our read of the counter in Ethereum's ERC-8004 identity registry this week showed 56,280 agent IDs issued, and an ID on its own tells a seller only which wallet controls the agent. AI agent identity has to answer 3 questions before a payment deserves trust: which agent sent the request, which person or company authorized it, and what that agent may buy. No single system is widely accepted for all 3 today. Visa and Mastercard verify the agent through signed web requests, registries such as ERC-8004 give it a name and a feedback record, and mandate systems such as Google's AP2 and Shufti's Know Your Agent record what a person approved. How many of these layers a seller combines should depend on what the order is worth.

What an onchain agent ID proves, and what it leaves out

A stablecoin payment proves that funds moved from one address to another. It says nothing about the software behind that address. On x402, the payment standard we covered in What Is x402? How AI Agents Pay With Stablecoins, an agent answers an HTTP 402 response with a stablecoin payment such as USDC, and the seller learns that money arrived. Erik Reppel, who leads engineering at the Coinbase Developer Platform and founded x402, summed up the gap for The Block in March: payments are the "how," and "identity is the 'who.'"

ERC-8004 is the Ethereum community's attempt at the "who." Reppel is one of its 4 authors, and the draft dates to August 2025. It defines 3 registries. Its identity registry is an ERC-721 contract, so each agent is a token, its owner controls it, and the token points to a registration file that lists endpoints such as an MCP server or an A2A address, along with a flag for x402 support. The second, a reputation registry, collects feedback from clients, and the third, a validation registry, records independent checks, such as stakers re-running a job or a zkML proof. Forbes reported that the core registries reached Ethereum mainnet in late January, and an onchain audit by LLM4Agents dated the Ethereum deployment to the end of January, with Base following days later.

Any wallet can register an agent, and the counts run far ahead of any review. When LLM4Agents read the contracts in mid-August, it counted 50,082 agents on Ethereum. Only 1,668 of them, or 3.3%, had received any feedback, and the Ethereum validation registry had not received a single request. Our own read of that counter this week shows 56,280 agent IDs on Ethereum and 1,177,835 on Base, up from 63,823 on Base in LLM4Agents' August count, a jump the counter alone cannot explain. 8004scan, an explorer for the standard, lists more than 2M registered agents across 29 networks.

The specification is candid about its limits. Its authors write that the standard has no cryptographic way to confirm that an agent's advertised capabilities work or are free of malice, and they warn that Sybil attacks can inflate the reputation of fake agents. An ERC-8004 ID names an agent and ties it to a wallet. Nothing in it tells a seller that someone has checked how the agent behaves.

Bar chart of ERC-8004 on Ethereum in August: 50,082 agents registered, 1,668 with any feedback, 0 validation requests

How Visa and Mastercard check the agent at checkout

Card networks start from the opposite end and verify the agent when it reaches a merchant's site. Visa introduced its Trusted Agent Protocol, or TAP, in October 2025, developed with Cloudflare. Mastercard's Agent Pay, announced in April 2025, requires agents to be registered and verified before they transact. Cloudflare has reported that both programs use Web Bot Auth as their agent authentication layer, which is built on HTTP Message Signatures, the IETF standard published as RFC 9421.

Each registered agent holds a private key, and the network publishes the matching public key in a directory; Visa's specification points to a well-known JWKS address for its keys. On every request, the agent signs the site and path along with a creation time, an expiry time, a key ID, a nonce, and a tag stating whether it is browsing or paying. The merchant, or a CDN working for it, looks up the key and checks the signature. Visa's specification says the creation and expiry times should be no more than 8 minutes apart, and a merchant that logs recent nonces can block a replayed request.

A TAP request can also carry 2 signed objects in its body. The first, a consumer recognition object, holds an ID token whose identity claims are obfuscated, so a merchant can recognize a returning customer only through its own mapping of hashed email or phone values. The second, a payment container, holds a hash of the card credentials, an encrypted payload, or a network token, depending on the merchant's setup.

For card checkouts, that settles which agent is asking: a registered agent sent the request within the last few minutes, and nobody replayed it. Coverage stops at the agents those networks have registered. Visa's GitHub repository also describes its code as a sample implementation, so verification comes from a merchant's CDN or payment provider, or from the merchant's own build.

Flow diagram: a merchant runs 6 checks on a signed agent request, from the tag and 8-minute window to the signature check

Proving that a person approved the purchase

Google's Agent Payments Protocol, AP2, goes after who approved the purchase and what the agent may buy. Google said at launch in September 2025 that more than 60 organizations were collaborating on it, among them Mastercard, American Express, PayPal, and Coinbase. AP2 records a user's instructions as mandates, which Google describes as cryptographically signed digital contracts backed by verifiable credentials. A shopper's request becomes an Intent Mandate, and approving a specific cart signs a Cart Mandate that fixes the items and the price. For a delegated task, a signed Intent Mandate can set a price limit and timing in advance, so the agent can produce the Cart Mandate once those conditions are met. Google also released an A2A x402 extension for crypto payments, built with Coinbase, MetaMask, and the Ethereum Foundation.

World took a different route, through proof of personhood. Its AgentKit, released in beta in March as an extension to x402 v2, lets a person delegate a World ID to an agent, so a site can see that a unique, verified human stands behind it. TechCrunch reported that the person needs a World ID from an iris scan with World's Orb device. The Block noted that the Orb has drawn criticism. AgentKit shows that a unique human stands behind the agent, not that the human approved a given order.

Late last month, Shufti launched Know Your Agent, a commercial service it markets as covering all 3 questions in one flow. Shufti said each agent receives a credential that expires and can be revoked, tied to a person or business verified through its KYC or KYB checks. The principal sets a mandate stating what the agent may do, its limits, when the mandate ends, and how it can be withdrawn, and any request outside it triggers a selfie liveness check by the person who authorized the agent. Help Net Security's coverage describes the same design. A merchant that accepts it still has to trust Shufti's KYC file and integrate the service separately.

Each of these binds the agent to a person in a different place: AP2 in the signed record of the order, AgentKit in a biometric credential, and Know Your Agent in a vendor's KYC file. In a dispute, the merchant relies on Google's signed records, World's Orb enrollment, or Shufti's KYC file, depending on which credential it accepted.

Where AI agent identity still falls short

A valid identity can still carry a bad instruction. A signature proves which agent sent a request and says nothing about whether the request is sensible. An agent fooled by a prompt injection signs its malicious request with a valid key, which is why identity sits next to a spending policy instead of replacing one. We set out those controls in Guardrails Every AI Agent Wallet Needs Before It Spends.

Reputation without validators is thin. LLM4Agents found that all feedback on Ethereum came from 653 client addresses and that nobody had used the validation registry there. Feedback from a few hundred wallets is easy to fake, which is the Sybil risk the specification names itself.

A single key controls the registry upgrades. The same audit found that the ERC-8004 proxies on Ethereum and Base all answer to a single externally owned account, not a multisig or a timelock. Whoever holds that key can change the contracts every ID depends on.

The layers do not share a directory. An agent registered with Visa has no automatic entry in ERC-8004, and a World ID requires an Orb visit. Visa has said it is working with Coinbase on interoperability between TAP and x402, but a merchant that accepts both cards and stablecoins still runs separate checks for each today.

Privacy limits what a seller can prove. Obfuscated claims in TAP and an ERC-8004 entry that names no person protect the user, and they also limit what a seller can prove after a dispute. We talked through how much of agent identity belongs onchain in our episode Your AI Agent Needs an ID. Does It Need a Blockchain?.

Standards bodies are still asking basic questions. In February, NIST's National Cybersecurity Center of Excellence published a concept paper on software and AI agent identity, with comments closing in early April. Biometric Update reported that it asks how credentials for agents should be handed out, kept current, and revoked, and whether an agent's identity should persist or be tied to a single task. By Biometric Update's reading, the paper names existing tools such as OAuth, OpenID Connect, and SPIFFE as candidates.

Table comparing 5 agent identity approaches, from ERC-8004 to Know Your Agent, by what each proves and what it leaves open

What a seller should check before accepting agent payments

We think the amount at risk should decide how many layers a seller requires. A 1-cent API call and a $5,000 equipment order do not need the same proof.

Consider a parts distributor that starts receiving orders from purchasing agents. A $40 order of fasteners arrives from an agent with a valid Visa signature and no mandate. The signature shows that a registered agent sent the request and that nobody replayed it, which is enough at that size. Later the same day, an order for $5,000 of motors arrives from an agent with an ERC-8004 ID, 2 feedback entries, and no mandate. Here the ID only tells the distributor where the agent lives. Before shipping, the distributor should ask for a signed mandate or a credential tied to the buyer's verified business, and hold the order until one arrives. The distributor ships the fasteners at once and holds the motors until the mandate arrives.

Small machine payments. For metered API calls paid through x402, the payment itself is the proof that matters. Treat an ERC-8004 entry as a lookup that tells you where the agent lives, not as a reference, and weight its feedback by how many distinct clients left it.
Card checkouts. Verify the TAP or Agent Pay signature, and reject a request whose validity window runs too long (8 minutes in Visa's specification; check Mastercard's) or whose nonce already appears in your log. Most merchants will get this through their CDN or payment provider, so ask yours whether it already checks Web Bot Auth signatures.
High-value or regulated orders. Require an AP2 Cart Mandate for the specific order. Failing that, require a Know Your Agent credential tied to a verified principal, with a mandate whose scope covers this order. An AgentKit credential shows only that a unique human stands behind the agent.
Every order. Store the agent ID, the request signature, and any mandate with the transaction record. A chargeback or a dispute turns on what you can show afterward, and none of these layers keeps that record for you.

Check revocation before you trust a credential, since several of these systems issue credentials that expire or can be withdrawn. An identity check should never stand in for a limit on what the agent can buy.

The takeaway

Match the proof to the amount at risk. We would accept small machine payments on the payment alone and require a verified agent signature at card checkout. Orders above your manual-review threshold should wait for a signed mandate covering that order, and every signature and mandate belongs in the order record. In a 60-minute Blockchain Strategy Call, we map your order thresholds to the proof each one should require. Details are on our consulting page.

⛔️ Disclaimer ⛔️

This article is published by Blockchain and Web3 Insights LLC for educational and informational purposes only. Nothing in this piece constitutes financial, tax, or legal advice. Always conduct your own research or consult a qualified professional before making decisions.

🗣️ Join the Conversation

Blockchain and Web3 Insights LLC is committed to delivering fact-based, practical education on Bitcoin, blockchain, and decentralized technologies. If this article was useful, please share it with your network and connect with us through the channels below to continue the conversation.