Trust & Safety

How we tell people from machines in 2026 — the technology, its economics, the ways it breaks, and why “are you human?” is quietly becoming the wrong question to ask.

WBOS Insights · Trust & Safety

By Srijan, founder of WBOS · Researched mid-2026, updated September 2026 · ~25 minute read

The machine now passes the human test more cheaply than the human does

For about twenty years, the most reliable way to beat a CAPTCHA was to pay a person in a low-wage country a fraction of a cent to squint at it and click. The bot couldn’t read the squiggly letters; the human could. That asymmetry — machines fail, humans pass — was the entire premise of the test. In 2026, it has quietly inverted. The cheapest reliable solver of a “prove you’re human” puzzle is no longer a human. It’s a machine.

The numbers are close enough that I want to be careful not to overstate them, because the honest version is striking enough on its own. Commercial AI-driven CAPTCHA solvers now advertise roughly $0.40 to $1.20 per thousand solves, while human solving farms sit at roughly $0.50 to $3.00 per thousand. (current market ranges, mid-2026) Those ranges overlap — this is a crossover, not a clean rout — but the trend line only points one way, because the machine’s cost falls along a curve the human’s wage never will. A late-2025 study of multimodal large language models solving CAPTCHAs found that they reliably solve recognition-oriented and low-interaction challenges at human-like cost and latency, with only tasks needing fine-grained localization or multi-step spatial reasoning still hard for current models. (arXiv 2512.02318, Dec 2025)

So the puzzle isn’t dead. But it’s demoted — from a wall into a speed bump. Which leaves a sharper question, and it’s the one this essay is really about:

I ran into this question the hard way. Last year, as a personal project outside WBOS, I built Humannnn — a small social network premised on a simple promise: that the people on it are people, with no ranking algorithm in between. “Only humans” turned out to be one of the hardest promises to keep on the modern internet. And the same question keeps surfacing in WBOS client conversations, usually in a different costume: a marketplace fighting fake sellers, a SaaS product bleeding free-trial abuse, a community platform where half the sign-ups are farms. So I went back and did the research properly, with a lot of help from AI research tools. What follows is the whole stack — how bot detection actually works, what each layer costs to defeat, and a deep, unresolved question about what “human” even means once the person on the other end is delegating to an AI.

The shift nobody announced: from puzzles to passive scoring

If you haven’t seen many CAPTCHAs lately, that’s not because the bots gave up. It’s because the entire industry restructured itself around a different idea, and mostly forgot to tell anyone. The model used to be challenge-first: a gate everyone had to pass before proceeding. The model now is score-first: an invisible risk engine watches how you behave, what your device looks like, and where your traffic comes from, assigns you a quiet risk score, and lets the overwhelming majority of users through having never seen a puzzle at all.

Every major scoring vendor works this way now — Google’s reCAPTCHA Enterprise, Cloudflare’s Turnstile, DataDome, HUMAN Security. (vendor documentation, 2025–2026) They fuse signals from four broad categories: behavioral (mouse movement, scroll rhythm, typing cadence), device (browser and hardware fingerprints, automation tells), network (IP reputation, datacenter-versus-residential origin, request velocity), and historical (reputation databases, prior sessions). A challenge, when it appears at all, is a fallback the risk engine reaches for only when the score is ambiguous. The challenge didn’t disappear; it got demoted to the role of last resort. (Not every vendor agrees — hCaptcha, for instance, remains comparatively challenge-centric — but the center of gravity has moved decisively to passive scoring.)

This reordering changes the attacker’s job in a way that’s easy to miss but reframes everything that follows. When the puzzle was the gate, the attacker’s goal was to solve the puzzle. When the score is the gate, the attacker’s goal is something subtler:

This is the “slow and low” strategy, and it explains why so much modern bot defense is really about accumulating tiny signals of abnormality until they cross a line. The fight isn’t at the puzzle. It’s spread across a whole stack of quiet measurements. So let’s descend that stack, one layer at a time, through the eyes of the thing it’s built to stop.

The anatomy of stopping a fake account

