If I still want to use a password instead of a fingerprint or face scan, is the risk really that different?
The difference is substantial, and it's not just a matter of "one extra layer of protection" — it's structural. A password is "something you know" — as long as anyone else also knows that string (whether shoulder-surfed, keylogged, or leaked from another site and tried here), they can impersonate you. A passkey uses "a private key your device holds" combined with "something you inherently are," and the private key never leaves the device from start to finish, nor is it transmitted anywhere in any form for comparison — meaning there's no single "thing" that can simply be stolen and used to impersonate you elsewhere.
For ordinary web browsing, the risk of using a password might still fall within what most people find acceptable. But for a scenario that approves actual financial transactions, the consequence of a leaked password translates directly into a financial loss — there's no buffer between the two. This is also why most AI agent payment products simply don't offer a password option at all: rather than letting users judge their own risk tolerance, it's more direct to exclude the higher-risk option entirely.
Passkeys sound like they depend entirely on my device — if the device itself gets hacked, does that mean there's no protection left at all?
That's a reasonable concern, but passkey design already accounts for this layer. Device compromise is indeed a real risk path, but a passkey's private key is typically stored in a specially isolated secure area on the device (naming differs by platform, but the concept is similar). This area is designed so that even if the rest of the operating system gets compromised, the private key inside is very hard to read directly — it requires bypassing additional hardware-level protection. Also, every approval still has to pass through biometric verification — even if the device is remotely controlled, an attacker would still find it very difficult to also forge your fingerprint or face scan without your knowledge.
More fundamentally, what passkeys are meant to solve was never "make the device completely uncompromisable" — it's "even if an attacker gets the device or witnesses the exact moment you approve something, they still can't get a credential they can carry off and reuse elsewhere." The device's own security (system updates, avoiding installing software from unknown sources) is still something the user needs to take responsibility for. Passkeys handle the layer of "can a credential get stolen and abused elsewhere" — the two are complementary, not substitutes for each other.
Every AI agent payment product asks me to set up a passkey again from scratch — doesn't that end up being more of a hassle?
In practice, that feeling is real, because a passkey is typically bound to the combination of "your device" and "a specific service," so in theory each new service needs its own separate setup process. But this "hassle" is actually a deliberate design choice: if a single passkey worked universally across every service, that would just recreate the old model of "one credential controls many places," and if that shared credential ever had a problem, the fallout would be far larger than a single service.
What helps mitigate this hassle in practice is making good use of synced passkeys — through a service like iCloud Keychain or Google Password Manager, setup you complete on one device can automatically sync to your own other devices, without needing to redo the full process on each one. You still need to set up separately across different services, but each individual setup usually only takes a few seconds (device prompt, fingerprint or face confirmation) — actually requiring less effort than the traditional password demand of "think up a sufficiently complex new password, memorize it, and don't reuse it across other accounts."
If my passkey stops working for some reason (say, I didn't transfer it correctly when switching phones), will I be completely locked out with no way to get my funds back?
No — most services designing passkey mechanisms retain at least one backup identity-verification channel, so a user doesn't lose account access entirely because of a single device problem. Common approaches include: allowing multiple passkeys to be registered at signup (like your phone plus a backup hardware security key), so if one fails you still have another to use; or providing a separate account recovery process, typically combined with other verification methods (email confirmation, human customer-support review) to re-bind a new passkey.
What's worth proactively preparing yourself, in practice, is confirming what this recovery process actually looks like and how long it takes before you start actively using any AI payment product that requires a passkey — not searching "what do I do" for the first time on the day you actually run into a device problem. This is the same kind of preparation as the "instantly revoke access" function mentioned earlier: something you're unlikely to need, but will be very glad you looked into beforehand if you ever do. The security improvement a passkey brings doesn't mean you don't need to prepare for the unexpected at all.
If you've tried any "let AI pay for you" product recently, you'll notice a common thread: the way you approve a transaction is almost always a fingerprint, a face scan, or your device's own unlock mechanism — almost none of them ask you to type a password. This isn't a coincidence, and it's not just a "trendier" interface choice — there's a specific technical reason behind it, tied to how the AI agent scenario particularly amplifies weaknesses passwords already had.
A password is fundamentally a string of characters you have to remember, type, and send off to be compared against. This design had a structural problem from the start: anyone who knows that string can impersonate you, and that string has opportunities to be intercepted or leaked during both transmission and storage. Phishing sites exploit exactly this weakness — building a fake site that looks identical, tricking you into typing your password directly into it, and it doesn't matter how convincing the site looks, because the password itself has no mechanism to tell whether it's being typed into the real site or a fake one. These weaknesses already existed in everyday human use of web services — the AI agent scenario doesn't create a new weakness, it just puts an existing one on a higher-stakes stage.
When what's being approved is a financial transaction, and approval might need to happen frequently (say, an AI agent completing a task with several steps in a row), a password's weaknesses get amplified into a few concrete problems. First, if the approval mechanism is typing a password, that password has to be stored somewhere for the system to compare against — and that storage location itself becomes a new attack target. Second, once a password leaks, what leaked is a static, reusable credential — an attacker who gets it can try logging in with it endlessly, until the account gets locked or the password gets changed. Third, and closest to the AI agent scenario specifically: if the AI agent's own judgment gets tricked by some attack technique into executing a transaction it shouldn't, a traditional password mechanism has no way to distinguish "this was approved by the actual user" from "this is a forged approval request generated by a hijacked process," because password comparison itself is just mechanical string matching — it doesn't care where the request came from.
A passkey replaces the password with a public-private key pair. The private key is locked inside your device from the moment it's created, never leaves, and never needs to be transmitted anywhere for comparison; the service side only ever stores the public key, and even if that public key leaks, it can't be used to forge a login, because the public key can't be mathematically reversed to derive the private key. Every approval happens when your device confirms it's really you via fingerprint or face scan, then signs this specific request with the private key, sending out only the signature result — which typically corresponds only to this one, single transaction, expires after use, and can't be reused even if intercepted. More critically, a passkey binds to the actual domain of the site making the request — even if an attacker builds a fake website that looks identical, your device won't use the passkey on that fake domain. This completely closes the fundamental problem where a password gets dutifully typed in regardless of whether the site is real or fake.
If you're using or considering using any AI agent product that requires approval for fund operations, the existence of passkey mechanisms means the risk you carry with every approval is on a different level than the risk you carried logging into a website with a password: even if someone could observe the exact moment you approve something, what they'd get isn't a credential that can be copied and reused — it's a verification result tied to that one transaction on that one device. This is also why you shouldn't be surprised or resistant when "this AI payment product asks me to approve with a fingerprint" — it isn't an extra hassle step; it's a direct response, built into these products' design, to the reality that financial transactions need a higher level of protection than an ordinary login. Choosing a passkey over a password is, to some degree, also a signal of whether the team behind a product takes fund security seriously.