Proof of Personhood and Agent Identity: Opposite Questions, and Ours Does Not Answer Either One Alone

Personhood asks whether there is exactly one human here. Agent identity presupposes there is none, and asks who is accountable instead. They are not adjacent problems, and a system that answers one says nothing about the other.

They are not two flavours of the same thing

Proof of personhood asks whether there is exactly one human behind this. Its enemy is duplication: the same person appearing as many participants.

Agent identity presupposes there is no human here at all, and asks who is accountable for something that acts on its own.

One is about uniqueness. The other is about attribution. A system can be excellent at one and say nothing about the other, and conflating them is how "verified" starts meaning whatever the reader hopes.

Where they actually meet

At the operator. An agent's accountability chain has to terminate in somebody who can be held responsible, and that somebody is a person or a company.

So personhood is upstream of agent identity rather than parallel to it. If you cannot establish that the party behind an agent is a distinct, real entity, everything downstream inherits that weakness however good the cryptography is.

And our chain establishes no uniqueness at all

Measured, at three points that compose into one conclusion.

Operator registration is public. The route has no authentication step and returns a bearer token on success. Anybody can create an operator.

There is no unique constraint on the identity reference, nor on the account field beside it. The same reference can back any number of operator records.

And each registration receives its own tenant identifier by default, so the accounts are isolated from one another rather than recognised as related.

The same migration set applies uniqueness in three other places, on an identifier, on an API key hash and on a deduplication key. Uniqueness is a tool this codebase reaches for deliberately. It is not reached for here.

What a relying party may and may not infer

May infer: somebody presented a reference to a verification performed elsewhere, and named an assurance level.

May not infer: that this is a distinct person, that they hold only this account, or that anybody confirmed the reference. Confirmation is advisory by default and the verdict is not carried in the credential.

Put plainly: our credentials attribute, and they do not count.

The practical consequence today, sized honestly

Free-tier allowances are per tenant, and tenants are free and unlimited, so the allowance is bounded per account rather than per person.

It becomes real the moment either billing or a relying party exists, which is why it is filed now rather than after.

What is real, because absences alone would misdescribe us

The separation of duties holds. The identity check happens on another surface, this one ingests the result, and our credential says who attested rather than asserting the fact.

An operator reference is required to create an agent at all, and the two failure modes have distinct messages.

And the credential names its issuer, so a relying party who does not trust that issuer can reject everything downstream in one decision rather than case by case.

What personhood would add, and what it would cost

It would add a denominator. "One operator" would mean something countable, and sybil-shaped attacks on any reputation or allowance system would stop being free.

And it would cost privacy in the ordinary way: uniqueness is established by linking, and linking is what selective disclosure exists to avoid. A system that proves you are unique has, by construction, something that recognises you again.

We are not going to pretend that tension resolves cleanly. It is the central hard problem of the field, and nothing on this surface addresses it.