Imagine a single fake-account-creation attempt — one bot, trying to register on our only-human network — and follow it down the gauntlet. At each layer the defender checks something, the attacker has a way around it, and crucially, that way around it costs money. Hold onto the cost column; it turns out to be the most important part of the whole picture.

The gauntlet, top to bottom: each layer pairs a defender signal with an attacker bypass and the cost that bypass imposes. The layers, in order, are described in the prose below — nothing here lives only in the diagram.

L0 — The network and the IP address

The first thing any defender looks at is where you’re coming from. Traffic from a known datacenter IP, or an address with a bad reputation, or a single IP suddenly registering hundreds of accounts, is trivially suspicious. The attacker’s answer is the residential proxy: route the traffic through real consumer devices so it looks like it’s coming from an ordinary home connection. This works well — and it’s the single most important cost in the entire attack, running roughly $1 to $10 per gigabyte, with most commercial plans landing around $2–$5. (residential proxy market, 2026) Remember that figure; we’ll come back to why it matters more than anything else.

L1 — The transport fingerprint

Below the application, the very way your client negotiates a TLS connection leaves a fingerprint — the cipher suites it offers, the order of extensions, the shape of its HTTP/2 frames. These are summarized as JA3/JA4 signatures, and a mismatch between, say, a browser’s claimed identity and its actual TLS handshake is a strong automation tell. The bypass is a class of tools (curl-impersonate, uTLS-based clients) that perfectly mimic a real browser’s handshake. The cost here is almost entirely up-front engineering; once built, the marginal cost is essentially zero. This is a recurring pattern: layers that read an artifact the client emits are structurally weak, because an artifact can be reproduced exactly.

L2 — The browser fingerprint

Now the defender runs JavaScript in the browser and measures the device itself: how it renders graphics on a hidden canvas, its WebGL and audio-stack signatures, its fonts, its screen geometry, and the dead giveaways of automation — a navigator.webdriver flag, telltale traces of a Chrome DevTools Protocol session. The countermeasure is a whole industry of anti-detect browsers — Multilogin, Kameleo, undetected-chromedriver and kin — that present each session as a unique, ordinary device. The cost is a subscription, modest and amortized across thousands of fake identities.

L3 — Behavioral biometrics

This is the deepest of the passive layers and the hardest to fake well: not what your device is, but how you move. The curve and jitter of your mouse, the rhythm of your scrolling, the cadence and error-pattern of your typing, the pressure and arc of your touches. Real human motion has a texture that naive bots — with their perfectly straight mouse paths and metronomic timing — conspicuously lack. The attacker’s response is humanized-input generation and, increasingly, replaying or synthesizing genuine human traces. I’m going to come back to this layer in the second half, because it cuts both ways: behavioral biometrics are simultaneously the most promising signal we have and one of the most quietly fragile, and that tension turns out to be important.

L5 — The risk engine, which runs the whole show

I’ve deliberately numbered this out of order, because in a modern system the risk engine isn’t a layer you pass after the others — it’s the orchestrator above them. It ingests every signal from L0–L3, fuses them with machine-learning models and hard rules into a single score, and decides your fate: allow silently, watch you, throw a challenge, or block. It’s precisely because this engine exists that the attacker’s real objective is the “slow and low” one from the previous section — keep every individual signal just normal enough that the fused score never crosses the line. The engine is the reason the challenge is now optional.

L4 — The challenge, now a fallback

Only when the risk engine is unsure does the old-fashioned challenge appear — a CAPTCHA, or a silent Turnstile proof-of-work. And as we saw in the opening, this is exactly the layer that has collapsed in price: AI solvers at roughly $0.40–$1.20 per thousand, human farms at $0.50–$3.00, and token-replay tricks that recycle a single solved challenge. The challenge is no longer a wall. For most attackers, it’s the cheapest part of the whole operation.

L6 — And on mobile, the hardware root

Native apps add a layer the web can’t: hardware-backed attestation, where the device’s secure chip vouches for its own integrity. It’s strong enough to deserve its own section, which it gets shortly. For now, place it at the bottom of the gauntlet as the sturdiest single layer — and note the foreshadowing that even it has a clean way around.

