Sign your agent in.
Never hand it a secret.
Agent Passkey holds the passkeys you enrol and signs on your agent's behalf. The agent gets a session — it never gets a credential, because there is no credential to get.
One consent screen. No API keys to copy, no code to paste.
Every signature this service produces, and why it was allowed.
Set it once. Then stop being the bottleneck.
Enrol a passkey
In your own browser, already signed in to the site, you register a passkey the way you always do. The private key is generated inside the service and never leaves it.
Connect your agent
One command. Your agent opens a consent screen where you pick which accounts it may use and for how long. No key to copy, nothing to paste back.
It just signs in
From then on the agent signs in unattended, inside the scope you set. Every signature is written to an append-only log, and one click revokes the lot.
One command. One screen.
Agent Passkey is a remote MCP server that speaks OAuth 2.1. Your agent discovers the endpoints, registers itself, and opens a browser. You tick the accounts it may use, choose how long, and hold Allow.
There is no API key, because there is nothing to key. Authority lives in a grant you can read and revoke, not in a string you have to keep secret.
$ claude mcp add --transport http agent-passkey https://app.solospace.dev/mcp
Added MCP server agent-passkey.
Opening browser to authenticate…
✓ Connected. 2 accounts · expires in 7 daysWorks with any MCP client that implements the 2025-06-18 authorization spec or later.
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.
An agent cannot enrol
Registering a new passkey requires a human in their own browser, already signed in to the site. The agent path deliberately does not serve create() — only assertions with credentials a person enrolled.
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.
Stop being the thing your agent waits for.
Enrol a passkey, connect an agent, and go and do something else.