A signature, not a secret.
An agent that can sign in as you is an agent that could be holding your credential. This service is built so there is no credential to hold: the passkey’s private key is generated inside it, every signature is scoped to a consent you gave, and the record of what was signed cannot be edited by the service that wrote it.
The limits, stated as plainly as the claims.
The key never leaves
Each passkey is a P-256 key generated inside the service and envelope-encrypted at rest. It is never sent to your agent, never sent to your browser, and never sent to the site. An agent asks for a signature; it does not ask for a key.
Enrolment is a scope, not a default
By default the agent path serves get() only, and a person registers passkeys in their own browser. A grant that holds the enrol scope may answer create() too — 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. Off unless you tick it.
Origin is checked, not asserted
A signature is only produced for an origin sharing a registrable domain with one captured at enrolment. A remote agent can claim any origin it likes; the claim is checked against what a human's browser actually saw.
The log cannot be rewritten
audit_log is append-only in the database itself — a trigger refuses UPDATE, DELETE and TRUNCATE, so not even the application that writes it can go back and change it.
Presence is a claim we take seriously
The UP/UV flags tell a site a human was there. We set them on the strength of a consent you gave, naming the accounts and an expiry — and where you ask for approval per signature, we wait for it. Where you ask for neither, we report UP=0/UV=0 rather than lie.
What this is not
The current deployment seals its master key with the host key, not a TPM — root on that box could recover it offline. What contains that is approval gating, rate limits, the audit log and revocation, not the cryptography. An HSM is the upgrade path and swaps one function.