Notice what the gauntlet reveals when you read down the cost column. The challenge — the thing we historically called “the bot test” — is nearly the cheapest layer to defeat. The expensive layer is the one at the very top: the bandwidth. That observation is worth its own section, because it tells us we’ve been fighting in the wrong place.

Where the cost actually lives

Here is a fact that reorganized how I think about this entire problem: in a great many real attacks, the residential-proxy bill is larger than the CAPTCHA-solving bill. A solve costs a fraction of a cent. But pushing the bandwidth for a realistic browsing session — loading the page, the scripts, the images, echoing it all back through a residential IP at $2–$5 a gigabyte — can easily cost more than the solve it was carrying. We spent two decades obsessing over the puzzle, and the puzzle was never where the attacker’s money went.

This reframes the defender’s goal in a useful, concrete way. You are not trying to build an unbeatable test — there isn’t one. You are trying to raise the attacker’s cost per successful account until the abuse stops paying for itself. And if your goal is to raise cost, you should attack the term in the cost equation that’s already largest. Roughly:

The strategic implication is that the highest-leverage defenses are the ones that force the attacker to spend more of their most expensive resource. Phone verification does this — which is exactly why “phone-verified accounts” command a steep premium in the account-farming markets. And, as I’ll argue later, it suggests a different and somewhat contrarian design for a challenge: one engineered to burn bandwidth rather than the attacker’s CPU.

The mobile dimension: hardware roots and their relay problem

Everything so far has been web-shaped — signals a server infers about a client it can’t trust. Native mobile apps change the game, because they can lean on a fundamentally stronger primitive: a hardware root of trust. Modern phones carry a secure element — Apple’s Secure Enclave, Android’s hardware-backed Keystore — that can cryptographically vouch for the integrity of the device and the app.

On Android, Play Integrity (which since mid-2025 requires genuine hardware-backed key attestation for its strongest verdicts) tells your server whether the app binary is untampered, installed from the Play Store, and running on a certified, un-rooted device. On iOS, App Attest generates a key inside the Secure Enclave that never leaves it, and answers a server’s fresh challenge with a hardware-signed attestation, followed by per-request assertions. (Google Play Integrity; Apple App Attest, 2025–2026) Done right, these are genuinely hard to spoof on the device itself. This is the sturdiest layer in the whole stack.

But — and this is the precise, load-bearing point that most write-ups blur — here is exactly what attestation proves, and what it doesn’t:

Those are different claims, and the gap between them is the bypass. It’s called token relay: run the app on a perfectly clean, genuine device to obtain valid attestation tokens, then relay those tokens to a farm of automated sessions elsewhere. The hardware honestly attests to a real device — it just has no idea that device is a token vending machine for a thousand bots. Worse, Apple is explicit that App Attest cannot detect a jailbroken OS or runtime hooking; a compromised device can pass attestation and then be manipulated above the attestation layer. (Apple developer documentation) The defenses against relay are real but partial: bind every attestation to a fresh, short-lived, per-action challenge; tie it to the account and network; and watch for the statistical tell of one “device” serving improbably many accounts.

And yet the most common way verification actually fails on both web and mobile isn’t any of this exotic machinery. It’s depressingly mundane: application-logic flaws. An attacker intercepts the server’s “code incorrect” response and flips it to “verified.” A frontend that trusts a client-side flag to mark an email confirmed. A verification token that isn’t bound tightly to one account, so it can be replayed against another. A server that never actually re-checks email_verified before granting access. (recurring findings in security disclosures, 2025–2026) These cost nothing to exploit and nothing to fix — they’re own goals — and I’ll give the full defensive checklist near the end. They’re a useful reminder that the most expensive attestation hardware in the world is wasted if the logic behind it trusts the client.

So that’s the landscape: a layered, score-first system that’s clever, paired at every layer with a bypass whose cost we can now roughly name. It’s a good system. It is also, as we’re about to see, fundamentally unable to answer the one question our only-human network actually cares about.

The honest problem: proof-of-personhood and the quadrilemma

Everything in the first half was about detecting bots. But “only humans” is a stronger and stranger requirement than “no bots,” and it has a proper name in the research literature: proof-of-personhood. The goal isn’t merely to block automation; it’s to establish that behind an account is a unique, real person — ideally without forcing that person to surrender their identity to do it. There’s a whole field building toward this, and it sorts into five families.

