Trust

The enrollment limitation

This page exists because it is the single most important limitation of the product, and hiding it would make everything else untrustworthy.

The limitation

A Brainprint is created from behavior observed in a session that your system said belonged to a particular person. GrayPass verifies continuity with whoever enrolled. It does not verify that the enrollee was the rightful owner of the account.

If an attacker controls the account at enrollment time, GrayPass will faithfully prove that the attacker is still the one in control. That is a correct answer to the question we ask, and the wrong answer to the question "is this the legitimate customer".

How the product reports it

Every subject carries an anchor describing what evidence backed enrollment:

Anchor	Meaning	Reported limitation
`none`	No claim about the enrollee	`limitation.enrollment_unanchored`
`customer_session`	Your authenticated session (default)	`limitation.enrollment_unanchored`
`idp`	Your identity provider asserted the identity; an evidence reference is required	GrayPass does not verify the assertion
`passkey`	A registered passkey was used at enrollment; an evidence reference is required	GrayPass does not verify the ceremony
`verified_identity`	You ran an identity-verification step; an evidence reference is required	GrayPass does not verify the provider result

The anchor appears on the subject, on the enrollment record, and in the Assurance Profile limitations. The identity_anchor_validity claim is reported as unsupported because GrayPass does not verify anchors itself: the anchor records what you told us, and we repeat it back without embellishment.

How to reduce the exposure

Anchor enrollment to your strongest signal. Enroll right after a passkey registration, an identity-verification step, or a fresh IdP assertion, and declare that anchor.
Enroll early. Behavior collected during onboarding, before the account holds value, is a smaller target.
Treat re-enrollment as a privileged operation. The subject's recovery_policy is enforced before a new enrollment session:
- re_enroll_with_anchor (default): a new Brainprint requires the same anchor strength as the original.
- re_enroll_any: any authenticated session may re-enroll. Convenient, and strictly weaker.
- manual_review: re-enrollment requires a human decision in the console.
Watch your own re-enrollment rate. A spike is an attack signal that belongs in your fraud system, and it is emitted as enrollment.completed events.

Recovery

People get new laptops, break their hands, and change how they type. The honest answer is that recovery is an authenticated-re-enrollment problem, not a biometric one:

Revoking a Brainprint is immediate and irreversible (POST /api/v1/subjects/{id}/revoke). All outstanding proofs are revoked with it.
A revoked subject cannot authorize anything: decisions return deny with decision.subject_revoked.
Re-enrollment follows the recovery policy above. Until it completes, the subject's assurance reports insufficient_evidence, which the policy routes to a challenge or a hold. Nothing silently falls open.

What we will not say

We will not claim that a Brainprint proves identity, that it cannot be stolen, or that enrollment is self-verifying. If you need proof of who a person is, that is an identity-verification purchase, and GrayPass is not it.

Generated from the API contract in contracts/ and the source in docs/. The build fails if this page disagrees with the running API.