HumanKey

The Internet Was Never Designed to Count People

Most internet authentication systems answer some version of the same question: Can you prove that you control this credential?

That credential might be an email address, phone number, password, authentication application, OAuth account, security key, device, or passkey. Those systems can be extremely secure, but they still prove control of a credential. They do not prove human uniqueness.

A platform can verify ten email addresses without knowing whether those addresses belong to ten humans or one human. Credential uniqueness is not human uniqueness.

On most platforms, creating another identity is cheap. Create another email address. Buy another phone number. Clear the browser. Use another device. Change the IP address. Register another username. The credential changes. The human does not.

HumanKey moves the uniqueness boundary from the credential to the person.

We Are Already Sharing the Internet With More Machines Than Humans

Automation itself is not bad. Search engines, businesses, security systems, and accessibility tools all use automation. The problem begins when automated systems impersonate independent human participants.

According to Imperva's 2026 Bad Bot Report, automated systems accounted for more than 53 percent of global web traffic during 2025. Human traffic represented approximately 47 percent.

Artificial intelligence makes this considerably more important. The old bot was obvious. Those clues are disappearing. A capable automated persona can intentionally make mistakes, use slang, wait before responding, remember conversations, disagree with another bot, and maintain a fictional history.

Trying to determine whether somebody is human solely by examining what they write is going to become increasingly unreliable. HumanKey takes the opposite approach. Instead of asking whether content looks human, it asks whether the participation identity was established by a unique living human.

The Real Problem Is Not Bots. It Is Synthetic People.

There is an important difference between automation and synthetic identity. A bot that retrieves weather information is automation. A bot pretending to be an ordinary citizen while arguing about a public issue is something entirely different. That is a synthetic person.

Synthetic people become far more dangerous when they operate in groups. Five hundred apparently unrelated accounts supporting the same position can create a powerful social signal. If those accounts belong to one operator, the crowd exists only on the screen.

That is synthetic consensus.

Duplicate Accounts Distort Almost Everything

Duplicate accounts are not a minor moderation problem. They corrupt the meaning of the social graph itself.

They can manipulate follower counts, likes, polls, comments, reports, trends, hashtags, apparent popularity, apparent opposition, political enthusiasm, product popularity, and community sentiment.

They also enable ban evasion, reputation resets, harassment through alternate accounts, sockpuppeting, account farming, fake grassroots support, manufactured customers, and manufactured fans.

What a Bot Farm Can Actually Do

A bot farm does not need to convince everybody. It only needs to alter the environment around the conversation.

A coordinated network can introduce a narrative, repeat it through apparently unrelated accounts, like and share those accounts, attack competing narratives, create the appearance of momentum, expose genuine humans to the content, and encourage genuine humans to continue the amplification.

The machine does not need to replace human opinion. It only needs to influence the environment in which human opinion develops.

Russian Influence Operations

In July 2024, the United States Department of Justice announced action against a Russian government-linked social media bot farm involving 968 fictitious accounts. The operation incorporated artificial intelligence and created false personas that frequently purported to belong to people in the United States.

Those personas were used to distribute narratives supporting Russian government objectives.

A message openly issued by a foreign government is interpreted one way. The same message apparently coming from hundreds of ordinary Americans is interpreted another way. That difference is exactly why synthetic identities have value.

Chinese Influence Operations

The United States Department of Justice has documented another example involving China's Ministry of Public Security. Federal prosecutors alleged that members of the 912 Special Project Working Group created thousands of fake social media personas. Some purported to be Americans.

According to DOJ, those personas were used to promote PRC narratives, attack critics, harass dissidents, and create the appearance that ordinary users supported positions favored by the Chinese government.

The technological change is the ability to surround propaganda with synthetic citizens.

Manufacturing Consensus

The traditional internet account model makes identity multiplication economically attractive.

Without proof of personhood, one operator plus automation plus 10,000 credentials can appear to be 10,000 humans.

HumanKey changes the resource requirement. The security objective is straightforward: 10,000 independent HumanKey identities should require something approaching 10,000 independently enrolled humans.

That does not eliminate coordinated movements. Ten thousand real people can still organize. What changes is the ability of one person to impersonate those 10,000 people.

Hash Humanity

Hash Humanity begins with a different assumption about social media. People should not have to compete with unlimited artificial identities simply to have a conversation.

The platform is built around one human, one account; human verification without mandatory public identification; persistent identity; no engagement-ranking algorithm designed to maximize provocation; no behavioral advertising dependency; and freedom of human expression.

