Proof-of-human standards, explained. And what to do about bots today.

The three questions, and who answers them

When something reaches your product, there are three different questions hiding inside "is this a human." They are not the same, and the tools being built answer different ones.

1. Is this a genuine device or client? (Private Access Tokens)

Private Access Tokens let a platform vouch that a request comes from a real device or a real user account, without a puzzle and without handing the site a fingerprint. It is privacy-preserving and frictionless, and it is about the device and the moment, not a portable history of a person. A genuine device can still be driven by automation, and a person moves across many devices.

2. Is this a known, declared automated agent? (Web Bot Auth)

Web Bot Auth uses signed HTTP messages so an AI agent or crawler can cryptographically say who it is. This is genuinely useful, and it solves the agent side of the problem: telling good declared bots apart from anonymous traffic. It does not tell you a continuous human is on the other end. It was never meant to.

3. Is a real, continuous human behind this account? (the open piece)

This is the question that fraud, survey farms, and mass account creation actually turn on, and it is the one no device token or agent signature answers. Answering it needs something that accrues over time and belongs to the person, not a check administered at the door.

Why the door is the wrong place to check

Every test given at the door is a race against the model that will eventually pass it. Puzzles, faces, voices, and gestures all get easier for machines as generation improves. The one thing a model cannot fake after the fact is a consented record of real activity that has been accruing the whole time, because you cannot mint elapsed weeks. That is the shift: from a quiz at the counter to a history, the way a bank checks credit rather than asking you to prove yourself with a riddle.

What a builder can do today

You do not have to wait for the standards to finish. You can read a portable, consented record of a continuous human at the moment it matters, with a call, and let the person revoke it whenever they want.

• Ask claims, not content. Four questions: is this a human, is it continuous, has it deviated, does the person stand behind it. You never receive what the person wrote.
• Let the person own and revoke it. The record belongs to the human, is opened by consent, and is revocable in two clicks. That is what makes it safe to rely on.
• Make it checkable. The record is committed to a public, append-only transparency log and signed with a key anyone can fetch, so "it has been accruing since a start date" is something a third party can verify, not something you take on trust.
• Handle the unknown honestly. A claim that cannot be evidenced returns null, never false. An absent record is not an accusation.

How Pupul fits

Pupul is that record. It answers the four claims over a normal API and over MCP, the person carries it between services, and every claim is checkable against a public transparency log. It is the application-layer answer to question three while the industry standardizes questions one and two. See the argument for why elapsed time is the moat on proof of human, run the check with no signup on the four-claims demo, or read the signed transparency-log checkpoint that makes the history non-backfillable.

Pupul is a proof-of-human signal for the AI era, not a consumer report, and it is owned by the person it describes. This page explains publicly available standards in plain terms; the standards themselves are maintained by their respective bodies.