Biometric uniqueness — World ID (formerly Worldcoin) — at its strongest tier — scans your iris with a physical “Orb” to mint a credential that’s extraordinarily hard to duplicate. Social-graph systems like BrightID infer your humanity from the structure of who vouches for you. Human-challenge protocols like Idena run synchronized, globally-timed puzzle sessions that are hard to pass at scale. Credential aggregation — Gitcoin’s Human Passport — stitches together many weak signals (an aged GitHub account, a phone number, prior on-chain activity) into one composite score. And anonymous tokens — Privacy Pass, Apple’s Private Access Tokens — let an issuer cryptographically vouch that you passed some check, redeemable later in a way that can’t be traced back to issuance.

Here is the thing they all have in common: every single one buys its strengths by sacrificing something else. And when you lay them against the four properties you’d actually want — privacy, uniqueness (sybil-resistance), inclusivity, and decentralization — a hard pattern emerges. No system gives you all four. You get three, at most, and the fourth is the price.

The proof-of-personhood quadrilemma: each system covers only part of the diamond. World ID maximizes uniqueness; Privacy Pass maximizes privacy but barely touches uniqueness; social and aggregation systems reach for inclusivity at the cost of hard sybil-resistance. No system spans all four corners.

The clearest proof that uniqueness alone isn’t enough comes from the system that has the most of it. World ID is, technically, the strongest sybil-resistance mechanism deployed at scale — roughly 15 to 18 million verified humans against some 30-plus million app accounts, served by on the order of 1,500 to 1,700 Orbs. (World, April 2026) (Since April 2026 World ID also offers weaker tiers — a document check and a plain app install — but the Orb tier is the one that carries the uniqueness guarantee.) And it keeps colliding with regulators. It has faced bans, suspensions, or restrictions in Spain, Hong Kong, Brazil, Indonesia, the Philippines, and Thailand; in Kenya, the High Court ruled its 2023 biometric collection illegal in May 2025; and data-protection investigations continue elsewhere. (regulatory actions, 2024–2026) The lesson is not that World ID is badly built — it’s that biometric uniqueness can be regulated out of existence regardless of its technical merit, because the privacy and consent cost is one many societies refuse to pay. My read of the field: World is winning on visibility, Privacy Pass is winning on standards, and Human Passport is winning on modularity — which is another way of saying nobody is winning the whole thing.

Which brings us to the heart of it. After all the layers, all the cryptography, all the biometrics, the honest conclusion is this:

There is no purely-technical, privacy-preserving, sybil-proof, and inclusive test of humanness today. And that tension is not a bug to be fixed — it’s the frontier.

If you’ve felt that conclusion building over the last several sections — every layer partial, every bypass affordable, every clean solution sacrificing something essential — that’s the point. The impossibility isn’t a gap in the engineering. It’s structural. And it’s about to get stranger, because a new development is dissolving even the question.

The category collapse: when the human/bot line dissolves

Every defense in the first half rests on a buried assumption: that there are two kinds of traffic, human and automated, and the job is to tell them apart. In 2026 that assumption is breaking, and not at the margins.

The evidence is concrete. AI browsing agents — OpenAI’s ChatGPT Agent and its kin — now routinely complete “I’m not a robot” flows, because by passing the behavioral pre-checks, they ensure the visible puzzle never even loads. (demonstrated 2025–2026) Cloudflare now blocks AI crawlers by default and runs a separate lane for cryptographically signed agents. World launched AgentKit in March 2026, letting a verified human delegate their World ID to an AI agent so the agent can prove a unique person stands behind it — I’ll come back to this, because it matters for one of the ideas below. The industry has clearly noticed.

And it’s building a real answer — just not, I’ll argue, the complete answer. The most important development is Web Bot Auth, an emerging IETF standard (the working group was chartered in late 2025, the drafts moved to Standards Track in August 2026, and the working group formally adopted them on 1 September 2026) that lets an automated client cryptographically sign its HTTP requests. The mechanism is clean: the agent operator publishes Ed25519 public keys at a well-known directory, signs each request per RFC 9421’s HTTP Message Signatures, and adds a Signature-Agent header pointing to that directory. Cloudflare, AWS WAF, Akamai, Vercel, Google, and agent operators like OpenAI already sign or verify with it in production, and Visa and Mastercard have built their agentic-commerce authentication on top of it. (IETF Web Bot Auth WG; Cloudflare, 2025–2026) Think of it as “User-Agent, but cryptographically backed” — instead of trusting a spoofable string, you verify a signature.

