Visa CLI Lets Agents Pay Any API. Who Verifies the Wallet?

Visa just made it trivial for an AI agent to pay any API. The card network certifies the agent and the merchant endpoint. It says nothing about whether the agent's wallet is actually eligible to buy what it is buying. That is a different question, and it needs a different primitive.

This week Cuy Sheffield, Head of Visa Crypto Labs, announced that Visa CLI is onboarding x402 and MPP merchant endpoints. In his words, "APIs, LLMs, data products, and dev tools can be discovered and purchased by verified agents with cards on file." Any API can become a merchant. Any agent with a card can pay. It is a real unlock for agentic commerce.

It also surfaces a question the payment rail does not answer. When a verified agent shows up to buy, is that agent's wallet actually eligible for what it is buying?

Two different questions

When an agent transacts, a merchant needs answers to two separate things:

• Who is this agent? Is it a legitimate, credentialed agent acting for a real user, authorized for this specific operation?
• What can this agent's wallet do? Does it hold the token the offer requires? Own the NFT that unlocks the member price? Meet the compliance condition for this product?

Visa CLI and the underlying Trusted Agent Protocol answer the first question well. They leave the second one open.

What the card network verifies

Trusted Agent Protocol is a clean authentication layer built on HTTP Message Signatures. The agent signs each request with a key registered to the payment scheme. The merchant verifies that signature against a published key directory, with replay protection and a tag that distinguishes browsing from payment. The trust it establishes is membership: this is a certified agent, with a card on file, acting on a user's behalf.

That is identity and payment capability. It is not wallet state. The agent registry that backs the protocol records the agent's name, domain, and public keys. There is no field for a wallet address, a holding, or a condition. By design, the rail certifies the agent, not the on-chain state behind it.

Why the gap is sharpest on x402

On a card-on-file flow, the network carries a reference back to a known funding source. On the x402 rail there is no card and no account reference. An agent simply presents a signed payment from a wallet address. The merchant can confirm the payment is authentic. What it cannot do is get a portable, signed answer to whether that wallet qualifies for the offer. A merchant could query a chain itself, but not efficiently, not consistently across dozens of chains, and not in a form it can pass downstream as proof. So in practice the wallet shows up unqualified.

As x402 interoperability expands across the ecosystem, every new merchant endpoint inherits the same blind spot. Authentication is handled. Eligibility is not.

The missing layer: wallet auth

Wallet auth, the primitive, reads a wallet's on-chain state, evaluates it against a set of conditions, and returns a cryptographically signed boolean. Not a score. Not an opinion. A signed yes or no, verifiable offline against a public key, across 37 chains.

It answers the second question directly. Is this wallet allowed to buy this? And it composes cleanly with the first. Visa verifies the agent. Wallet auth verifies the wallet state. One answers "who is acting." The other answers "whether the wallet qualifies." They are layers, not competitors.

Token-gating is the obvious first use, but it is the smallest one. The same signed boolean answers far larger questions for autonomous commerce: does a counterparty hold enough balance to settle, does a treasury have the reserves it claims, does this wallet meet a compliance or jurisdiction condition, does an agent carry the on-chain authority to act for an organization, does a buying agent's wallet meet a supplier's procurement terms. Every one of those is the same operation: read on-chain state, evaluate it against a condition, return a verifiable yes or no. It is a decision input for agentic commerce, not a niche checkout feature.

How it works in practice

A merchant endpoint receives a payment from an authenticated agent. Before it fulfills, it reads the payer's wallet from the signed payment payload, not from a header the agent could spoof, and calls the wallet auth primitive with the conditions it cares about. The flow is short:

Agent pays  ->  Merchant reads the wallet from the signed payment
            ->  Wallet auth checks the condition on-chain
            ->  Signed yes / no  ->  Fulfill or fall through to paid flow

In code, the eligibility check is a single call:

curl -s -X POST https://api.insumermodel.com/v1/attest \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_KEY" \
  -d '{
    "wallet": "0x...",
    "conditions": [
      { "type": "token_balance",
        "contractAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
        "chainId": 8453,
        "threshold": 1,
        "label": "Holds USDC on Base" }
    ]
  }'

The signed result travels downstream as proof, verified offline against the public JWKS at api.insumermodel.com/v1/jwks. No re-querying the chain. No need to trust the endpoint that produced it.

We ship a working reference endpoint that does exactly this on x402. A 402-protected resource grants free access to eligible wallets and falls through to the normal paid flow for everyone else, with the payer read from the signed payment so eligibility cannot be spoofed. It is a few dozen readable lines: x402-condition-gate.js in the examples repo.

Why this matters

The agentic-commerce stack is settling into layers. Networks like Visa certify the agent and move the money. That is necessary and it is hard. But "this agent has a card" is not the same as "this wallet qualifies for this purchase." As more APIs become merchants for agents, the eligibility question only gets louder.

The cleanest way to hold the two apart: authentication answers whether an agent may transact. Eligibility answers whether a specific transaction should be allowed. Wallet auth is the primitive that answers the second one: condition-based access, a signed boolean, verifiable by anyone, owned by no rail.