What this cannot do: enrolment, second-factor-only sites, unattended sign-in, custody.
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.