Spending limits, payee confirmation, and payment mandates: how CAI keeps agent payments safe

Spending limits, payee confirmation, and the mandate model: how CAI keeps agent payments safe

When an AI agent has access to your wallet, the question is who decides what the agent can spend and where. A wallet an agent can drain in one mistaken API call is a liability, not a product.

CAI uses three layers of authorization: automatic spending limits, human-in-the-loop confirmation for new payees, and payment mandates for trusted merchants. Each layer is independent, and each can be bypassed only by explicit user action in a higher layer.

Layer one: the automatic spending limit.

Every agent-initiated payment through CAI carries a product-level daily cap. Currently set at $200 USD per day per account, this limit applies to all custodial transfers triggered by an agent API call. The limit resets on a rolling daily cycle. It applies regardless of whether the payment reaches the recipient through a custodial transfer, an x402 payment, or a hosted action flow.

The $200 cap is not configurable through the API. It lives at the platform level so a compromised API key or a buggy agent loop cannot drain a wallet in minutes. Users who need higher limits can adjust them in the Dashboard at cai.com/app.

Layer two: new-recipient confirmation.

When an agent initiates a payment to a recipient it has never paid before, CAI inserts a confirmation step. The agent calls resolve_transfer_recipient or x402_payment_prepare and receives a response that requires user confirmation before execution proceeds.

CAI delivers this confirmation as a hosted action URL. The user opens the URL in a browser, sees the proposed transaction details (recipient, amount, token, chain), and confirms or rejects. The agent cannot proceed without that confirmation hash.

This confirmation requirement applies to every first payment to a new recipient. Once a recipient has been paid successfully, the same recipient may not trigger another confirmation for subsequent payments (the system remembers the payee by its resolved address). Changing the recipient address or sending to a different chain with the same alias does require a fresh confirmation.

For the x402 flow, the sequence works like this. An agent receives an HTTP 402 from a paid API endpoint and calls x402_payment_prepare with the resource URL and the seller's payment terms. The prepare response includes a requires_user_confirm flag. When it is true, the agent must stop and wait for the user to confirm through the hosted action URL before calling x402_payment_execute.

Layer three: payment mandates.

Payment mandates are the exception to layers one and two. A user can create a mandate that authorizes an agent to spend up to a defined amount at a specific merchant without per-payment confirmation.

Creating a mandate requires the user to specify the merchant domain, a maximum amount per payment, a daily cap, and an expiration window. The user approves the mandate through the Dashboard or a hosted action URL. Once the mandate is active, the agent can make x402 payments within those limits without user confirmation for each one.

The mandate is a CAI-native implementation, not a full W3C AP2 credential. It is marked as partial_live in the capabilities matrix. It works within CAI's custodial system and does not interoperate with external AP2 wallets yet.

How these layers work together.

Layer one (the auto-limit) always applies, even when a mandate is active. Layer two (new-recipient confirmation) applies unless a mandate covers the merchant. Layer three (mandate) is the only way to skip per-payment confirmation, and even then the daily cap from layer one still stands.

A compromised agent with a valid API key cannot spend more than $200 in a day. It cannot send funds to a new recipient without user confirmation. If the user has set up a mandate for a trusted SaaS service, the agent can authorize payments there within the mandate's limits, but the $200 daily aggregate still applies.

So a user can give an agent meaningful spending authority without giving it unrestricted wallet access.

For developers integrating CAI into their agent or SaaS product, these limits affect how you design the payment flow. An agent that expects to make large or repeated payments needs to handle the confirmation step gracefully. A SaaS product accepting agent payments through x402 should expect that some payments will require the user to confirm in a hosted action page, which adds a round trip to the checkout flow.

The vault adds another safety boundary. Site credentials and platform API keys stored in the vault are encrypted and require explicit vault tool calls to retrieve. An agent with a CAI API key can list available vault entries and manage them, but it cannot read decrypted credentials through the API. The vault operates independently of the payment system, so a compromise in the payment flow does not expose stored credentials.

Documentation for the spending limit and confirmation endpoints is in the CAI skill.md contract at cai.com/skill.md, and the capability matrix at cai.com/capabilities.html shows the current status of each feature. Payment mandates are marked as partial_live in that matrix because the implementation is CAI-native and has not completed full AP2 credential interop testing.

If you hit a limit or a confirmation requirement in your integration, that is the system working as designed. CAI has published the full skill contract and capability matrix so developers can model their payment flows around these guardrails rather than discovering them at runtime.

Bug reports about the payment flow are replied to within 24 hours. Every comment on this article gets read.