Passkeys for AI and agents
The question comes up a lot: can an AI agent authenticate with a passkey?Not as a user, but passkeys are exactly what keeps agents safe: the agent works on a scoped token, and every sensitive action waits for the human's passkey.
tl;dr
- Agents act on tokens, people approve with passkeys. An agent works under a scoped, short-lived token issued after the user signs in with a passkey.
- Sensitive actions go back to the human. Payments, sharing and account changes trigger a fresh passkey tap through the standardstep-up flow, bound to that specific action.
- No fake "agent passkeys". WebAuthn requires a human gesture, so PasskeyBase never lets software impersonate a passkey holder.
The core constraint
A passkey is "something the user has" plus "something the user is" (the biometric or PIN that releases it). Both legs depend on a human user being present at the authenticator. An agent running on a server has neither. Anything that claims an agent is "logging in with a passkey" is doing one of:
- Holding a long-lived bearer token issued after a human signed in (this is fine; just call it a token, not a passkey).
- Holding a private key in a keystore (this is fine; it's a service credential, not a passkey).
- Lying.
PasskeyBase's agent story is built around honestly working with the constraint: use passkeys to bound the agent's authority, not to pretend the agent is the user.
Step-up verification for autonomous agents
The hard problem with agents isn't authentication; it's authorization boundaries. You want the agent to be able to do small things on the user's behalf (read mail, draft replies, run searches) without paging the human for every keystroke, but you want sensitive actions (send money, share private data, change account settings) to require a fresh, deliberate human approval — and you want that approval to be phishing-resistant and bound to the specific action.
Passkeys are uniquely good at the second part because the assertion is cryptographically bound to (origin, user, challenge) and you can attach an arbitrary context payload to the challenge. The agent host can show "send $250 to Bob? [Face ID]" and the resulting assertion is provably about that action, not something the agent could reuse for a different transfer.
In practice this is the step-up flow: the agent host pauses before the sensitive action, the user confirms with Face ID, Touch ID or a security key, and the agent continues with an approval that cannot be replayed for a different action.
Where this is going
The interesting research direction is agent-attested actions: the agent presents not only a user-issued bearer token but a signed statement of intent ("agent X, running model Y at version Z, intends to do A on behalf of user U"), signed by an attestable agent runtime. PasskeyBase would then bind a user-passkey approval to that statement, not just the action. This makes forensic incident response on agentic systems tractable in a way bearer tokens alone don't.
We're tracking proposals from the FIDO Alliance, the W3C WebAppSec WG, and Anthropic's own work on agent identity. None of it is shippable yet. When it is, PasskeyBase will be among the first to ship support for it — that's the long-run bet behind the company.
What we won't do
- Sell "passkeys for agents" as a current product — the standards aren't there yet, and shipping a proprietary version would just create lock-in around a pattern that the W3C is going to standardize differently.
- Pretend a long-lived API token is a passkey because the user happened to set it up using one. It's a token. Call it a token.