A few days ago I read a post by Guillermo Weinmann from AlphabetWare on digital identity for AI agents. I’d recommend reading the original, it’s sharp, technically precise, and identifies something most breach post-mortems miss entirely. It inspired me to apply his argument to the work we’re doing at Realeyes with VerifEye. I’ve kept his core thesis intact because I think he’s right!
“When registering an agent costs nothing, whoever creates the most identities controls the outcome.”
The breach nobody framed as an identity problem
In February 2026, a security researcher at Wiz disclosed a misconfiguration in a platform called Moltbook, a social network built for AI agents. What they found was striking: 1.5 million agent registrations, traced back to around 17,000 real people. Roughly 88 agents per human. No identity verification. No rate limiting. Just an API key, a loop, and an open door.
The story was covered as a developer error. Flip the right switch in Supabase, problem solved. But the more interesting question (the one that didn’t make the headlines) is why the authentication layer never thought to ask whether a person was behind the registration request in the first place.
The oldest attack in distributed systems
What Moltbook experienced has a name: a Sybil attack. One actor, many identities, each appearing legitimate. The term comes from a 2002 Microsoft research paper, but the concept is as old as ballot-stuffing. In digital systems, reputation, rate limiting, and moderation all depend on identity being scarce. When identity is free, whoever manufactures the most of it wins.
This isn’t a problem unique to niche AI platforms. It runs through X, TikTok, Facebook, and most of the open web. Moltbook just made the arithmetic visible.
The tools we already have and why they’re not enough
There are free, widely available tools that would have made the Moltbook attack harder. Google reCAPTCHA and Cloudflare Turnstile both gate registration endpoints and distinguish automated requests from real browser sessions. Turnstile in particular is built on Privacy Pass, an IETF-standardised protocol with strong privacy credentials. Both are a few lines of code to implement.
For a non-technical reader: think of these as the digital equivalent of a doorbell camera. They deter casual attempts and log suspicious behaviour. But they don’t change what’s on the other side of the door.
The problem with Moltbook wasn’t just that 1.5 million agents got in. It was that once they were in, 1.5 million real API keys sat in a database table readable by anyone curious enough to look. A Turnstile at registration would have reduced the number of keys stored. It wouldn’t have changed what happened when the door to that database was left open.
Every authentication system that touches credentials leaves residue — API keys, session tokens, identity documents. Aggregated at scale, that residue is the reason breaching the system is worth the effort. Require a passport scan and a facial photo to create an agent account, and you’ve just made your database considerably more valuable to an attacker.
“The answer isn’t a stronger lock on the vault. It’s an architecture that doesn’t need one.”
The deeper fix: stop building vaults
The more durable answer isn’t better locks. It’s an architecture that doesn’t accumulate secrets worth stealing.
The cryptographic building blocks for this have existed for decades. Blind signatures, first described by David Chaum in 1982, allow a system to verify that something is genuine without ever seeing what it’s verifying. The Privacy Pass protocol, standardised by the IETF in 2024, puts this into practice: the thing you authenticate with is never seen by the thing that issued it, and the thing that verifies it never learns who you are. You prove you’re human without handing over anything that can be stored, aggregated, or stolen.
For the non-technical reader: imagine proving you’re over 18 to enter a venue, without showing your name, address, or date of birth – just a confirmation that you meet the threshold. The bouncer learns what they need to know. Nothing else enters the record.
Nobody has yet assembled these primitives into a working standard for agent authentication. That gap is where the next wave of identity infrastructure needs to be built.
Where human verification fits
This is where the conversation moves from abstract architecture to practical deployment.
Sybil attacks, device farms, and agent flooding all share a common root: the absence of a verified human in the loop. Not a password. Not an API key. Not a document stored in a database. A confirmed human presence at the point of registration, with nothing retained that can later be compromised.
VerifEye’s approach is built around exactly this principle. Liveness detection confirms a real person is present, not a photo, video replay, or AI-generated deepfake. A mathematical facial embedding is generated and used for uniqueness checking; the source image is deleted within one second. No photograph is stored. No document is retained. The verification happens, the proof exists, and there is nothing in the database worth stealing.
Applied to agent registration, this means one verified human can authorise their agents and the system can enforce that boundary without accumulating a vault of sensitive credentials in the process.
“A face is the one credential that can’t be scripted, looped, or stolen from a database.”
What this means for the agent era
The tooling for building AI-powered applications has outpaced the tooling for securing them. Platforms like Moltbook can be built in a weekend. The identity infrastructure that should underpin them is still being assembled.
The right response isn’t to slow down deployment or pile on more document verification. It’s to build human presence into the foundation of agent authentication, cheaply, privately, and in a way that leaves nothing behind worth taking.
A gate checks who’s at the door. The real question is what you’re leaving inside.
Realeyes builds privacy-preserving human verification for authentication. VerifEye’s Passkeys Plus adds human assurance to existing passkey implementations without storing photographs or identity documents. Learn more →