MoonPay Launches PayBox: Claude and ChatGPT Can Spend Your Money Without Ever Holding Your Wallet

How is PayBox different from earlier AI wallets or trading bots?

Letting AI act on a user's funds historically meant one of two approaches: hand a Private Key or API key directly to a program, giving it complete control over funds, or route control through a third-party custodian, transferring fund control to the platform itself. Both approaches share the same underlying problem — some single party (the developer's program, the custodial platform) ends up holding complete authority to move funds on its own, and once that link is compromised or misused, the funds are directly exposed.

PayBox's design differs by splitting the key via MPC across the device, a single session, MoonPay, and the AI Agent, so no single link can complete a signature alone. This means that even if the AI agent's own judgment is hijacked, or one link is compromised, an attacker only gets an incomplete key fragment — not enough to move funds alone. That's a fundamentally different security assumption from the older model of simply trusting that a program or platform won't misbehave.

What tradeoff do the "Always Ask" and "Autonomous" permission modes reflect?

The two modes essentially hand the choice of "how autonomous should the agent be" back to the user, rather than having the product unilaterally decide one mode fits everyone. "Always Ask" trades away convenience — if the AI is handling a task spanning multiple services, you might need to approve several times — in exchange for every single transaction passing through human confirmation, so in theory no fund movement happens without the user's knowledge. "Autonomous" runs the other way, letting the AI act continuously within a preset limit without stopping for approval each time; the convenience comes at the cost of the user having to think carefully in advance about what that "limit" should actually be — set it too loose, and the approval gate becomes hollow; set it too conservative, and autonomous mode becomes pointless in practice.

Worth noting: regardless of which mode is chosen, changing the permission setting itself always requires a fresh passkey approval, meaning a user isn't locked in by an initial wrong choice. But this also means the security of the whole permission design depends heavily on whether the user judged the initial limit correctly — the product architecture can offer the options and the boundaries, but it can't make that judgment call on the user's behalf.

Does card payment via Visa's agentic commerce protocol protect against the same risk as MPC key-splitting for the wallet?

Not quite the same risk — the two address different asset types within the payment flow. MPC key-splitting for the wallet protects crypto assets, preventing any single link from independently moving on-chain funds. Card payments routed through Visa's agentic commerce protocol protect traditional card numbers instead — ensuring PayBox never sees or stores the raw card number, which closes off a different common fraud path: once a card number leaks, it can be reused elsewhere repeatedly, because a traditional card number is fundamentally a reusable static credential.

Taken together, what PayBox is addressing is the broader problem that an AI Agent, whether dealing in crypto or a traditional payment card, shouldn't directly touch the reusable core credential at all — not just a crypto-specific concern. This echoes the "three common sources of fraud" mentioned in the press release: a stolen credential that works anywhere, a card number that leaks and gets reused, and a single system that can move funds once compromised — PayBox addresses these three paths respectively through non-reusable passkey authorization, card-number concealment, and key-splitting.

With this product now live, what does it actually mean for users or companies evaluating whether to let an agent touch their funds?

The most direct implication is that "should an agent be allowed to touch money" is shifting from a binary choice of "hand over control or don't" into a design question of "what architecture lets an agent move funds without holding control of them." The old concern was that authorizing AI to handle payment flows effectively meant handing fund control to some single link — whether that link was the program itself or a custodial platform. Architectures like PayBox attempt to demonstrate that an agent's transaction capability and an agent's control over funds can be separated into two distinct things.

For users, the practical judgment call is to ask, when evaluating any similar product, specifically how keys or credentials are split or protected, which party can move funds under what conditions, and what the mechanism is for an authorization to expire — rather than just taking a product's claim of being "secure" at face value. For enterprise users, if this kind of architecture proves reliable, it could gradually shift the risk-assessment basis behind decisions like whether to let an agent handle procurement or subscription payments. But as of now, PayBox has only just launched, and its real-world security still needs to be validated over time and through actual use cases — at this stage it's better treated as an industry signal worth watching, not a settled conclusion for immediate large-scale adoption.