An agentic browser is a web browser with an AI model that can read pages and take actions for you, such as clicking, filling forms and navigating. The main risk is that any page the agent reads can contain instructions aimed at the model. Limit what the agent can reach and make it ask before consequential actions.
What makes a browser agentic?
A normal browser shows you content, and you decide what to do. An agentic browser puts a language model in the loop. You give it a goal, such as "find the cheapest flight" or "pull last month's invoices into a spreadsheet", and it reads page content, chooses actions and carries them out, often while signed in to your accounts.
That combination is the issue. The agent runs with your identity, and it reads untrusted content from the open web in the same context where it takes instructions from you.
Why is prompt injection the central risk?
The UK National Cyber Security Centre describes prompt injection as the situation where developers concatenate their own instructions with untrusted content in a single prompt, then treat the response as if there were a reliable boundary between what the app asked for and anything in the untrusted content. The NCSC says current large language models do not enforce a security boundary between instructions and data inside a prompt, and notes that OWASP ranks prompt injection first for generative AI applications.
OWASP's entry says prompt injection can occur through input that humans cannot see, as long as the model parses it. For a browser agent, hidden text on a page, an email, a document or a comment can all count as input.
The NCSC argues the problem differs from SQL injection, which can be fixed with parameterized queries, and suggests thinking of the model as an inherently confusable deputy. In its words, the goal is to reduce risk and impact rather than expect a fix, and if the system's security cannot tolerate the remaining risk, it may not be a good use case for LLMs.
What turns injection into harm?
OWASP's Excessive Agency entry names the root causes: excessive functionality, excessive permissions and excessive autonomy. For a browser agent:
- Functionality. It can click anything, submit any form and open any site.
- Permissions. It uses your logged-in sessions, with all your access.
- Autonomy. It acts without checking with you first.
OWASP's guidance for this problem includes minimizing the tools an agent can call, minimizing what each tool can do, requiring user approval for high-impact actions, and complete mediation, meaning downstream systems check authorization instead of trusting the model to decide whether an action is allowed.
A constructed example
A user asks an agentic browser to summarize a forum thread about a product. One reply contains hidden text telling an AI assistant to open the user's webmail and forward the latest message to an outside address. The agent is signed in to the webmail in the same browser profile. If it follows the hidden text, the user's own session does the work and the server sees a normal request from a normal device. Nothing in the network or server logs separates it from the user.
The remedies are structural: run the agent in a profile with no access to webmail, and require a confirmation click on any send or share action.
How to check or apply this
- Separate profiles. Run the agent in a browser profile with no saved sessions for banking, email, admin consoles or code hosting.
- Least privilege. Give it only the sites and actions the task needs. Block everything else by default.
- Approval for impact. Require a human click for purchases, sends, deletes, permission changes and anything that moves data off the page.
- Distrust page content. Treat everything the agent reads as untrusted, including content from well-known sites, since user-generated content lives there.
- Authorize on the server side. Do not rely on the agent to decide what is allowed. Apply limits in the services it touches.
- Log actions. Record every page visited and action taken so you can review what happened.
- Decide where it does not belong. Per the NCSC, if the remaining risk is unacceptable, skip the use case. High-value admin consoles are a good example.
- Test with adversarial pages. Before wider use, try pages with hidden instructions and see what the agent does.
Quick check
Can a better system prompt stop prompt injection?
Not reliably. The NCSC says current models do not enforce a boundary between instructions and data, so design to limit the impact instead of relying on wording alone.
What is the single most useful control for a browser agent?
Limit what it can reach and require human approval for high-impact actions, so a hijacked agent cannot do much damage.
Sources
- UK NCSC: Prompt injection is not SQL injection (it may be worse), fetched 18 October 2026.
- OWASP LLM01:2025 Prompt Injection, fetched 18 October 2026.
- OWASP LLM06:2025 Excessive Agency, fetched 18 October 2026.
Last reviewed: 18 October 2026.
