The web page that reprogrammed your browsing agent

A tech lead at a research tools company told me about the moment they stopped trusting their own agent. It could browse the web to gather information for a report. In testing, they pointed it at a topic, and one of the pages it landed on had text on it written for the agent, not for a human reader. The text told the agent to stop its task and instead pull a piece of internal context into its output. The agent, doing its job of reading pages carefully, read that too and started to comply.

The web is not a trusted data source. It is the least trusted one there is. The moment an agent reads pages it did not choose, from sites you do not control, every one of those pages becomes a channel for someone to talk to your agent.

The open web is an input, and inputs can be hostile

We are comfortable with the idea that user input can be malicious. A browsing agent widens that idea in a way teams do not always sit with. The agent pulls in content from anywhere on the internet, and it reads that content into the same context where its instructions live. A page owner who suspects that agents will visit can write instructions on the page aimed squarely at them.

This is indirect prompt injection at internet scale. The attacker does not need to reach your product. They put a payload on a page and wait for an agent to arrive. Search results, forums, documentation, a competitor’s site, a page set up specifically to catch crawlers. Any of them can carry a message the agent will read as a command.

What makes it worse is that browsing agents usually have other capabilities. They summarize, they call tools, they write to systems, they act. A page that can redirect the agent is a page that can, in the worst case, aim all of those capabilities at a target the page owner chose.

Contain what the agent can do with what it reads

You cannot sanitize the internet. So the defense is not about cleaning the input. It is about limiting what a hostile page can reach once the agent has read it.

Things that help:

Keep the agent’s power small while it browses. An agent that can only read and summarize is a poor weapon. An agent that can browse and also send data or take actions is a much better one for an attacker.
Treat fetched pages as untrusted data. Label them as external content in the prompt, and instruct the model that instructions found on a page are not orders from you.
Separate reading from acting. Let the browsing phase gather information, and put any action that follows behind a check that does not simply trust whatever the pages said.
Log the pages visited and the content pulled. When an agent behaves strangely, you want to trace which page fed it what.

The teams that run browsing agents safely accept that they cannot vouch for the content and design around that fact. The agent can read the whole open web. It just cannot be allowed to do much on the strength of a single page’s say-so.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we look hard at any agent that reads content from outside your systems. We map what it can do after it reads, and we ask what a page written to hijack it could actually accomplish. Browsing agents are useful, and they are also one of the widest attack surfaces a team can ship without noticing.

If your agent reads the open web, assume some of what it reads was written to steer it. Build so that a hostile page can waste its time and nothing more.