This is important, and it validates a direction I’ll build on shortly. But here’s where I want to be careful to separate what the evidence shows from what I’m arguing. What the evidence shows: Web Bot Auth authenticates the operator of an agent — it tells you “this request comes from OpenAI” or “this is Google’s crawler.” And even that operator-level layer is uneven: verification lives at the CDN and payment-network edge, while a 2026 scan of sixty large enterprise domains found essentially zero origin-side adoption — most companies’ own servers still can’t check a signature. What I’d argue: for an only-human social network, knowing which company’s agent is talking to you is necessary but nowhere near sufficient. Because the real situation is this —

The blurring line: a human delegating to an AI agent sits in the ambiguous middle of the spectrum — tripping every automated-traffic signal, while a consenting, accountable human stands behind the action. The binary “human or bot?” has no good answer here.

A person who tells their AI assistant “sign me up and set up my profile” is, at that moment, both a genuine human intent and a non-human actuator. Every behavioral and fingerprint signal will scream “bot.” And yet there is a real, consenting person behind it. My contention is that this breaks the question itself. “Is this a human?” is becoming unanswerable not because detection is too weak, but because it’s the wrong question. The better questions — and I’ll grant these are an argument, not a settled fact — are: is there an accountable human behind this action? and is this action consented-to and rate-limited per human? (I should be honest that the industry could simply settle for “allow verified-operator agents, block everything else” and never reach the human-principal layer at all. I think that would be a mistake for a network whose entire premise is human authorship — but it’s a real possibility, not a foregone conclusion.)

So if the honest landscape is “no clean test exists,” and the honest frontier is “the question is dissolving,” what do you actually do? Here are six ideas. Some lean on real, citable primitives and extend them; all of them, in keeping with the spirit of this piece, come with the reason they might fail.

Six ideas for an only-human network

1. Make a fake account cost a real human

The deepest problem with the entire cost analysis from the first half is that every attacker resource — proxies, solvers, anti-detect browsers — is commoditized. You can always rent more. So what if account creation consumed a resource that isn’t rentable at scale? This idea builds directly on a real cryptographic primitive called the Rate-Limiting Nullifier (RLN), an extension of the Semaphore protocol. In RLN, a verified member proves — in zero knowledge — that they belong to a set of known-unique humans, and emits a per-epoch “nullifier” each time they act. Act once per epoch and you stay anonymous; act twice, and a Shamir secret-sharing construction leaks enough to reconstruct your key and slash you. The mechanism is elegant and it exists today.

My extension is an economic reframing rather than a new cryptographic gadget: bind account creation and high-value social actions to a finite, replenishing per-human budget enforced by these nullifiers. The effect is that the marginal cost of the millionth-and-first fake account stops being “rent another gigabyte of proxy” and becomes “acquire another verified human.” That single substitution collapses the attacker’s economics, because verified humans — unlike bandwidth — are not a commodity you can buy by the terabyte. (World demonstrated a toy version of this in 2026: a limited product drop capped at one unit per verified human, where spinning up extra agents bought you nothing.) Why it might fail: it presupposes a sybil-resistant proof-of-personhood layer underneath, so it inherits every unsolved problem from the quadrilemma above — and worse, it could spawn exactly the exploitative market the World ID story warns about: paid humans in low-income regions renting out their personhood credential. It moves the wall; it doesn’t remove it.

2. Prove you’re human without showing how you move

Behavioral biometrics — that L3 layer — pose a genuine dilemma. To use them, you either stream a person’s intimate interaction data (every mouse twitch, every keystroke rhythm) to a server, which is surveillance, or you trust the client to score itself, which is trivially spoofable. Neither is acceptable for a network that takes privacy seriously. So here’s the idea: run the behavioral model entirely on the device, and have it emit a zero-knowledge proof that says “my interaction data scores above the humanness threshold on the model you committed to” — revealing nothing about the raw behavior itself. It combines two things that exist (behavioral models and ZK proofs) into something neither does alone.

