cardvera
Get started →
← All posts
· Cardvera

In agentic commerce, 'is it a bot?' is the wrong question

The industry is treating cryptographically signed AI agents as the answer to bots at checkout. A signature proves who sent a request, not whether the session behind it is doing what it claims. The layer that judges conduct is still missing, and card testing lives in that gap.

For as long as there have been checkout forms, the defensive question has been the same: is this a person or a script? CAPTCHAs, device fingerprints, headless-browser checks and IP reputation all exist to answer it. Automation at the payment form meant attack, and the job was to keep it out.

That model stopped holding this year. Visa, Mastercard and American Express are building rails whose purpose is to let software check out on a shopper’s behalf. Visa launched its Trusted Agent Protocol citing a 4,700% rise in AI-driven traffic to U.S. retail sites. The bot at your checkout may now be the customer, and the networks are asking you to let it in. So the industry built an answer: make agents prove who they are. The answer is real. It is also incomplete.

A signature tells you who is knocking. It doesn’t tell you what they do once they’re inside.

Web Bot Auth answers one question, and answers it well

Web Bot Auth is an IETF draft built on HTTP Message Signatures (RFC 9421). The agent holds a private key and signs each request, and its public keys sit in a directory at /.well-known/http-message-signatures-directory. The draft’s starting point is that agents mostly identify themselves today through IP address lists and User-Agent strings, both of which anyone can copy.

The card networks have standardized on it:

Once a signature verifies, you know four things: the request came from a key a network vouches for, it was addressed to your site, it is fresh, and it hasn’t been replayed. That is a real improvement over trusting a User-Agent header.

What a valid signature leaves unanswered

Everything a signature proves is about a single request. Checkout abuse plays out over a sequence of requests.

Visa’s spec describes the nonce as a session identifier. The protocol gives you a session ID and says nothing about what a legitimate session looks like. Each verification step in the spec looks at one message: are the fields present, is the timing valid, is the nonce unused, does the signature check out. Suppose an agent submits forty checkout attempts with forty different cards, each with a fresh nonce inside its window. Every one of those requests passes.

Three questions sit outside the signature entirely:

Identity tells you whose agent it is. Authority tells you what it was allowed to do. Neither tells you what it is doing right now.

The protocols are building the first two layers carefully. The third layer is conduct. Card testing has always lived in conduct, and no one in the agentic stack has taken responsibility for it.

Why an allowlist at the edge widens the gap

The obvious response is to verify signatures at the CDN, allowlist the trusted agents, and keep blocking everything else. That does solve the problem Visa’s spec names: merchants and their site protection providers have historically treated automated traffic as bots and blocked it, which turns away legitimate agent-led orders.

It creates two structural problems.

First, allowlisting moves signed traffic past the controls that would have watched it. A rule that routes verified agents around bot protection also routes them around whatever was counting their behavior. The more a key is trusted, the less its sessions get examined. A trusted key with no one watching its sessions is exactly where abuse concentrates.

Second, unsigned traffic doesn’t go away. Visa’s spec says that when a request carries no trusted-agent tag, the merchant can block it or use some other mechanism to decide whether the interaction continues. Card testers will not register keys. Agents from operators that haven’t onboarded with a network, and agentic browsers running in a shopper’s own session, will also arrive unsigned. “Some other mechanism” is the entire unsolved problem, handed back to the merchant.

Gateway velocity rules can’t fill that gap. They see authorization attempts only after they have been submitted and metered, and they never see whether the originating session was signed, tagged for browsing or tagged for payment. The decision has to be made at the payment form, before the gateway. That is the only point where the signature, the session and the behavior are all visible together.

Judge the session, then weigh the signature

Stop asking “Is this a bot?” and start asking “Is this session behaving like what it claims to be?” In agentic commerce the honest answer to the first question is increasingly yes, so it no longer separates good traffic from bad. The second question works the same way for a person, a signed agent or an unsigned script.

Conduct is where the useful signals are. A request tagged for browsing that submits the payment form is contradicting its own signature. So is a session tagged for payment that submits the form dozens of times in a few minutes, or an agent whose request rate is far above the rate it declared. Traffic with no signature at all still gets judged on the same terms.

Cardvera consumes Web Bot Auth signatures today. A verified signature is one input: strong evidence of who sent the request, weighed against what that session does on the page. Cardvera sits in front of the gateway because that is where identity and behavior meet, before an attempt reaches the network and starts costing money.