Personhood Credentials Guide: Proof of Human Online

CAPTCHAs and behavioural bot scores no longer separate people from software reliably, and full identity verification is too intrusive for most sign-ups, which leaves online services without a privacy-respecting way to ask "is there one real person behind this account or this agent?". Personhood credentials (PHCs) are a proposed answer: digital credentials that let someone prove they are a real, unique person without revealing who they are. This guide explains the concept as defined in the 2024 research paper that named it, compares the main design families (government credentials, biometric uniqueness schemes such as World ID, privacy tokens and wallet-based credentials), covers how proof of human is now being attached to AI agents, and sets out how a relying party should evaluate, pilot and monitor these schemes. It is written for identity architects, fraud and trust-and-safety leads, and privacy officers.

Key takeaways

A PHC proves personhood, not identity. The defining paper sets two requirements: credential limits (an issuer gives each eligible person at most one credential) and unlinkable pseudonymity (services see a per-service pseudonym, and neither issuers nor colluding services can link activity).
Uniqueness is the hard part. Proving "a human" is easy to fake at scale; proving "a human who has not already registered" needs either a trusted registry such as a government ID or a biometric deduplication step, each with its own privacy and exclusion costs.
Agents are the new use case. Schemes now let a person bind an AI agent to their personhood credential so a website can see that a verified human stands behind it, as with World's AgentKit, announced in beta in March 2026.
Treat it as a risk signal, not an access decision. Credentials can be stolen, rented or sold; PHCs reduce scale abuse but do not prove the person present is the credential holder or that their intent is benign.
Privacy law shapes the choice. Biometric schemes face regulator scrutiny: Bavaria's data protection authority ordered Worldcoin to provide a GDPR-compliant deletion procedure in December 2024.

What a personhood credential is

The term comes from "Personhood credentials: Artificial intelligence and the value of privacy-preserving tools to distinguish who is real online" (Adler, Hitzig, Jain and co-authors, first published August 2024). The paper defines PHCs as credentials that let users show they are real people, not AIs, without disclosing personal information. It argues that two trends make them necessary: AI is becoming indistinguishable from people online (content, avatars and actions) and increasingly scalable because it is cheap and widely available. It also notes that a PHC system need not be biometric and could be issued by governments or other trusted institutions.

Concept	What it proves	What it reveals to the service	Typical example
Identity verification (KYC)	Who you are, to an assurance level	Name, date of birth, document data	Bank onboarding to NIST SP 800-63A IAL2
Age or attribute proof	One attribute, such as over 18	The attribute only, if selective disclosure is used	Mobile driving licence presentation
Bot challenge or attestation token	That a client passed a check or that a device attested	Little or nothing; not unique per person	CAPTCHA, Privacy Pass token
Personhood credential	That a real, unique person holds the credential	A pseudonym that is stable for that service only	World ID nullifier per app and action
Agent backed by personhood	That a verified unique person authorised this agent	A pseudonymous link from agent to a human credential	World AgentKit

The problems PHCs aim to solve

Sockpuppets and fake engagement: one operator running many personas. Credential limits cap verified accounts per person. See the Bot Farms and Fake Engagement Guide.
Ban evasion and bot attacks: abusers re-registering without limit. A per-service pseudonym that is stable for a person lets a service make bans stick without learning who the person is.
Sybil attacks on votes, airdrops and quotas: any system that allocates one unit per person. See the Sybil Attacks Guide.
Misleading agents: AI agents that misrepresent whose goals they serve. The paper lists verified delegation, where an assistant shows it acts for a real person, as a benefit.
Mass account creation: the GemStuffer RubyGems campaign shows an AI agent swarm mass-creating accounts on a public registry, the kind of scale abuse that per-person limits are designed to blunt.

What PHCs do not solve: a real person tricked by a deepfake on a live call, as in the Arup deepfake fraud, is a verification-of-counterparty problem; that needs the controls in the Deepfake-Resistant Identity Verification Guide.

Design families compared