This is, I think, the most novel idea here — and I have to be brutally honest that it has a hard wall. If the model lives on the device, a determined attacker can extract it, and a stolen model is a perfect oracle: now they know exactly what synthetic behavior clears the threshold, and can generate it at will. Partial mitigations exist — rotate the committed model frequently to shorten the exploitation window, keep a small secret server-side residual check so the on-device proof is necessary but not sufficient — but I won’t pretend they close the gap. And behavioral biometrics carry their own well-documented baggage: they can be defeated by replay and by generative motion-synthesis, and they systematically false-positive users on assistive technologies, whose interaction patterns look “abnormal” to a model trained on typical users. That last one isn’t just a bug; it’s an ethics problem with treating “moves like most people” as a proxy for “human.” This idea is a promising direction with a known, honest ceiling.

3. Burn the resource the attacker actually pays for

Recall the central economic finding: the attacker’s dominant cost is residential bandwidth, not the puzzle. Cloudflare’s Turnstile already issues a silent proof-of-work challenge — but it burns CPU. My twist is to key the burn to the resource that actually hurts: make the risk-scored challenge consume bandwidth. On elevated suspicion, require the client to download, process, and echo a large unique payload. For one legitimate user creating one account, a few megabytes is invisible. For a farm pushing millions of attempts through metered residential proxies at $2–$5 a gigabyte, you’ve just multiplied their single largest bill. Why it might fail: it’s regressive in exactly the wrong direction — it taxes users on metered mobile data, low-end devices, and slow connections, the same inclusivity wound that runs through this whole topic. And a sophisticated attacker amortizes it: warm a session once, reuse it many times, or run the bandwidth burn over cheap datacenter egress and only route the final credential through the residential IP. It raises the cost; it doesn’t change the game.

4. If you must show a puzzle, make it a scene, not a snapshot

This one predates the rest of the essay. One morning in June, before I’d done any of this research, I sketched a spec for a different kind of CAPTCHA and thought I’d found something. Now, with the cost column in front of me, I can say precisely what it does and doesn’t buy. The observation behind it: today’s puzzles are snapshots. A grid of crosswalk tiles, a distorted word, a rotated animal — one frame, one recognition task, exactly what a multimodal model does at near-zero cost. So don’t show a frame. Show a scene: a five-second, procedurally generated animation in which a character interacts with several objects and several codes, and the answer depends on what happens when. “Type the code the astronaut points to after the light turns green.” “Click the moment the fox waves at the blue sign.” Every scene is unique — character, background, timing, wording, easing, camera drift all randomized — and the answer lives in the relationships between events, not in any single pixel.

The reason this isn’t just a harder puzzle is that it changes which capabilities a solver needs at once: text recognition, object tracking, pose and pointer detection, temporal ordering, and instruction parsing, applied across frames rather than to one. And that happens to be exactly the seam the research points at. The same late-2025 study that found recognition CAPTCHAs cheap to automate also found that tasks needing multi-step spatial reasoning or cross-frame consistency remain much harder for current models, and a 2026 line of work on “cognitive gap” CAPTCHAs is deliberately building on that gap. (arXiv 2512.02318; arXiv 2602.09012) A solver now has to run a video-capable model over every attempt, or stitch together a pipeline of specialized ones — and either way the per-solve cost climbs back out of the fraction-of-a-cent basement. It doesn’t make the puzzle unsolvable. It moves it, for a while, off the cheap end of the curve.