HumanKey proves humanity and uniqueness. It does not determine whether somebody's opinion is correct.

HumanKey Architecture

HumanKey separates several security problems that are often incorrectly treated as one problem.

It asks whether a live person is physically participating, whether that person appears to have enrolled already, whether the person can prove membership without publicly revealing biometric identity, whether the established human can authenticate securely later, and whether that human can recover the same identity after losing authentication credentials.

No single component is expected to solve the entire problem. HumanKey uses layers.

Consent Comes First

HumanKey does not treat access to a camera as permission to conduct biometric processing.

Biometrics are sensitive. HumanKey therefore gates biometric operations behind the required consent state. The implementation includes automated tests covering consent gating and invalid session behavior.

Liveness

HumanKey uses AWS Face Liveness as its production liveness provider. The purpose is to determine whether a live participant is physically present rather than simply accepting a facial image.

HumanKey's implemented policy has used a liveness confidence threshold of 85.

Liveness makes attacks involving photographs, displayed images, prerecorded material, and other presentation techniques more difficult. It is one part of a larger security system and is not presented as mathematically infallible.

What Happens to the Face

HumanKey does process a person's face. There is no honest way to perform facial biometric comparison without processing facial information.

AWS Rekognition collections extract and retain mathematical facial representations used for comparison rather than operating as a conventional public photo album of enrolled users.

The face vector is still biometric information and should be treated as sensitive. The privacy distinction is that the persistent biometric uniqueness record is a mathematical representation used for comparison, rather than an ordinary public photograph of the user's face.

Duplicate Detection

After liveness succeeds, HumanKey compares the candidate against the enrolled biometric population. The production AWS path has used SearchUsersByImage with a similarity threshold of 90.0.

If the candidate strongly corresponds to an existing HumanKey participant, the system does not simply issue another identity. The event becomes duplicate protection or account recovery depending upon context.

For a new unique participant, the AWS enrollment path includes creation of the Rekognition user and facial association process.

This is the heart of HumanKey's duplicate-account resistance.

Why Duplicate Resistance Matters So Much

A banned user on a conventional platform can create another email address. A scammer can abandon a damaged reputation. A harasser can create five accounts. A political operator can create hundreds of credentials.

HumanKey changes that equation. Another email address does not create another face. Another browser does not create another human. Another phone does not create another human. Another IP address does not create another human.

The uniqueness check follows the human rather than the credential.

That dramatically raises the cost of sockpuppeting, account farming, ban evasion, harassment through alternate accounts, follower inflation, poll manipulation, reputation resets, fake grassroots campaigns, coordinated artificial amplification, and manufactured consensus.

This is not merely a login feature. It changes what an account means.

Zero-Knowledge Membership

Proving human uniqueness creates an obvious privacy question. If biometrics establish that somebody is unique, does the social platform need access to those biometrics every time that person participates? No.

HumanKey separates enrollment from participation.

The point is to establish membership in a set of verified humans and allow that membership to be demonstrated without unnecessarily exposing the underlying biometric identity.

Nullifiers

Anonymous participation creates another challenge. If the system does not publicly identify the person, how can it stop one valid member from repeatedly performing an action that should only happen once?

Nullifiers provide scoped accountability. Conceptually, a nullifier is derived from an identity secret and an action scope.

The system can determine that a valid HumanKey member has already performed a particular scoped action without necessarily determining the person's public legal identity.

Passkeys

A person should not need to perform biometric enrollment every time they log in. Once HumanKey establishes the human, routine authentication moves to passkeys.

The server issues a cryptographic challenge. The user's authenticator signs it with a private key. The signed response returns to the server. The server verifies it with the public key and authenticates the user.

The private key remains with the authenticator. The face establishes the human. The passkey authenticates the established human afterward.

Account Recovery

Recovery is not an afterthought in HumanKey. It is one of the most important security boundaries in the protocol.

A user can lose a phone. A computer can fail. A passkey can be deleted. An authenticator can become inaccessible. The human still exists.

HumanKey follows a simple recovery principle: Recover the human. Do not recreate the human.

Enrollment asks whether this is a new unique human. Recovery asks whether this is the human who already owns an existing HumanKey. Those are completely different operations.

The HumanKey Recovery Process

Recovery does not intentionally create another HumanKey identity. The same human returns to the same account.

The One-Scan Recovery Design

During development, a recovery problem was identified where facial verification could occur twice. That was not the intended architecture.

