Charge the agents, identify the humans

Google announced Cloud Fraud Defence this week, billed as the next evolution of reCAPTCHA and pitched at the threat actually keeping fraud teams up at night: agents browsing the web on behalf of real users. Claude in someone's terminal, an Operator session running overnight, some bespoke browser-using thing the platform team wired up last quarter, and from the server's perspective it's indistinguishable from any other modern browser carrying a logged-in session. Reasonable problem, real product, and we're glad someone at that scale is acknowledging the shift in public.

The bit that made us laugh, and then frown, is the verification flow. When the system can't tell whether the actor is a human or an unsupervised agent, it falls back to a QR code the user is meant to scan with their phone, presumably to prove there's a meatspace human nearby with a camera and a thumb. It's a 2014 two-factor flow dressed up for the agent era, fighting today's war with yesterday's tools.

QR codes against agents are a structural mismatch

The QR challenge made sense when the threat was a script in a datacentre with no phone attached. It makes much less sense when the threat is an agent the user spun up, because now you're punishing the legitimate use case as hard as the abusive one. The user wants the agent to book the flight, file the expense, place the bid, and the agent has been delegated genuine authority to do exactly that. Putting a QR in the middle of that loop turns "agent acts on your behalf" into "agent prompts you to pick up your phone", which is the entire problem agents were meant to solve. It also assumes the human is co-located with the action, when half the point is that the user kicked the agent off at 9am and went into a meeting.

The failure mode isn't symmetric, either. The infrastructure to defeat a QR challenge already exists at industrial scale, because the same phone farms that have spent the last decade defeating SMS-2FA and app-attestation are sat there with thousands of warm handsets and operators ready to point them at a screen. The exploit is a one-line script: the agent intercepts the image, decodes the URL, posts it to the farm's job queue, a real phone in Manila or Lagos opens it and taps confirm, and the agent carries on. It's a Selenium-era pattern with a different camera in the loop. The legitimate agent, meanwhile, won't bother, because it has no incentive to spend money defeating its own user's bank. Equilibrium settles on a world where the abusive agents pass and the helpful ones fail, which is precisely backwards.

Most "agent abuse" is just free abuse

The reason agents are a fraud-shaped problem at all is that every HTTP request is free. A spammer running a thousand agents through your signup flow, your search results, and your checkout costs roughly the same as a developer running one, because the marginal cost per request is rounded to zero. Behavioural fingerprinting, captchas, and device attestation (the whole lineage of which Cloud Fraud Defence is the current heir) is the industry's compensating mechanism for an underlying market that's mispriced.

The cleaner answer is to fix the price. x402 is the HTTP 402 status code's long-overdue revival, paired with a payment header that lets a server quote a per-request price in stablecoin and a client pay inline before the response comes back. It works at the HTTP layer, so it doesn't care whether the route serves JSON, HTML, or a checkout submission. The plumbing is real enough that we're using it in our own infrastructure, and the agent experience is simple: the agent has a wallet, the wallet has a budget, and the budget gets spent against the routes that matter.

The reason this isn't just "Stripe but cheaper" is precision. Traditional billing rails round to the currency's minor unit, so a request that ought to cost $0.0000003 either settles to zero (which is the free-abuse problem creeping back in by the back door) or rounds up to a penny (which kills the demand side of the micro-pricing model). x402 sidesteps this by quoting in a stablecoin on a chain that natively supports eighteen decimal places, where a fraction-of-a-cent fee is a real number rather than a rounding error. It's the same precision discipline we bake into Ledga, and it's what makes per-request pricing usable as a primitive rather than a marketing demo.

The structural change is asymmetry. A spammer running a thousand agents now pays a thousand times what one agent pays, every request, in real money; the honest researcher pays pennies a day, while the bulk-scrape operator pays four-digit sums per hour and the unit economics of their scheme stop closing. You haven't blocked anyone, you've just refused to subsidise them, and most fraud problems shrink the moment you stop doing that. As a side effect, your site becomes reachable to every legitimate agent and every founder building on top of you without an API-key dance, because pricing is a sharper instrument than friction.

Where you genuinely need a human, prove a human once

Pricing alone doesn't solve every case. There's a residual class of operations where you genuinely need to gate by personhood: voting in an online forum, claiming a free tier, posting reviews, redeeming a one-per-customer bonus, that whole shape of thing. Charging for those is the wrong answer because you want them free for legitimate humans; what you want is for one human to count as one allocation regardless of how many agents they spin up.

This is where the wallet stops being a payment rail and starts being an identity primitive. If you can prove, once, that a given wallet is controlled by a unique human (not which human, just that there's exactly one warm body behind it), and the proof is cryptographically verifiable and reusable across services, you have a sybil-resistant identity layer any application can read. Proof of personhood is the term of art, with implementations ranging from biometric (Worldcoin) to social attestation (Gitcoin Passport) to government-document attestations done client-side with zero-knowledge proofs that reveal nothing except "this wallet is linked to a real ID exactly once". Trade-offs vary, but the architectural shape is the same: bind personhood to a wallet, expose the binding through a verifiable credential, let the relying party check it without learning anything else.

Stack that on top of x402 and the picture rounds out. Agents pay for what they consume, which prices generic abuse out of the market, and routes that genuinely require a human are gated by a one-time personhood proof rather than a QR challenge on every interaction. The phone stays in the pocket, the agent is allowed to be useful, and the spammer can't run a thousand fake users through the funnel because creating a thousand personhood-bound wallets is the expensive bit they were trying to avoid in the first place.

Warning: One wallet, one human is harder than it sounds

Proof of personhood is a genuinely hard problem, and any naive "KYC and a hash" scheme leaks more than the user thinks. A serious design needs unlinkability between the personhood attestation and the wallets that consume it, revocation that doesn't require a central authority, multiple attestation paths so no single provider becomes a chokepoint, and an explicit story for what happens when the human dies. The literature has plenty of broken designs to learn from.

At Zoid, we've been thinking about this shape of system enough that we've started to scaffold out a potential solution, but we'll have more to say when we're ready to ship something rather than wave our hands. For now: the right answer is closer to "bind humans to wallets, charge agents at the request layer" than to "show QR codes to robots and hope".