Why it might fail: three ways, and I’d rather name them than let a reader find them. First, and this is the one the cost column makes unavoidable, it raises the AI solver’s bill but not the human farm’s. A person in a solving farm can watch a five-second cartoon as easily as they read a squiggle, so the ceiling on what this buys you is roughly parity with human labor — it pushes attackers back to the farms, it doesn’t price them out. Second, it is a challenge-layer idea, and this essay’s whole argument is that the challenge is the layer attackers rarely even see; at best this is the step-up you throw at elevated risk scores, never a gate for everyone. Third — and this is the flaw I only spotted once I understood the stack — my original spec preferred procedural rendering: send the browser a scene and a timeline as JSON and let it draw the animation, for tiny bandwidth and infinite variation. But whatever the browser needs in order to draw “the light turns green at 3.6 seconds and the fox points at A7FK” is exactly what a bot needs in order to skip the animation entirely and read the answer off the timeline. Procedural rendering leaks the puzzle’s structure to the one party you can’t trust. The fix is to render server-side and ship opaque video — which costs a rendering farm and bandwidth, though notably that bandwidth is paid by the attacker too, which quietly folds this idea into idea three. And it carries the inclusivity wound in its most acute form: a timed, motion-based visual task is hard for people with motor, cognitive, or visual impairments, so an audio or simplified path isn’t optional, and every such path is a softer target. A promising step-up challenge with a hard ceiling — which, by now, should sound familiar.

5. Don’t ask if it’s a human. Ask which human is accountable.

This is the idea I care about most, and it’s the constructive answer to the category collapse. Start from the real standard: Web Bot Auth, as we saw, lets an agent cryptographically prove which operator it belongs to. Now layer on a second primitive — the blind-signature tokens behind Privacy Pass and Apple’s Private Access Tokens, which let an issuer vouch for a property in a way that’s unlinkable at redemption. Combine them and you can build what I’ll call an accountable-agent delegation token: a verified human (rooted in proof-of-personhood) mints a scoped, revocable, attributable credential that says “this agent is acting for human H, for purpose P, rate-limited to R — and if it abuses that, it’s traceable back to H.”

Let me draw the distinction as sharply as I can, because it’s the whole point and it’s my argument, not established fact: Web Bot Auth authenticates the corporate operator — it answers “is this OpenAI’s agent?” What an only-human network actually needs is the accountable human principal — “is there a specific, real person who answers for this action?” Those are different layers, and the second sits above the first. The industry has built (is building, really — recall the near-zero origin adoption) the operator layer. The human-principal layer has exactly one shipping instance I know of: World’s AgentKit, which lets an Orb-verified human delegate their World ID to an agent and proves “a unique human backs this” without revealing who. That’s the right shape, and it validates the direction. But it is bound to a single proof-of-personhood vendor — and so inherits every regulatory problem World faces — and it answers “is there a human?” more than “for what, how much, and revocable by whom?” What I’m describing is the vendor-neutral version: delegation as a standard layered over Web Bot Auth and blind tokens, with purpose, rate limit, and revocation as first-class fields, and with the proof-of-personhood root pluggable rather than fixed. That layer is further off still, which is precisely why it’s worth articulating now. This reframes the entire posture from “detect and block all automation” to “welcome accountable automation, exclude anonymous farms” — which is the only stance that survives contact with a world where your real users delegate to agents. Why it might fail: there’s a deep tension between accountability and the unlinkability that makes these tokens private — resolving “traceable back to H under abuse” reintroduces some trusted party who can open the box, which is a governance cost, not a free lunch. A human can also launder their delegation by selling tokens to a farm (rate caps and revocation blunt this but don’t kill it). And it presupposes an entire agent ecosystem agreeing to a delegation standard — a coordination problem as much as a technical one.

6. Humanness is confirmed in weeks, not milliseconds

Every idea so far still tries to win the fight at the gate — to adjudicate humanness in the 200 milliseconds of account creation. My hypothesis — and I’ll flag clearly that it’s a hypothesis, not a proven result — is that this is the wrong battlefield, and that the defender should deliberately concede it. Make account creation cheap and provisional. Then win the fight where you have an overwhelming, structural advantage the attacker can never match: time and downstream data. A new account enters a settling period with limited reach. Over the following days and weeks, it either accrues the texture of a real human — organic reciprocal connections, content that earns genuine engagement, longitudinal behavioral consistency — or it doesn’t, and gets retroactively culled. The platform owns the outcome signals; the attacker is blind to them at creation time and can’t forge them without actually operating like a real human, at real cost. You stop fighting the unwinnable millisecond battle and fight the longitudinal one, where the house always sees more than the player. As a bonus, this gracefully absorbs the agentic case: an accountable agent’s account settles into legitimate patterns; a farm’s does not. Why it might fail: a provisional account can still do damage before it’s culled (capability-gating — restricting reach until an account settles — limits this but doesn’t eliminate it); and patient adversaries run “sleeper” accounts that behave perfectly through the settling window before pivoting to abuse. It raises the attacker’s time cost dramatically, which is real — but time is a resource a well-funded adversary can spend.