Recovery should require one live biometric ceremony for the recovery event. The corrected design allows the successful liveness result to continue through identity resolution rather than automatically requiring another redundant scan.

This reduces unnecessary biometric processing, user friction, provider calls, and the possibility of conflicting biometric state.

Recovery Preserves One Human, One Account

Recovery therefore reinforces HumanKey's Sybil resistance rather than bypassing it.

Recovery Failure

A failed recovery match must not become a shortcut to creating another account.

If the system cannot establish a sufficiently strong relationship with an existing HumanKey, the correct result is controlled failure or retry.

Security-sensitive ambiguity should fail closed. HumanKey development has also included handling for stale biometric-only states so legitimate users are not incorrectly trapped by inconsistent identity state.

Recovery Security Testing

Recovery has been tested independently because of the damage a weak recovery system could do to the one-human-one-account model.

HUMANKEY RECOVERY VALIDATION Tests executed: 10 Tests passed: 10 Tests failed: 0 Result: PASS

The test run followed investigation of the redundant face-scan behavior. When the corrective patch was subsequently checked, the implementation reported that the relevant correction was already present and no additional file changes were required.

The regression suite completed 10 passed and 0 failed. This does not mean HumanKey can never contain another bug. It means every test in that recovery regression suite passed at that point in development.

Broader HumanKey Testing

Recovery is only one part of the testing program.

Testing has covered biometric consent, AWS gating, invalid sessions, required capture state, recovery, duplicate detection, provider response handling, biometric searching, passkey authorization, replay protection, state transitions, calibration, multi-template behavior, rate limiting, and blocked attempts.

The purpose of the test suite is not merely to prove that legitimate enrollment works. A security system must also prove that invalid operations do not work.

Rate Limiting

Proof of personhood does not make humans harmless. A real human can spam, scrape, automate activity, or attack an API.

HumanKey combines identity scarcity with rate controls. Implemented safeguards have included 3 applicable liveness attempts within a 24-hour control window, a 60-second cooldown, a 500-per-day global AWS liveness ceiling, HTTP 429 rejection, idempotency protections, an administrative kill switch, and automated blocked-attempt testing.

Proof of personhood limits identity multiplication. Rate limiting limits action multiplication.

Replay Protection

A successful security ceremony should not become a permanent reusable ticket.

This principle applies particularly to credential authorization and security-sensitive enrollment state.

Server-Side Authority

The browser is not trusted to decide whether somebody is human.

A malicious user controls their browser. They can modify JavaScript, alter requests, manipulate local storage, and bypass interface screens.

Security decisions therefore belong on the server. The interface can request a state transition. The server determines whether the transition is valid.

Software Architecture

HumanKey and Hash Humanity use different technologies for different jobs.

HumanKey uses Python for biometric and security service logic and testing, FastAPI for the API layer, Pydantic for structured validation, AWS Face Liveness for production liveness verification, AWS Rekognition for production biometric uniqueness and matching, Semaphore for zero-knowledge membership components, and passkeys for cryptographic routine authentication.

Hash Humanity uses React, JavaScript and JSX, HTML, CSS, and Firebase for appropriate application, hosting, account, and real-time functionality.

The biometric authority is deliberately separated from the presentation layer.

Language Accessibility

A human network should not define humanity according to language.

Hash Humanity has been developed with internationalization support including English, Spanish, Portuguese, Chinese, German, French, Malay, and Korean.

If the objective is a human social network, geographical and linguistic boundaries should not determine who can participate in the conversation.

Security Threat Model

HumanKey considers several attacker classes.

Automated bot: attempts participation without a legitimate human. Defense includes liveness, server-side enrollment state, and identity controls.

Single-human Sybil attacker: attempts to create many identities. Primary defense is biometric uniqueness.

Account farm: attempts to manufacture large numbers of verified accounts. Defenses include liveness, uniqueness, and rate limits.

Presentation attacker: attempts photographs or prerecorded imagery. Defense is AWS Face Liveness.

Credential attacker: attempts to steal login access. Defense is passkey public-key authentication.

Replay attacker: attempts to reuse previously valid security artifacts. Defenses include expiry, consumption state, and server-side transitions.

Ban evader: attempts to return under another identity. Defense is persistent biometric uniqueness.

Influence operation: attempts to manufacture thousands of apparent independent citizens. Defense is changing the scarce resource from accounts to actual humans.

What HumanKey Does Not Do

HumanKey does not determine truth.

A verified human can still lie, spread misinformation, be paid, participate in propaganda, harass somebody, or simply be an asshole.

