How to mathematically prove your users aren't AI agents

Picture this. You are selling limited-edition sneakers. You drop a thousand pairs at noon. You configure your rate limits by IP address, you add invisible CAPTCHAs to the checkout flow, and you require SMS phone verification to confirm the order. Within thirty seconds, bots buy every single pair anyway. The real people who wanted the shoes get nothing.

The reason your defenses failed is that an IP address, a device fingerprint, or a phone number are all just proxies for the concept of a human. And proxies can be bought in bulk. The moment adversaries figure out how to acquire those proxies cheaply, the defense collapses. You can rotate through residential proxy networks or buy phone numbers from automated farms. None of these checks actually bind the verification to a real, unique person.

The Uniqueness Puzzle

To stop this at the root, you have to stop asking for proxies. You have to solve a mathematical puzzle. You need a way to mathematically prove a user is a real, unique human, without actually knowing who they are.

Proving uniqueness is structurally different from standard authentication. We are very accustomed to authentication. Think about single sign-on, passkeys, or Face ID on your phone. These are one-to-one matching problems. Your phone stores a single facial template locally. When you look at the screen, it takes a fresh capture and compares it against that one stored template. If your system has a per-comparison error rate of one in a million, it works beautifully. It unlocks for you and rejects almost everyone else.

But uniqueness is a one-to-many matching problem. If that sneaker retailer wants to know if a buyer is different from every other person who has already checked out, they aren't comparing a credential against one template. They are comparing it against a global population. If you take that same one-in-a-million error rate and check it against a billion candidates, you will generate roughly a thousand false matches per query. To make global uniqueness viable, your per-comparison error rate has to be strictly better than one in a hundred billion. Standard device templates and passkeys cannot do that. The math completely changes.

The Anonymized Solution

So how do you do it? If a service does not know who I am, how can it definitively prove it has never seen me before?

You cannot centralize this into a database. If you put a billion high-entropy biometric signatures on one server, you have built a surveillance apparatus. Instead, this requires a shift to Anonymized Multi-Party Computation, or AMPC.

When a user's biometric signal is captured to prove they are human, that signal is immediately split into three pieces of statistically random noise. Those three pieces are sent to three completely independent nodes, operated by different organizations in different legal jurisdictions. No single node receives the full picture. By looking at their isolated fragment, they see nothing but noise.

Through secure multi-party computation, these nodes jointly calculate a binary answer. They ask, "Does this scattered reading match any scattered reading we have already enrolled?" They produce a simple yes or no. The pieces are combined only in the abstract space of the computation. The data is never reconstructed on any actual machine. This determines global uniqueness without exposing the underlying identity to anyone, not even the system operator.

Once a human is verified, they are not handed a single static secret. Holding a single key is brittle. If you lose your phone, you do not want to lose your proof of humanity. Instead, the verified human becomes an abstract account in a public registry. This account holds a list of public keys, called Authenticators, that are authorized to act on the user's behalf. Your phone wallet might hold one key. A hardware security token might hold another. If your phone is stolen, you initiate a flow through a designated Recovery Agent. They re-verify your physical uniqueness, revoke the stolen key on the registry, and authorize a new one.

Enforcing Rules with Zero-Knowledge

That handles the global registry. But the relying party, our sneaker retailer, still needs to enforce its own rules. It needs to know if the same human is trying to buy shoes twice, and it needs to do this without tracking the user across the rest of the internet. This is handled through zero-knowledge proofs and a cryptographic primitive called a nullifier.

A nullifier is a string of numbers derived from three specific inputs combined together. The inputs are the user's verified credential, the relying party's identifier, and the specific action taking place. Generating this requires a distributed network of Oblivious Pseudorandom Function nodes. The user sends a blinded version of their query to these nodes. The nodes compute on the blinded value without knowing what it represents, and the user unblinds the result.

Because the math is deterministic, the exact same combination of user, service, and action will always produce the exact same nullifier string. If the sneaker site sees that string twice, they know the exact same human is attempting the exact same action again. The purchase gets blocked. But if that same user goes to a ticketing website later that afternoon, the relying party identifier changes. The resulting nullifier is entirely different. The two services have no way to correlate the strings.

To prevent replay attacks on a single service, there is an Oblivious Nullifier Pool that records used nullifiers, but it reveals absolutely zero metadata about who is doing what.

The Practicality Problem: Friction vs. Fraud

The cryptography here is elegant. The system design is a masterclass in zero-knowledge architecture. But we have to separate the math from practical applicability. Deploying this kind of uniqueness infrastructure is cautious territory.

Most businesses do not actually need cryptographically guaranteed uniqueness. What they need is for the cost of acquiring bot proxies to exceed the profit margin of the transaction. Tools like Cloudflare Turnstile or reCAPTCHA Enterprise execute passively in the background. They do not care if you are unique in the universe. They care if your traffic pattern looks expensive to spoof.

If you integrate an SDK that requires a user to present a zero-knowledge proof of their humanity, you are taking on massive operational friction. The user is entirely bottlenecked by their physical verification status. If a startup mandates this kind of proof for a free trial to stop server abuse, it will absolutely stop the bots. But it will also block nearly every legitimate early adopter who hasn't verified themselves on this specific network. You introduce a severe bootstrap problem. Applications will not enforce the requirement until users hold the credential, and users will not acquire the credential until applications require it.

If your primary metric is user acquisition, the cart abandonment risk here is fatal. This infrastructure is strictly for platforms facing existential financial bleed from automated fraud, where you are willing to sacrifice significant user conversion just to stop the scalping.

The AI Agent Dilemma

There is one more layer to this architecture, and it addresses a reality we are running right into. We are entering a future where we actually want our AI agents to act on our behalf. You might want an agent to monitor that limited-edition shoe drop and buy it for you while you are away from your keyboard. Or book a flight. Or negotiate a bill. Standard bot defenses treat all automated traffic as adversarial. But if we block the bots, we defeat the exact automation the user is paying for.

The uniqueness architecture handles this through delegation. Because the human's identity is an abstract account with rotating keys, a human can bind an AI agent to their verified status. Using delegation registries and SDKs like AgentKit, an AI agent registers its address and ties it to the human's credential. When the agent hits the retailer's API, the retailer verifies the agent is backed by a unique, living human, without knowing which human. The agent's activity consumes the human's quota.

By default, this setup might allow an agent three uses per human per service before standard payment rules apply. A single human cannot spin up ten thousand agents to bypass the rules, because all ten thousand agents would deplete that single human's quota instantly. But this delegated human quota is entirely untested at scale. Right now, agent traffic is minimal. As autonomous agents scale up and take on more continuous background tasks, the idea of a per-human cap will face entirely new abuse patterns. Will a secondary market emerge where people lease out their human quotas to automated agent farms? If an agent misbehaves, who governs the revocation of that specific nullifier pool? The protocol handles the math, but the application layer will have to handle the messy reality of human behavior.

The Fundamental Shift

The core takeaway here is a fundamental shift in how distributed systems handle identity. The standard identity stack relies on matching a secret. That worked when the primary threat was someone guessing a password. But when the primary threat is automated agents perfectly mimicking legitimate human traffic, the old models break down.

Defending against that requires moving from authentication to global uniqueness. It requires nullifiers, secure multi-party computation, and a willingness to separate the proof of a human from the identity of the human. The mathematical primitives are ready. The open question is whether the friction of adopting them will ever be lower than the pain of the bot traffic itself.

TAKEYOURPILLS.TECH

Go ship something.