Family	How uniqueness is established	Privacy model	Main weaknesses
Government-issued digital credentials (mobile driving licences, EU Digital Identity Wallets under Regulation (EU) 2024/1183)	The state registry: one citizen, one credential	Depends on wallet design: selective disclosure and per-service pseudonyms are possible but not guaranteed in every scheme	Excludes people without state ID; issuer may see usage if the protocol phones home; uneven availability across countries
Biometric uniqueness schemes (World ID with Orb iris verification)	Biometric deduplication at enrolment, then a self-custodial credential	Zero-knowledge proofs; a nullifier derived from the user, the app and the action lets a service detect repeats without identifying the user	Biometric processing raises GDPR and similar concerns; enrolment hardware is not everywhere; trust concentrated in one operator
Attestation tokens (IETF Privacy Pass, RFC 9576 to 9578)	None inherent; the Attester decides what it checks (CAPTCHA, device attestation, account state)	Strong unlinkability between issuance and redemption, even if Issuer and Attester collude	Proves a check was passed, not that the person is unique, unless the Attester enforces per-person limits
Wallet-based verifiable credentials (W3C Verifiable Credentials, OpenID4VP)	Inherited from whichever issuer signed the credential	Selective disclosure formats can limit data shared	Uniqueness and unlinkability depend on credential format and presentation protocol
Social vouching and web of trust	Existing members vouch for new ones	Varies	Collusion rings; slow to scale; hard to audit

The Privacy Pass architecture is covered in detail in the CAPTCHA and bot challenges guide; wallet protocols in the Verifiable Credentials Guide and OpenID for Verifiable Presentations (OpenID4VP) Guide.

How a nullifier-based scheme works

World ID's documentation describes the pattern most biometric and cryptographic schemes share. A relying party defines an action, such as "create account" or "claim offer". The user's authenticator generates a zero-knowledge proof that it holds a valid credential from a registered issuer, plus a nullifier derived from the user, the relying party and the action. The relying party stores the nullifier: the same person repeating the same action yields the same nullifier, so a second claim is rejected, but nullifiers for different apps cannot be linked. An optional signal binds extra data, such as a vote choice, so it cannot be altered after the proof. In World ID 4.0, issuers must be registered in a credential schema issuer registry and the former App ID is called an RP ID.

Proof of human for AI agents

As agents start to shop, book and post on behalf of users, services want to know two things: which agent this is, and whether a real person stands behind it. The first is agent authentication, covered in the Know Your Agent (KYA) Guide and the Web Bot Auth and HTTP Message Signatures for Agents guide. The second is personhood.

AgentKit: Tools for Humanity announced AgentKit in beta on 17 March 2026. Users register their agents with their World ID, and the agent can then show websites that a distinct, verified human approves its actions; the scheme requires an Orb-verified World ID and is built as an extension to the x402 payment protocol (developed by Coinbase and Cloudflare), in coordination with Coinbase, according to TechCrunch. Treat details as subject to change while the product is in beta.
Per-person agent quotas: a service can cap how many agents, purchases or sign-ups each verified human can drive, using the per-service pseudonym, without learning the person's identity.
Accountability boundary: a personhood link shows that some unique person authorised the agent; it does not prove that person is who they claim to be, that they are a customer in good standing or that the specific action was authorised. Combine it with delegation evidence; see the Delegation Chains and Attenuated Authority for AI Agents guide.

Where identity fits

PHCs sit between anonymous access and full identity proofing. Map them to your assurance model explicitly. NIST SP 800-63A-4 defines IAL1 to IAL3 for proving who someone is, and it now requires credential service providers doing remote proofing to detect virtual cameras, device emulators and jailbroken devices, analyse submitted media for manipulation, and meet a presentation attack detection threshold (IAPAR below 0.07, tested to ISO/IEC 30107-3:2023). A PHC is not an IAL: it answers "unique human?" rather than "which human?". Where a regulated process needs identity, PHCs can reduce friction earlier in the journey but cannot replace proofing. See the NIST SP 800-63A-4 Identity Proofing (IAL) Guide.

Risks and how to evaluate a scheme

Risk	Source	Question to ask the scheme operator
Credential theft, rental or sale ("authentication farms")	Named in the PHC paper as a robustness challenge	How is the credential bound to the holder's device; can it be re-bound; what re-verification exists after suspected transfer?
Exclusion	Equitable access challenge in the PHC paper; Privacy Pass guidance to support multiple attestation methods	Who cannot enrol (no ID, no enrolment site nearby, disability); what fallback exists?
Concentration of power	"Checks on power" challenge in the PHC paper	Can one issuer revoke or deny personhood globally; is there more than one issuer; how are disputes handled?
Biometric data protection	BayLDA order against Worldcoin, 19 December 2024	What biometric data is retained, where, for how long, on what legal basis, and how is erasure honoured?
Linkability	Unlinkable pseudonymity requirement	Does the issuer learn where credentials are used; can relying parties correlate pseudonyms?
Spoofed enrolment	Deepfake and injection risks described in SP 800-63A-4	What presentation and injection attack detection protects enrolment?