What I’d actually build

Step back from the frontier and get concrete. If I were shipping the only-human network tomorrow, here’s the architecture — pragmatic, layered, and honest about its own limits.

A score-first spine. The passive risk engine (L0–L3 feeding L5) does the everyday work, and the overwhelming majority of real users sail through having seen nothing. Proof-of-personhood and attestation are reserved as step-up challenges, invoked only when the risk score is elevated — you never make a normal human jump through a hoop. This keeps the experience humane while concentrating friction on the suspicious.

Close the own goals first. Before any of the exotic stuff, fix the application-logic flaws that defeat verification for free. These are defensive hygiene, and they’re cheaper and higher-impact than anything else on this list:

• Enforce email_verified and equivalent states server-side, on every sensitive action — never trust a client-supplied flag.
• Bind every verification token to a single account, email, and timestamp, so it can’t be replayed against another.
• Rate-limit OTP attempts and reject reused attestation across different IPs or accounts.
• Treat the server’s own response as the source of truth — assume the client will tamper with anything it can see.

Rate-limit by device and phone at creation — not as a wall, but as another term in the attacker’s cost equation, pushing them toward the expensive phone-verified tier.

Offer humanness as a mosaic, not a gate. This is where I’d apply the hard lesson of the quadrilemma: no single proof-of-personhood method should be mandatory, because every one of them excludes someone. Instead, let strong-uniqueness (an optional biometric or PoP credential), social-graph signals, and credential aggregation each contribute a partial humanness score. A user who refuses biometrics — a completely reasonable choice — can still clear the bar through other means. Inclusivity isn’t a nice-to-have here; it’s a design constraint, and a mosaic respects it where a single gate cannot.

Take a clear stance on agents. Don’t reflexively block automation — your real users will increasingly use it. Welcome accountable automation along the lines of idea five, and exclude only the anonymous farms that can’t name a human behind them.

And then — the honest part — let the flywheel catch the rest. No gate is perfect, so don’t design as if yours will be. Accept that some fakes get through creation, and lean on idea six: the longitudinal settling period, powered by downstream data the attacker can’t see, quietly culls what the gate missed. The goal of the whole system isn’t to be impassable. It’s to make dishonesty expensive and honesty easy — and to keep learning from every account that turns out to be a lie.

The tension is the point

I set out to answer a practical question — how do you keep bots off a network meant for people — and arrived somewhere more unsettling and more interesting. There is no clean answer. Every technical test of humanness is partial; every partial test is affordable to defeat; every attempt to make it airtight sacrifices privacy, or inclusivity, or decentralization. And now the rise of agentic AI is dissolving the very question, turning “are you human?” into something a consenting person with an AI assistant can no longer cleanly answer “yes” to.

It would be neater to end with a solution. But the honest ending is that the absence of one is exactly why this problem stays alive — and why it’s worth working on. The most defensible posture isn’t a perfect gate; it’s a patient, layered, economically-grounded system built around accountability rather than detection — one that makes lying expensive, makes honesty effortless, welcomes the human-behind-the-agent, and keeps getting smarter from everything it sees. For a network whose entire promise is that the people on it are people — or for any product where fake accounts quietly eat the margin — that’s not a compromise. Given where the technology actually stands in 2026, it’s the most human thing we can build.

If you’re wrestling with sign-up abuse, fake accounts, or how to let agents in without letting farms in, this is the kind of problem WBOS works on. Let’s talk.

Srijan is the founder of WBOS, an AI and product engineering studio, and built Humannnn as an independent personal project. Research for this essay was done with the help of AI research tools (CellCog and Claude) and checked against primary sources; figures are directional ranges from market, vendor, academic, and regulatory sources as of September 2026.