The Good Bot Problem

One of the challenges we hit while testing Prism with agents had nothing to do with payments. It was the front door.

When we started testing agent checkout end to end, our agents kept failing before they ever reached the store. The requests died at the perimeter: a 403 from our own edge, before they ever reached the application, exactly as our own rules said they should. That's the part worth sitting with: nothing was misconfigured. We wanted that security posture. Twenty years of running anything on the open internet teaches you to want it. Score every session for humanness, challenge whatever moves too cleanly, block automation by default. Scrapers, sneaker bots, credential stuffers earned every one of those rules.

And yet the traffic our rules were killing was a customer's agent, holding a funded wallet, trying to complete a purchase. Both things are true at once, and that's the real engineering challenge of agent commerce, the one that doesn't show up on protocol slides. The wall detects machine. It can't detect motive.

There's a word for this moment, and it's irony. The internet spent twenty years getting brilliant at keeping machines out, and the next thing it needs is a graceful way to let the right ones in. We didn't resolve that by weakening anything, and we wouldn't recommend anyone else do so either. The way through is not a lower wall. It's a door in it. This piece is what we've learned about that door so far: which parts exist, which parts don't, and the open questions we find most exciting.

Start with what an agent actually is: it doesn't want anything. The assistant at your checkout is a customer's intent wearing software. That doesn't make machine traffic friendly. There's a person behind every scraper too, and that person's intent is extraction. Intent is conserved either way. Conserved is not the same as welcome.

Which is why "is this human?" was always a proxy question. It held for twenty years because humans bought things and machines didn't. That correlation is breaking. A scraper carries intent to extract: prices, stock, content, taken for free. An agent carries intent to purchase, with the money attached. The perimeter treats them identically because it classifies on how human the traffic looks, and that's the one signal that no longer separates anything.

The encouraging part: an agent, unlike a scraper, has every reason to identify itself. It wants to be let in, it can prove who sent it, and it can pay. The raw material for a better question is sitting right there in the request.

The merchant-facing parts of the door mostly exist already. The commerce protocols, ACP, UCP, x402, give an agent a catalog to read and a checkout to call, and the major platforms are shipping them as features you enable rather than projects you staff. Structured product data has been table stakes since SEO. The money underneath, machine-native settlement, is the layer Prism itself handles, and there are good reasons it runs on stablecoins. All of that worked.

The trouble came one layer out, and it doesn't belong to any merchant. CDNs, WAFs, bot management. There's no villain here. The reality is simply that most WAF and application-security rules were written long before anyone assumed agents would be visiting stores too, so that visitor has no place in their model of the world. A handful of infrastructure companies operate that perimeter for most of the internet, and their classifications decide whether a paying agent ever reaches a checkout. A merchant can enable every protocol on the list and still be unreachable behind a default they've never seen.

Our fix was unglamorous, and it worked: custom firewall rules that recognized well-known agents by their declared user agents and let them through, while everything else stayed blocked. A guest list, maintained by hand. It solves the problem the way guest lists always do, which is to say it scales exactly as far as your willingness to maintain it. It also confirmed the deeper principle for us: the durable answer here is cryptographic, not behavioral. An agent that matters will never look human, and shouldn't have to pretend to. Let it present identity instead of a disguise.

Here is the part that should worry any merchant reading this. Everything you might invest in to serve agent traffic sits behind a decision you have probably never looked at. Enable every commerce protocol on the list, clean up your structured product data, wire in machine-native settlement, and none of it matters if the request never reaches your application. The protocols are not the bottleneck. The perimeter is. And the perimeter is almost always a default someone else chose for you, years before agents existed.

The good news is that this is the cheapest thing in this entire article to check, and you can do it this afternoon. Send a request to your own checkout with a well-known agent user agent and watch what comes back. If it is a 403, you have your answer, and you got it for the price of one command. That is exactly how we found ours. Nothing was misconfigured. The rules were working.

The second piece of good news is that you probably do not need to build anything. Most perimeter providers have already shipped the controls, and the vocabulary is broadly the same wherever you look: a flag for verified or known-good bots, categories that separate an agent fetching on behalf of a waiting human from a crawler harvesting a training corpus, and per-agent allow and block toggles that write the underlying rules for you. Some of it lives in a dashboard, some of it is a managed rule set you switch on. What matters is that expressing "let verified agents through, keep challenging everything else" is now usually a configuration question rather than an engineering project.

It is still rules-based and a little manual, which is roughly where TLS was in 1997. That is not a criticism. It is a marker of how early we are. The tooling is already moving from strings to signatures, letting an agent prove who sent it cryptographically instead of impersonating a browser, and the card networks have started adopting that approach for shopping agents. When that lands properly, human-versus-machine is finished as a classification. What replaces it is policy: which verified intent gets through, on what terms. That is a decision a merchant gets to make deliberately, rather than a guess a fraud model makes on their behalf.

None of that is a reason to wait, though. The door is being built. The question worth asking today is whether yours is bolted shut.

The part we find most interesting now is how admission control evolves, because the shape of it is just becoming visible.

It's not hard to imagine agents carrying something like a passport: a cryptographic identity, a mandate that says who sent it and what it's allowed to do, a wallet that proves it can settle. The perimeter stops guessing species and starts checking papers. Maybe reputation attaches to agent identities the way it attaches to domains today, so a well-behaved agent earns smoother passage. Maybe admission control becomes a standard layer of the stack, as unremarkable as TLS termination, with every WAF shipping an agent lane next to the bot score. Maybe the negotiation moves into the door itself, and a 402 becomes the opening move of a conversation instead of the end of one.

Which standard carries all this is still open. Web Bot Auth has the payment networks behind it, the commerce protocols are still deciding how identity, mandate, and payment compose, and the perimeter providers each hold a piece. We don't know how it lands. We're building the settlement layer for whichever answer wins, and watching the door get designed with real interest.

Because the direction is not in doubt. Your best customers are about to stop doing the typing. The walls will keep doing their job, and they should. The stores that thrive will be the ones whose walls learned to check papers, open the door, and take the money.

I'm the CTO at First Digital, building payment infrastructure for the autonomous agent economy. Tell me where I'm wrong on LinkedIn or X.

To learn more about Finance District, join our Discord community, follow us on X, or explore our documentation.