AI browsers that act on your behalf combine private data, untrusted web content, and the ability to act, the exact recipe for exploitation. We cover why these agents are so exposed and what controls actually help.
A new class of product arrived in force: the agentic browser, an AI that does not just answer questions about the web but navigates it, reads pages, fills forms, and takes actions on your behalf while logged into your accounts. It is genuinely useful, and it is, from a security standpoint, close to a worst case. An agent that browses the open web for a logged-in user combines, by design, every ingredient of the attacks we worry about most. If your organisation is adopting these tools, you need to understand why they are so exposed before you let them touch anything that matters.
Why agentic browsers are structurally vulnerable
We have written about the lethal trifecta, the observation that any agent combining access to private data, exposure to untrusted content, and the ability to communicate or act externally can be turned into an exfiltration or action tool by a single injected instruction. An agentic browser is the trifecta in its purest form, and it is worth seeing why:
- Private data: it operates inside your authenticated sessions, your email, your accounts, your documents.
- Untrusted content: its entire job is to read arbitrary web pages, the single largest source of attacker-controlled content in existence.
- Ability to act: it can click, submit, send, and navigate, taking real actions in your accounts.
Put those together and the consequence is direct: a malicious instruction hidden in any web page the agent visits can attempt to make it read your private data and act on the attacker's behalf, using your own logged-in sessions. The agent is doing exactly what it was built to do, reading the page and following instructions, and it cannot reliably tell your intent from an instruction planted in the content. This is why a broad consensus has emerged that prompt injection cannot simply be patched away for browsing agents; it is a structural property of giving an AI the whole web plus your credentials plus the ability to act.
What an attack looks like
The pattern is the indirect-injection one, with unusually high stakes. An attacker plants instructions in a web page, visibly or subtly, that the agent will read while doing its task. The page might tell the agent to extract information from the user's other open sessions, to submit a form, to navigate somewhere and act, or to send data outward. The user asked the agent to do something innocuous, like summarise a page, and the page itself hijacked the agent into something else. Because the agent acts with the user's authenticated access, the blast radius is whatever those sessions can reach.
Why "be careful" is not a control
The honest difficulty is that you cannot defend this by telling users to be cautious, because the user did nothing wrong, they visited a page, which is the entire point of a browser. And you cannot defend it by hardening the model alone, because the model following instructions in content is the feature. So the defense, as with the trifecta generally, has to break the chain at the system level rather than relying on the model's restraint or the user's vigilance.
What actually helps
- Scan the untrusted content before it drives action. The web content the agent ingests is the attacker's entry point; evaluating it for injected instructions before it can steer the agent is the highest-leverage control.
- Constrain what the agent can do and reach. Least privilege for an agentic browser means limiting which sessions, accounts, and actions it can touch, so a hijack is contained rather than total. High-stakes actions, anything that sends data or moves money, should require explicit human confirmation.
- Limit where data can go. Constraining the agent's ability to send information outward cuts the exfiltration leg of the trifecta.
- Govern enterprise adoption deliberately. Treat agentic browsers as a managed capability with policy and monitoring, not a tool employees quietly add, the shadow-AI problem with action attached.
Frequently asked questions
Are agentic browsers safe to use in an enterprise? They can be used, but not casually. Their structural exposure means they need real controls, content scanning, tight permissions, human confirmation on consequential actions, and governance, before they touch sensitive accounts. Adopting one without those is accepting a large, mostly invisible risk.
Will the vendors just fix prompt injection? The prevailing view, which we share, is that this cannot be fully solved at the model level for browsing agents, because it follows from the agent's core design. Vendors will reduce it, but you should plan as though residual injection risk is permanent and defend at the system level accordingly.
Isn't this the same as the lethal trifecta post? It is the trifecta made concrete in the highest-exposure product. The conceptual argument is the same; what is specific here is that agentic browsers combine all three legs maximally, by design, which is why they deserve their own attention and their own controls.
How Promptention helps
Two of the three legs of this problem are exactly where we operate. We scan the untrusted content reaching an agent for injected instructions, the web pages that are the attack's entry point, and we help enforce policy on what an agent is allowed to do and where it can send data, so that even a hijacked agentic browser runs into limits instead of running wild with your sessions. The model will keep reading the web and following instructions; the user will keep visiting pages. Our job is to make sure the malicious instruction on the page does not become an action in your accounts.
Promptention scans untrusted web content for injection and supports policy enforcement on agent actions, addressing the core exposure of agentic browsers.