HumanKey does not attempt to technologically sanitize humanity. The protocol addresses a narrower problem: one human should not cheaply become a hundred apparent humans.

Human disagreement remains. Synthetic population is what becomes dramatically harder.

Why That Difference Matters

Consider two platforms.

Platform A allows one human to create fifty accounts.

Platform B restricts one human with high confidence to one persistent identity.

Both platforms contain imperfect people, but they do not have the same social dynamics. On Platform A, one attacker can appear to be fifty people. On Platform B, fifty identities should require something approaching fifty enrolled humans.

That changes reputation, moderation, polls, voting, follower counts, harassment, ban enforcement, community governance, apparent popularity, political organization, and synthetic consensus.

Toward a Social Graph of Humans

Most social networks contain graphs of credentials. HumanKey attempts to create something closer to a graph of people.

If ten conventional accounts disagree with you, you cannot automatically know whether ten people disagree with you. It might be ten. It might be five. It might be one.

If ten valid HumanKey identities disagree with you, the architecture is specifically designed to provide substantially stronger evidence that ten independently enrolled humans are represented.

That does not make them right. It makes them real participants.

Current Validation Status

AWS Face Liveness: Implemented AWS biometric uniqueness: Implemented SearchUsersByImage: Implemented AWS user and face association: Implemented Biometric consent gating: Implemented Passkey authentication: Implemented Passkey replay protection: Implemented Semaphore membership components: Implemented Account recovery: Implemented Single-scan recovery correction: Implemented Recovery regression tests: 10 / 10 passed Broader security regression tests: 182 passed Broader regression skipped: 1 Rate-limit safeguards: Implemented Global AWS liveness ceiling: 500 / day Administrative kill switch: Implemented

These results represent the implementation and testing status documented at the time of this white paper. They should change as the system changes.

Security Is Never Finished

No legitimate security engineer should claim that passing a test suite makes a system permanently secure.

Attackers change. Providers change. Dependencies change. Browsers change. Artificial intelligence changes.

HumanKey therefore requires continuing regression testing, adversarial testing, provider monitoring, dependency maintenance, threshold calibration, penetration testing, privacy review, abuse monitoring, incident response, and threat-model revision.

The goal is not to claim that HumanKey is impossible to defeat. The goal is to make defeating one-human-one-account dramatically more difficult and expensive than simply creating another internet account.

Where This Is Going

Artificial intelligence is going to become better at pretending to be us. That is not science fiction. It is already happening.

Synthetic text will improve. Synthetic photographs will improve. Synthetic video will improve. Autonomous agents will improve. Persona management will improve.

Eventually, asking whether a message sounds human will tell us almost nothing about whether a human actually produced it.

So the question has to change.

That is the problem HumanKey was built to address.

Conclusion

The internet does not have a shortage of accounts. It has a shortage of confidence in what those accounts actually represent.

Machines now generate the majority of measured web traffic. Governments have deployed fake social media personas. Bot farms have impersonated citizens. Disposable accounts enable harassment, fraud, ban evasion, artificial popularity, account farming, and manufactured consensus. Artificial intelligence is making those operations cheaper and more convincing.

HumanKey uses liveness to establish live presence. It uses biometric uniqueness to make duplicate enrollment dramatically harder. It uses mathematical biometric representations so persistent uniqueness does not require turning the platform into a public gallery of enrollment photographs. It uses zero-knowledge membership to separate proof of humanity from public identity. It uses passkeys so users do not need to continually scan their faces just to log in. It uses biometric recovery to reconnect a person to the same identity when authentication credentials are lost. It uses rate limits to constrain abuse even when the actor is human. It uses server-side state controls and automated regression testing to enforce those boundaries.

The objective is not to make everybody agree. I would not want that internet.

The objective is not to decide what people are allowed to believe. I would not want that internet either.

The objective is much simpler.

Let humans argue with humans.

Let people disagree. Let people change their minds. Let people be unpopular. Let people say things other people hate.

But when 1,000 apparently independent people are speaking, there should be a meaningful technical reason to believe that something approaching 1,000 actual humans are behind those voices.

Not one person with 1,000 email addresses. Not an account farm. Not a government running synthetic citizens. Not an AI system operating a crowd that does not exist.

Actual people.

That is what HumanKey is trying to restore to the internet.

Not agreement. Not conformity. Not control.

Human presence.

Because in an internet increasingly filled with machines, proof that somebody is actually there is becoming one of the most valuable things we have.

One human. One account.

HumanKey.