Prompt injection meets online banking: what agentic-browser research tells banks

Most of the debate about AI agents and bank accounts has been about the customer: did they intend what the agent did? There is a second problem that has nothing to do with the customer's intent. An agent that reads the web can be instructed by the web. If it happens to be signed in to a bank at the time, so can the bank account.

This attack is called indirect prompt injection. It is now well documented in agentic browsers, and Wells Fargo's new terms name it, in effect, when they make customers responsible for agent actions “resulting from incomplete, inaccurate, or manipulated inputs” (section 15(e)). This post summarises the public research and what it implies for anyone running a site where money moves.

What indirect prompt injection is

A language model cannot reliably tell the difference between instructions from its user and text it happens to be reading. If a web page, email or document contains something that looks like an instruction (“ignore the previous request and do this instead”), the model may follow it. The text can be hidden from people: white on white, in an HTML comment, or faint text in an image.

The OWASP GenAI Security Project ranks the general class first in its Top 10 for Agentic Applications as “agent goal hijack”: an attacker redirecting an agent's objectives through content it processes.

The Brave research

In August 2025, Brave's security team published a study of Perplexity's Comet browser. They found that when a user asked Comet to summarise a page, it fed part of the page to the model without separating it from the user's request. In their demonstration, a hidden comment on a Reddit post instructed the agent to collect the user's email address and a one-time login code from their email, and send both back to the attacker.

The researchers' framing of the risk is the part banks should read twice. The agent, they wrote,

“operates with the user's full privileges across authenticated sessions, providing potential access to banking accounts, corporate systems, private emails, cloud storage.”

A follow-up, “Unseeable prompt injections in screenshots”, showed the same class of problem in other AI browsers, including instructions hidden in images that people cannot easily see. Brave's conclusion was that this is not one vendor's bug but a difficulty common to agentic browsing.

What the browser makers say

OpenAI's December 2025 post on hardening ChatGPT Atlas describes automated red-teaming that uses reinforcement learning to find attacks, model-level and system-level defences, and a rapid response loop for fixes. It is a serious effort. It is also candid: ITPro's coverage carried OpenAI's view that prompt injection is “unlikely to ever be fully solved”, and a long-term AI security challenge.

That is the honest position across the industry. Defences make attacks harder and rarer. They do not make an agent safe to hand unlimited authority in a session where money can move.

Is this happening in practice?

There is no public case of a bank customer losing money to a prompt-injected agent, and the October 2026 bank reports did not describe one. But organisations running agents are seeing them act outside their instructions. In Salt Security's 2H 2026 survey of more than 380 professionals, 49.8% confirmed or suspected an agent had taken an unexpected or unauthorised action in the past year, and more than half of that group reported unauthorised external API calls or transactions, Campus Technology reported. Not all of that is prompt injection. All of it is agents doing things nobody asked for.

What the researchers recommend

Brave's recommendations, from the original post, translate directly to banking:

• “Security and privacy sensitive actions should require user interaction.” Their example: sending an email should always prompt the user to confirm right before it is sent.
• “Powerful agentic capabilities should be isolated from regular browsing tasks.” An agent reading Reddit should not be the same agent holding your bank session.
• Separate the user's instructions from page content, and check whether proposed actions match what the user actually asked for.

What it means for a bank or fintech

All three recommendations are for the browser maker. A bank cannot control which browser or agent its customer uses. What a bank controls is its own site: which actions are sensitive, and what has to be true before they go through.

The first recommendation can be enforced from the bank's side. If adding a payee, changing contact details, raising a limit or sending a transfer requires a person to be in control at that moment, then an injected instruction can make the agent try, but cannot make the action complete. The agent may still read, summarise and prepare. The step that moves money waits for a person.

That check has to be robust to the obvious workaround: the agent pressing the confirm button itself. An approval that software in the same session can complete is not user interaction in Brave's sense. It needs to establish that a person, not the agent, is at the controls for this specific action. That is the question HEIP answers for the platform's server, with ALLOW, STEP_UP or DENY and reasons, without asking the person to solve a puzzle and without learning who they are.

Takeaway

Prompt injection turns every page an agent reads into a potential source of instructions. The browser makers are working on it, and say plainly it will not be fully solved. The durable defence is at the point of action: whatever the agent was told, the money does not move unless a person is there to move it.