The Bavarian order required a GDPR-compliant deletion procedure within one month of the decision taking effect, explicit consent for certain processing steps and deletion of some records collected without sufficient legal basis; the company said it would appeal. Before relying on any biometric scheme, run a data protection impact assessment and check the current regulatory position in each market you serve.

Decision guidance

Choose a PHC when the harm is scale (fake accounts, ban evasion, giveaway abuse, agent swarms) and you do not need to know who the person is.
Choose identity proofing when regulation or liability requires a named person: payments, KYC, age-restricted goods, employment.
Choose attestation tokens when you mainly want to reduce CAPTCHA friction for legitimate clients; they do not enforce uniqueness on their own.
Accept several schemes: no single scheme reaches everyone. Accepting a government wallet, a PHC and a fallback path reduces exclusion and avoids lock-in.
Small services: integrate through an identity provider or fraud platform that already supports the schemes rather than building verification directly.
Large platforms: run controlled experiments measuring abuse reduction against drop-off, and publish which schemes you accept and why.

Implementation approach

Define the abuse case and metric: for example duplicate promotional claims per 1,000 sign-ups, or agent-driven purchases later charged back.
Complete a privacy assessment: data flows, retention, legal basis, cross-border transfer, and what the issuer learns.
Pilot as an optional step-up: offer the credential as one way to lift limits, not as a mandatory gate; keep existing controls running.
Store only what you need: the per-service nullifier or pseudonym and the verification result, never biometric data.
Bind to risk decisions: feed the result into your fraud engine as a signal with a weight, alongside device, velocity and payment signals.
Test failure paths: issuer outage, revoked credential, a user who loses their device, and a credential presented from an unusual context.
Roll back cleanly: because the pilot is optional, switching it off reverts to existing controls; keep pseudonyms only for the declared retention period.

Detection and measurement

Abuse rate by verification status: fraud, spam or chargeback rate for PHC-verified accounts versus unverified ones.
Duplicate attempts blocked: repeated nullifiers or pseudonyms per action.
Completion and drop-off: share of users offered the step who complete it, broken down by region and device.
Credential resale indicators: one personhood pseudonym appearing behind many devices, locations or agents in a short period.
Agents per verified human: distribution of agents or automated sessions linked to each pseudonym, with alerts on outliers.
Appeals and false denials: volume and resolution time, a measure of exclusion harm.

Common failure patterns

Treating personhood as identity: letting a PHC satisfy a KYC or age requirement it was not designed to meet.
Mandatory single scheme: excluding users who cannot or will not enrol, and handing one operator control over access.
Storing more than the pseudonym: logging device identifiers or raw proofs alongside the nullifier, which recreates the linkability the scheme was meant to prevent.
Ignoring transfer: no signal for one credential suddenly backing many devices or agents.
No fallback during outages: the issuer or verification service goes down and sign-ups stop.

Framework mapping

Framework	Reference	Application
NIST CSF 2.0	PR.AA-02	Identities proofed and bound to credentials based on the context of interactions
NIST SP 800-53 Rev. 5	IA-8, IA-12, RA-3	Authenticating non-organisational users, identity proofing, risk assessment of the chosen assurance
NIST SP 800-63A-4	IAL1 to IAL3, injection and presentation attack requirements	Where identity, rather than personhood, is required
ISO/IEC 27001:2022	A.5.16, A.5.34	Identity management; privacy and protection of personal information

Practitioner checklist

Write down whether each journey needs identity, an attribute, personhood or none of these.
Require credential limits and unlinkable pseudonymity from any PHC scheme you accept.
Complete a data protection impact assessment before accepting a biometric scheme.
Store only the per-service pseudonym and result; never store biometric data or raw proofs.
Offer at least two schemes plus a non-credential fallback.
Feed personhood results into risk scoring rather than using them as a sole gate.
Monitor for credential resale: one pseudonym behind many devices, locations or agents.
For agents, combine personhood with agent authentication and delegation evidence.
Track abuse reduction against drop-off and appeals, and review quarterly.

Personhood Credentials Guide: Proving a Human Is Behind an Account or Agent