If the AI agent only holds one share of the key, can it complete a transaction on its own?
No — that's precisely the core purpose of this design. Completing a transaction requires enough shares to jointly participate in a computation. If the AI agent holds only one share, then whether its own judgment goes wrong or it's tricked by something external into doing something it shouldn't, it can't sign a valid transaction with just that one share alone — like having only half the digits of a safe combination; that half alone can't open anything.
This is also why this architecture is considered safer than "handing the complete key to the AI": in the traditional approach, once the AI gets fooled, the consequence is total loss; in the share-based approach, the consequence of the AI getting fooled is, at worst, that its one share gets used in an attempt — but since the other shares can't be gathered, the attack itself simply can't happen.
"Always Ask" sounds the safest — should I always pick that mode and avoid Autonomous?
Not necessarily — it depends on your actual use case. If the AI agent is only occasionally completing a single transaction for you (booking one flight, say), the number of approvals under Always Ask won't be much of a burden, and that mode is genuinely more reassuring. But if you have the AI agent handling a task requiring several steps in a row (managing several small subscription payments at once, or making frequent small adjustments to a portfolio), Always Ask might turn into constantly watching your phone for approvals — in that case, Autonomous mode paired with a spending limit you've set yourself and can genuinely tolerate might actually be the more practical choice.
The key judgment isn't "which mode sounds safer" — it's "if an unwanted transaction really did happen under Autonomous mode, what's the maximum loss, and can I accept that." Setting the limit within a range where "even if something really does go wrong, it won't be devastating" is usually a more balanced approach than chasing absolute zero risk.
How is passkey approval different from typing a password like before, and why do these products all switch to it?
A traditional password is a fixed string of characters you have to remember, and one that can be shoulder-surfed, keylogged, or leaked from one site and then tried against another — it's fundamentally "something you know," and anyone else who knows that string can impersonate you. A passkey works differently: it's bound to your physical device, unlocking a piece of encrypted information stored on that device through a fingerprint or face scan — "something you inherently are." That piece of information itself is never typed, never seen, and never transmitted over the network for the other party to compare against; instead, the device verifies your identity locally, then cryptographically generates a proof corresponding to that specific approval.
This is also why product descriptions commonly emphasize that "every passkey approval is scoped to a single action and expires after use" — because even if someone could observe the exact moment you approve something, what they'd get isn't a password that can be copied or replayed elsewhere; it's a verification result tied to that one transaction on that one device, with no way to move it somewhere else and reuse it. That's a structural improvement over traditional passwords when it comes to preventing "a leaked credential getting abused everywhere."
If I lose or someone steals the phone I use to approve transactions, will the money in my AI agent wallet just get taken?
No, it won't be taken directly — this is exactly where the share-based architecture proves its value in an unexpected situation. Your phone only holds one share of the complete key. Whoever finds or steals your phone, even if they successfully unlock it, only gets that one share — they can't gather the other shares (the one held by the AI agent system, the one held by the server) to complete a signature on their own. This means simply losing your phone isn't, by itself, enough for an attacker to take your funds.
That doesn't mean you can just do nothing, though. Most products like this offer an "instantly revoke access" function — the moment you realize your phone is lost, you should use another channel (like logging into a web account) to revoke the validity of the share held by that device as soon as possible. This action typically causes the system to generate a fresh share for your new device, and even if the old device still physically holds its share, that share has already become useless. This is also why it's worth confirming where this "instant revoke" function is and how to use it before you start actively using the product — not scrambling to find it for the first time on the day you actually lose your phone.
"Book my flight," "swap this money into a stablecoin" — when you say something like this to an AI agent, what it's about to do is complete a real financial transaction. That sounds a little unsettling: how can a program built out of generated text be trusted to spend your money? The answer isn't "just trust it as much as possible" — it's an architecture deliberately designed so it never gets the complete key in the first place.
Think of your wallet as a safe, and the traditional approach as having one complete key — whether that's a seed phrase written on paper, a private key stored on a device, or a password memorized in your head. Whoever holds that complete key can open the safe and take whatever's inside. If you want an AI agent to pay on your behalf, the most intuitive but also most dangerous approach is handing that complete key directly to it — meaning that if the agent's judgment goes wrong, or it's tricked into doing something it shouldn't, it's holding a key that can take everything in one go.
AI agent payment products that have recently emerged commonly use a technology called MPC (multi-party computation) threshold signature, and the logic is completely different. The moment this "key" is created, it's split into several "shares" distributed across different devices or systems — your phone gets one, the system running the AI agent gets another, and the service provider's server might get one too. The key point is that the complete key formed by putting all these shares together never actually gets assembled anywhere, at any point — it's not "make one complete key first, then split it up"; the complete key never existed in the first place. Completing a transaction requires a set number of shares to jointly participate in a computation — meaning even if the AI agent's share is stolen or hijacked, the attacker only gets one small piece of the puzzle, not enough to open the safe on its own.
Take a recently launched AI payment product as an example — the actual flow works like this: you tell the AI agent in natural language, "swap this amount of dollars into a stablecoin," the agent prepares the transaction details, and then a confirmation request pops up. You approve it with your phone's passkey (usually a fingerprint or face scan), and only at that point does the threshold-signing computation with enough shares actually kick in, and only then does the money genuinely start moving. There are two layers of protection throughout this process: the first is that the key itself is split into shares, with no single party able to act alone; the second is that every approval corresponds to exactly one transaction and expires once used, so even if someone intercepts a record of that approval, they can't reuse it or expand it into broader access.
Most products like this offer two modes to choose from. The first is "Always Ask," meaning every transaction, regardless of size, requires your personal approval — the most conservative, most reassuring approach, at the cost of needing to approve multiple times if the AI agent is completing a task with several steps in a row. The second is "Autonomous" mode, where you set a spending limit up front, and within that range, the AI agent can complete transactions on its own without waiting for your approval each time — smoother experience, at the cost of needing to think carefully in advance about what that limit should actually be. Set it too loose, and you've effectively canceled the approval gate; set it too conservative, and autonomous mode's convenience never really kicks in.
Next time you come across a product claiming to "let AI pay for you," there's a simple but genuinely useful question to ask: does the complete key or password ever get handed over to the AI, fully assembled, at any point in time? If the answer is yes, this product uses an older, more concentrated-risk model — if the AI's judgment goes wrong, the consequence could be losing everything. If the answer is "the key was split into shares from the start, and the AI only ever holds one of them," this product uses an architecture the industry currently considers safer. You don't need to understand any technical detail to ask this question — asking it clearly tells you how much trust you're actually handing to a text-generating program, rather than simply being persuaded by the word "secure."