What are passkeys for AI agents?

What are passkeys for AI agents?

Passkeys are the consumer-friendly version of FIDO2/WebAuthn — public-key credentials that replace passwords with a private key bound to a device. The user proves they hold the key with a local biometric or PIN; the site verifies the signature; nothing transmittable ever crosses the wire. They're a substantial security improvement for humans. They're also the most awkward existing standard to map onto autonomous browser agents, because the entire architecture assumes a single physical user at a single physical device — and an agent is neither.

Why passkeys are hard for agents

Three properties of passkeys that make agentic flows non-trivial:

1. Device binding. A passkey lives on a specific device (a phone, a security key, a synced platform credential). An agent running in a fresh cloud browser doesn't have a stable device the user's passkey is bound to, and provisioning a new credential per session breaks the security model.
2. User presence checks. Most passkey flows require a "user verification" step — a fingerprint, face scan, or device PIN. The agent can't present a fingerprint. This is a feature, not a bug, of the standard.
3. Lack of programmatic enrollment. WebAuthn doesn't have a clean way for a long-lived identity to programmatically enroll a passkey on a new device. Sync ecosystems (iCloud Keychain, Google Password Manager, 1Password) are designed around human accounts.

The honest summary: agents and passkeys are incompatible by design today, and the standard has not yet been extended in a way that resolves this without compromising the security properties that make passkeys worth adopting in the first place.

What works in practice today

Three workarounds, in roughly increasing order of friction:

• The site offers a passkey-or-password fallback. Many do. Configure the account to keep password + 2FA active and let the agent take that path with credential vaulting and the identity's 2FA channels. Pragmatic for most sites.
• Bootstrap a browser profile once. A human enrolls a passkey on the cloud-browser session through the Notte viewer with persist=True. The session cookies persist; the agent reuses them on every subsequent run. Works for sites that issue long-lived sessions after passkey login, which is most consumer accounts. The downside: any periodic re-prompt for the passkey requires a human in the loop again.
• Hardware-keyed cloud browsers. Some emerging platforms run sessions inside microVMs with a virtualized TPM that can hold a passkey scoped to the agent's identity. Still rare, and the security review is harder than for the password+2FA path.

For most production deployments today, the right answer is the first or second option. The third is on the roadmap for the industry, not a shipped pattern.

What changes if Web Bot Auth lands

The medium-term picture is more interesting. Once Web Bot Auth is widely deployed on the receiving side, sites will be able to verify that the agent making a request is a legitimate, provider-issued actor. That changes the calculus on passkeys: a verified agent identity might be granted a different authentication path than an anonymous browser, and "agent has its own credential" stops being a category error.

That's a few years out at production scale, but it's where the standards bodies (FIDO Alliance, IETF) are headed. Treat the current passkey gap as temporary — but real for now.

Common pitfalls

• Assuming passkeys are a replacement for credentials in agent flows. Today they're a blocker; vault + identity + profile is still the production path.
• Trying to programmatically register a passkey for the agent. The flow requires user verification that an agent can't present.
• Skipping the conversation with the user. If your product's customers use passkeys, surface that limitation explicitly during onboarding rather than leaving them to discover the agent can't log in.

Key takeaways

• Passkeys are FIDO2/WebAuthn credentials designed around a human at a device — incompatible by design with autonomous agents today.
• Practical paths are the password + 2FA fallback (where the site offers one) or a browser profile bootstrapped manually with the passkey.
• Hardware-virtualized passkey provisioning for agents is an emerging direction, not a shipped pattern.
• The medium-term resolution depends on Web Bot Auth — verified agent identity changes what authentication paths sites can grant.