Passkey approval for AI-agent mandates
Passkeys can bind a person to an exact mandate on a trusted surface. They do not identify the agent or replace policy enforcement, execution controls, or payment rules.
Identity, product-security, and platform teams
Key takeaways
- Bind the WebAuthn ceremony to the immutable mandate shown on a trusted origin.
- Describe passkeys accurately: local verification may use a biometric or PIN, but neither biometric data nor private keys leave the device.
- Keep later policy evaluation and single-use execution control separate from approval.
What a passkey approval proves
A WebAuthn ceremony can prove that a registered credential performed user verification for a challenge issued by the relying party. In a delegated-action flow, the challenge and resulting evidence must be bound to the exact mandate identity and content the user was shown.
This makes passkeys useful for the approval step: the private key remains protected by the user's authenticator, while the service verifies the signed response with stored public-credential data. Depending on the device, local user verification may use a biometric, PIN, or another device mechanism. The biometric and private key are not sent to the service.
Use a trusted approval surface outside the agent
The agent should not control the text or fields that define its own authority. A hosted approval surface should load the immutable mandate from the authorization service, show the important boundaries in plain language, and begin the WebAuthn ceremony from the expected origin.
The platform remains responsible for delivering the approval link to the correct authenticated user. The approval service must prevent one organization from using another organization's subject, mandate, origin, or credential.
- Show action type, material attributes, value limit, validity window, and single-use behavior.
- Do not hide enforceable fields behind generic language such as “allow this agent to book.”
- Bind the ceremony to the mandate identity, relying-party origin, subject reference, and current lifecycle state.
What passkeys do not solve
A valid passkey response does not prove that a later action fits the approved policy. It does not authenticate the AI model, stop duplicate execution, move money, satisfy every payment-authentication requirement, or decide whether a downstream merchant will accept an action.
Those responsibilities belong to the surrounding architecture: agent and platform identity, deterministic policy evaluation, reservation state, existing booking or payment systems, and the legal or risk controls that apply to the customer's use case.
Design the credential lifecycle, not only registration
Production systems need to handle returning credentials, sign counters and clone warnings where applicable, passkey sync behavior, lost devices, subject changes, and credential removal. Registration and authentication ceremonies need fresh, expiring challenges and one-time server-side session state.
The evidence record should identify the credential and verification result without exposing secrets. It should also distinguish whether approval enrolled a new credential or verified an existing one, because the security context differs.
Review the full approval path
A passkey integration is only as strong as the flow around it. Test origin validation, challenge expiry, replay, cross-tenant access, user-verification requirements, mandate mutation attempts, and concurrent completion. Also review the copy a user sees: the cryptography cannot compensate for an approval screen that obscures the actual bounds.
Use passkeys to bind the user to the mandate—not as shorthand for “biometric authorization” and not as proof that every later action is acceptable.