ReferenceFactors · v1.0

Active3 GA · 1 in beta

Four factors. One proof.

Each factor proves a different kind of human. Compose any subset — the verifier still learns one bit. The art is picking the right primitives for the threat you're actually defending against.

§ 01 · The factors

Built to compose.

Three are generally available; one is in beta. New factors slot in without re-issuing credentials — that's the whole reason we built the proof envelope this way.

F · 01

FIDO2 / Passkey

"What this device can sign for."

What it proves

Possession of a private key bound to a hardware-backed credential. Phishing-resistant by construction; the browser refuses to sign for a domain that isn't asking.

How it works

Standard WebAuthn / FIDO2 ceremony. AuthenSee derives a commitment from the assertion and feeds it into the proof circuit instead of speaking the assertion directly to the verifier.

When to compose

Always. This is the workhorse factor — fast (≈40ms), supported on every modern device, and the strongest thing we can ask of the OS.

Defends PhisherCred stufferMITMProfile linker

F · 02

Memory factor

"What this person remembers."

What it proves

Recognition of a private symbol set the user enrolled with. Resistant to synthesis: a generative model has no signal for an idiosyncratic memory tile.

How it works

The user enrolls a small set of symbols; at auth time, those are presented mixed with decoys and the user picks. The pick is committed to and proven correct — the symbols themselves never leave the device.

When to compose

Anywhere a deepfake is in the threat model — sign-up, account recovery, high-stakes actions. Cheap to add (≈90ms), and the only factor in our stack that resists synthetic media outright.

Defends DeepfakeSybil farmCred stufferMITM

F · 03

On-device liveness

"That a human is on the other end, right now."

What it proves

A short presence challenge — a passive head movement, a micro-gesture — passed an on-device classifier. The classifier output is committed to; the camera frames never leave the device.

How it works

A lightweight Core ML / TFLite model evaluates the challenge locally and emits a pass/fail. AuthenSee feeds the pass bit into the proof circuit — biometric templates and frames are never persisted or transmitted.

When to compose

Sybil-resistant signups, anti-bot gates, and any flow where you want a "human is here right now" signal that doesn't require a face on file.

Defends Sybil farmBot replayHonest-but-curious

F · 04

Hardware token

"What only this physical key can sign."

What it proves

Possession of a discrete external device — YubiKey, Titan, Solokey, Nitrokey. The strongest single factor we support, with the lowest deployability ceiling.

How it works

Standard CTAP2 over USB / NFC. AuthenSee treats the token's signature exactly like a passkey commitment — slot it into the same circuit, no special-casing needed.

When to compose

Privileged admin access, treasury operations, regulated workflows, or anywhere your users are okay carrying a key. Optional by design.

Defends PhisherCred stufferEndpoint compromise (raises bar)

§ 02 · Composition recipes

Picked the wrong combo? No re-onboard.

Here are the four shapes we see most. None are special-cased in the SDK — they're just what to ask for on the compose() call.

R · 01

Returning user signin

Fast, frictionless, phishing-resistant. The default for everything that isn't a money or admin action.

KPasskey + LLiveness → ZK proof

R · 02

Account creation (anti-sybil)

Higher cost per fake account without making real signup painful. Memory is cheap to enroll once and pays back forever.

KPasskey + MMemory + LLiveness → ZK proof

R · 03

High-stakes step-up

Banking transfers, password resets, treasury moves. Same SDK, same proof envelope — just request more factors at the moment of risk.

KPasskey + MMemory + HHardware → ZK proof

R · 04

Anonymous engagement

Comments, ratings, polls. Prove a unique human is here without ever issuing a stable identifier across sessions.

MMemory + LLiveness → ZK proof

§ 03 · On the bench

✦ The fifth factor

"Something we haven't named yet."

The proof envelope is factor-agnostic on purpose. Spatial-presence, behavioral cadence, social-graph attestation — when one of these matures into a clean primitive, it slots in without breaking your existing integration. Watch the changelog.

✦ Public beta · April 2026

Pick your factors. Compose your proof.

Every factor described here is in the SDK today. Get an API key and you're three commands from a working compose() call.

Get an API key → Read the docs