KERNEL announced agent payments for browser agents on November 10, 2026, with vaults that let a browser session use a payment method without the card number reaching our app or the model. Does that keep our agent from overspending, and what checks are still ours to build?

What should I check, step by step?

1. Give each user or task its own vault. Attaching a vault grants the browser access to all its items, including ones added later, and the attachment can't change, so a shared vault is a shared wallet.

2. Create the card item only on the final checkout page, once your application has verified the merchant, items, amount and currency from the merchant's order or cart data, not from what the agent read on the page.
3. Keep approval links (spend_approval, push_approval, enrollment) in your own user-facing screens. KERNEL's docs say not to send action URLs or provider authorization material to the agent.
4. Have your trusted controller, not the agent, call fill with the exact current page URL. For Link and Shop Pay, fill only works on the authorized checkout origin (host and port, no other subdomains) and returns 403 destination_denied elsewhere.
5. Treat fill's completed status as fields written, nothing more. Submit once, then confirm the order in the merchant's records.
6. Never retry a failed, timed-out or unknown payment automatically, and don't create a replacement item to retry. KERNEL's docs say to inspect outcomes, item events and the merchant's order state first; a card in recovery_required blocks new authorization and has no reset.
7. Don't record or stream the browser while payment fields are filled. KERNEL warns that recordings and other observation surfaces may include filled values.
8. Keep your own per-agent budget and approval record, because the vault doesn't enforce one for card payments.

How do KERNEL vaults keep card numbers out of a browser AI agent's context?

KERNEL runs the browser and its network path. A vault groups payment items; when a vault is attached to a browser session, your controller can call fill with an item reference, the browser and field selectors, and KERNEL writes the stored values and returns per-field outcomes, never the values. With Agentcard, the agent enters non-sensitive aliases; KERNEL recognizes the processor request leaving the browser (Stripe, Shopify, Recurly and Razorpay formats are listed), holds it while the user approves, lets Agentcard execute it and replays the response. KERNEL's announcement says the merchant doesn't need to integrate with KERNEL.

• That keeps card numbers out of your application code, prompts, logs and traces. It doesn't make the page itself safe: KERNEL's fill docs say page scripts, extensions, devtools and an agent with unrestricted browser or CDP access may read the filled values afterwards.

What limits and approvals do KERNEL's payment sources (card, Link, Shop Pay, Agentcard) enforce?

Pay with card (the user's own card): your card item names the merchant, amount and currency and is bound to one card. Eligible cards get a network token with a one-time security code, and fill is restricted to the configured merchant's top-level origin. Visa purchases need the cardholder to complete a spend approval; supported Mastercard purchases have no hosted purchase approval. KERNEL says there's no general standing approval or spending-limit setting, and on the fallback path for cards without network tokens the recorded amount and merchant don't restrict outgoing payment requests.

• Link by Stripe: the user approves each purchase in Link. Amounts run from 1 to 500,000 minor units (5,000 USD) for a Link Pay Token on Stripe checkouts with Link's agent tools, and at most 50,000 (500 USD) for a single-use virtual card everywhere else. The request needs a written context of at least 100 characters, which the user sees. Card creation is live-only. If the user declines or the request expires, delete the card item and make a new one.
• Shop Pay: USD only, the shopper approves each purchase in Shop, fill must happen within an hour of the card becoming ready, and you report the outcome with confirm_transaction. Agentcard: each checkout is approved separately and a card item can be reused for later purchases, with one pending authorization at a time; Agentcard has no merchant URL or domain allowlist, and the merchant name is what the approval screen shows, not an enforced origin.

What do you still have to check yourself when a browser AI agent pays through KERNEL?

Deciding whether the purchase should happen. Every KERNEL payment guide puts verification of merchant, items, amount and currency on your application before authorization. A prompt-injected agent that reaches a convincing checkout can still propose a purchase; the vault only controls how the card gets there.

• A budget. Apart from the payment source's own approvals and limits, nothing in the vault caps what one agent or task spends across purchases. Keep a per-agent or per-task total in your system and check it before you create the card item.
• Proof of payment. A completed fill, an approval or a ready card isn't proof that money moved. Reconcile with the merchant's order record, and keep the approval and order together so a second charge can be matched to a second approval.