how should passkeys work for ai agents?
Passwords can be copied and replayed. Passkeys provide a better boundary because an agent can receive a signed WebAuthn assertion without receiving the private key that created it.
a passkey is not a password replacement string
The website sends a challenge for a relying party. The authenticator verifies the relying party, checks user presence and signs the challenge. The resulting assertion proves possession of the private key without revealing it.
An agent integration should preserve this ceremony instead of attempting to export or emulate the private key.
the browser and phone each have a job
The browser supplies the website origin, relying-party identifier and challenge. The phone selects the matching passkey, performs Face ID or device authentication and signs the exact challenge. The assertion returns to the browser to finish login.
Decoy keeps the private key in the phone’s secure credential storage. Every passkey sign-in requires the phone, even when the agent has standing access to other account data.
passkeys reduce one risk but not every risk
The agent cannot copy the private key, but a user can still approve a malicious or mistaken login. The approval screen must clearly name the connected agent and website. The browser integration must also bind the challenge to the real page origin.
After login, the agent may receive an authenticated session. The browser or runtime must still control what actions that session can perform.
common questions
does the AI agent ever receive the passkey private key?
No. The phone signs the challenge and returns only the WebAuthn assertion.
does a standing grant silently approve passkeys?
No. Decoy requires the phone for every passkey assertion.
does a passkey authorize purchases or account changes?
No. It authenticates the session. Downstream action authorization remains the responsibility of the agent runtime or website.