# Limits

Stated at full strength, because an agent that knows the ceiling stops climbing.

## The first sign-in is a human act

By default no tool enrols a passkey: a person creates one in their own browser, on a site they
are already signed in to, and the agent path serves `navigator.credentials.get` only. A grant
that holds the `enrol` scope may also answer `create` — but only on a page where a human has
already signed in, because the service holds nothing that could get a browser past a login.

There is no fallback credential, no password, no TOTP seed, no backup code and no mailbox. If a
site is not connected and nobody is signed in to it, an agent cannot get into it, and no amount
of retrying changes that.

## Roughly half of "passkey support" is not passkey sign-in

A large share of sites that advertise passkeys accept them only as a **second factor**, after a
password. A passwords-never product cannot serve those accounts at all. The connector notes say so
where it is known.

## Unattended sign-in is not solved

Every signature this service has produced for a real relying party required a human tap. That is
the honest configuration: the `UP`/`UV` flags are a signed factual claim, and the choice is
between gating each signature on a real approval or reporting the flags truthfully as `0` and
accepting what breaks. There is no third option in which the flags are true because it was
convenient.

## Custody

Keys are envelope-encrypted at rest: a per-credential data key wrapped by one master key,
delivered at start and held in plaintext only inside the process.

The production host **has no TPM**, so that sealing is host-key only — root on the box can recover
the master key offline. What contains that is approval gating, rate limits, an append-only audit
log and revocation, not the cryptography. This deployment is not hardware-sealed and is never
described as such. An HSM is the upgrade path and swaps exactly two functions.

## One relying party is properly proven

The first real end-to-end sign-in was against Google, with a browser holding no Google session,
using a key that has never existed outside the service. That is one site and one credential.
Behaviour on any other relying party is expected, not proven.

## The remote server has no browser

It signs bytes. It cannot click anything, cannot see your page, and cannot tell you whether you
have a session. An agent with no browser tooling can inspect and sign, but cannot complete a
sign-in — and the correct answer in that case is to say so, not to improvise.