Circle and Proof Demonstrate Verified Identity and USDC Payments for AI Agents

For merchants weighing whether to accept purchases initiated by AI agents, the Circle and Proof demo at Money20/20 addressed a central operational gap: proving who approved a transaction. The companies paired verified identity with USDC settlement in one agent-initiated flow, aiming to give merchants evidence they can use in disputes while limiting exposure of personal data. That combination speaks to a practical concern: a payment can be technically successful while leaving a merchant unsure which person, if any, authorized the agent to make it. Payment credentials alone may show that funds moved, but they don’t necessarily establish whose instructions the agent followed.

The demo is a proposed way to connect those two records. It doesn’t, by itself, show that merchants or financial institutions will accept the evidence, or that the process will work across different identity providers and payment systems. That distinction matters. For businesses considering agent purchases, proof of concept and proof of operational acceptance are separate milestones.

Identity first, payment second

The demonstration combines two open HTTP-layer protocols. Proof’s x401, published in June 2026 and moved into production last week, uses an HTTP 401 response to let a merchant state the identity evidence it requires and the credential issuers it accepts. Circle’s x402 uses HTTP 402 to specify payment terms. Together, they establish who the agent represents and how it should pay. The sequence gives the merchant a way to describe both conditions in the same exchange, rather than treating identity and settlement as unrelated steps.

In the demo, the merchant’s response includes both an identity requirement and a request for USDC. The agent’s Proof wallet supplies a verified credential based on identity proofing certified to NIST IAL2, along with a signed approval for that specific purchase. The merchant receives only the relevant identity attributes, not a full identity document. The agent then pays through a Circle Agent Wallet using USDC over x402. The resulting signed record is designed to preserve evidence of authorization for later dispute resolution without requiring a live request to Proof.

That last detail is operationally significant. If a later dispute depends on a credential provider being reachable, the record may be harder to verify when it’s needed. A signed record can help preserve the link between the approval and the purchase, though the demo’s description doesn’t establish how merchants would store, review, or present that evidence in their own processes. Nor does it say how the system handles a purchase that changes after approval. Those questions sit at the boundary between a protocol working as described and a merchant being able to rely on it.

Data minimization is another part of the proposition. A merchant can request relevant attributes without receiving an entire identity document, which may limit unnecessary disclosure. But the usefulness of that approach depends on what the merchant asks for, which issuers it accepts, and whether the information is enough for its own controls. A narrower data transfer can reduce exposure; it doesn’t automatically resolve the merchant’s verification needs.

Pay-per-verification adds a business model

The protocols also support an on-demand fee for identity checks. Proof prices individual identity claims, and x402 can route a micropayment from the merchant to the credential issuer each time a check is used. That could let merchants purchase verification at the point of need without first negotiating a bilateral contract with each issuer. The model links the cost of a check to its use, which may suit transactions where identity verification is required only occasionally.

There’s a tradeoff built into that convenience. A merchant would still need to decide which claims and issuers it trusts, and how to account for the fee in its transaction economics. Pay-per-check can lower the need for a standing commercial relationship, but it doesn’t remove the work of assessing evidence or setting acceptance rules. (And this is the part most people overlook.) A payment for a credential check is not the same thing as a merchant deciding that the credential is sufficient.

Proof founder and chief executive Pat Kinsel described the combined flow this way: “Our demo with Circle shows one exchange can answer both questions: verified identity from Proof and payment in USDC. That gives businesses a reason to say yes to agents instead of blocking them.” The pitch is clear: make the agent’s authority legible at the point of payment. Whether that changes merchant policy will depend on the quality of the evidence and the cost of integrating it into existing operations.

Adoption hinges on trust and acceptance

The commercial case is straightforward: blocking agent traffic may limit fraud exposure, but it can also exclude purchases as consumers adopt AI assistants. The article reports that several large institutions at Money20/20 are blocking AI agent traffic. Circle and Proof are among multiple efforts to establish agent identity, alongside work in the W3C verifiable credentials ecosystem and proprietary authentication systems from payment networks and cloud providers. That mix suggests the market is still testing different approaches to the same basic question: how can a business distinguish an authorized agent action from an action it shouldn’t honor?

For merchants, accepting agent traffic isn’t only a question of whether a payment can settle. They need to understand who authorized it, what the agent was permitted to do, and what evidence will remain available if the purchase is challenged. Similar systems typically have to fit into existing fraud review and customer support processes as well as the payment flow. If you're working in this space, the hard part may be aligning those internal processes with a new format for authorization evidence.

NIST IAL2 gives the demo a recognized identity-proofing reference point, but it doesn’t settle whether protocol-based claims will meet financial institutions’ KYC obligations. The source also points to comparable trust frameworks in the UK’s Digital Identity and Attributes Trust Framework and the EU’s eIDAS 2.0 wallet framework, while leaving cross-border recognition uncertain. Recognition of a framework and acceptance of a particular credential in a particular transaction are separate questions. A merchant may still need to assess the issuer, the claim, and the context in which the agent is acting.

What the demonstration leaves open

This is more significant than it looks, because an agent payment can shift the point of interaction away from a customer entering details into a familiar checkout. The signed approval is intended to give the merchant a record of a specific purchase, but the available account doesn’t describe how that record would be interpreted across different dispute procedures or institutions. Evidence that exists is useful only if the parties involved can understand and rely on it.

For financial firms, the practical test is whether signed identity evidence can satisfy their controls and dispute processes at scale. That means evaluating the requirements a merchant sets, the credentials an agent can present, and the record left after settlement. Until that’s clear, agent payments may remain routed through existing customer-authenticated channels. The demo offers a concrete path to test; broad acceptance will depend on whether the evidence works in the less tidy cases that routine demonstrations can’t settle.