My AI agent browses the web and can pay for things. How do I stop a hidden instruction on a web page or in an email from making it buy something or send money?

What should I check, step by step?

1. Treat every web page, email, PDF, review and tool result the agent reads as untrusted input, including hidden text a person can't see. Anthropic red-teamed its Chrome agent against injections hidden in form fields a person can't see, in URL text and in tab titles that only an agent would notice.

2. Give the agent a payment credential of its own (a virtual card, a scoped wallet or a delegated token), never your main card, with a per-purchase cap and a daily cap small enough to lose.
3. Set a merchant allowlist outside the agent. A purchase from a merchant you didn't list is refused, which defeats the common trick of sending the agent to an attacker's checkout page.
4. Require a human approval for anything off the list, above a threshold, or that adds a payee, changes a shipping address or buys gift cards or crypto. Bind the approval to the exact merchant, amount, currency and items, and refuse the payment if any of them changed afterwards.
5. Build the approval screen from the checkout data, not from what the agent says. An injected agent can describe a purchase falsely.
6. Make sure only you can approve. If the agent holds the key that approves, an injection can tell it to approve itself.
7. Split the jobs. Let a research step read the open web without payment tools, and let a separate step with payment tools act only on structured choices (product id, merchant, price) instead of free text it just read.
8. Follow the vendors' own advice: OpenAI recommends logged-out mode when sign-in isn't needed, reviewing confirmation requests carefully, and giving specific tasks instead of broad ones like "take whatever action is needed".

How often do prompt injection attacks succeed against browser AI agents?

Anthropic's Claude in Chrome post (August 25, 2025) says prompt injection can cause AIs to delete files, steal data or make financial transactions. In its red-teaming of 123 test cases representing 29 attack scenarios, browser use without its new mitigations had a 23.6% attack success rate when deliberately targeted, and 11.2% with them in autonomous mode. On a challenge set of four browser-specific attack types, such as hidden form fields in the page's DOM and instructions in URL text or tab titles, the new mitigations took success from 35.7% to 0%. Its defenses start with permissions: site-level access and confirmations before high-risk actions like purchasing, plus blocking high-risk site categories such as financial services by default.

• OpenAI's post on hardening ChatGPT Atlas (December 22, 2025) says an injected agent's impact can be as broad as a user's, including sending money, that deterministic guarantees are challenging, and that prompt injection, like scams and social engineering, is unlikely to ever be fully solved. Its agents ask for confirmation before consequential actions such as completing a purchase, and it asks users to check that the action is correct before confirming.
• OWASP's LLM01:2025 Prompt Injection entry lists the same controls in general form: least privilege, with functions handled in code instead of given to the model, human approval for high-risk actions, and separating and marking untrusted content.

Why should spending controls for an AI agent sit outside the model?

A confirmation the model chooses to ask for is only as strong as the model. A cap, an allowlist and an approval check enforced by code the agent can't change hold even when the model has been fooled, because they look at the purchase itself (merchant, amount, payee) and not at the agent's reasons for it.

• Rightshold's spending controls work at that point. set_spend_policy, called with the owner's account key, sets a credential's currency, per-purchase and daily caps, allowed merchant domains and categories. authorize_spend then checks each proposed purchase and returns a signed allow or deny with reasons such as merchant_not_allowed or over_per_transaction_cap. It records the decision and never moves money, so the check only protects you if your payment code refuses to pay without an allow.
• For purchases that need a person, request_human_approval hashes the exact action. Only the owner's account key can decide it, and delegated agent keys are refused. Before paying, check the order you're about to send against the approved hash with verify_human_approval and stop if it doesn't match.