Indirect prompt injection targets browser agents

A browser agent opens a vendor page to summarize a product update. The visible article is ordinary. A block of text buried in the page tells automated readers to abandon the summary, open another tab, and copy information from the current session. The person who assigned the task never sees that instruction.

The agent does see it. The text arrives beside the article, so the model has to decide whether it is content or a command. If the agent also has access to an authenticated inbox, a file store, or an outbound tool, one hostile page can turn a reading task into an unauthorized action.

That is indirect prompt injection. Direct injection starts with the user. Indirect injection starts in material the agent retrieves. The attacker does not need to reach the prompt box. The web page, email, or document becomes the delivery path.

Your agent reads everything. That is the attack surface.

A human reader and a browser agent do not experience a page the same way. The person notices the headline, the chart, and the button. The agent may receive extracted text, the rendered DOM, an accessibility tree, image content, or tool output assembled from several of those sources. Material that is visually minor can still become prominent inside the model context.

The risk begins with the agent's job. A useful browser agent must read untrusted material. It must also decide what to do next. Summarizing a page, following a link, downloading a report, and drafting a response all require the model to interpret content and select an action. The same capability that makes the workflow useful creates the control surface.

Hidden does not always mean invisible CSS. The instruction might sit in a long comment thread, a collapsed panel, document metadata, image text, or an email quoted below the current message. It only needs to enter a representation the agent processes. Once there, it competes with the actual task.

The attacker also gets more chances than the user. The user writes one request. The agent may visit several pages, read attachments, inspect search results, and pass outputs between tools. Every retrieved artifact adds another place where instructions can ride inside data.

Direct vs indirect injection

Direct prompt injection arrives through input explicitly sent to the model. A user asks the system to ignore its rules, reveal restricted information, or take an action outside the stated task. The application can identify the sender, the input field, and the moment the instruction entered the system.

Indirect prompt injection arrives inside retrieved content. The user asks for a legitimate task, such as summarize this page or review this email. The hostile instruction is already inside the page, message, attachment, or search result. The agent retrieves it because retrieval is part of the approved task.

That difference expands the attack surface. Direct injection depends on access to the agent's user channel. Indirect injection can wait anywhere the agent might read. A public page can target unknown future agents. A poisoned document can remain dormant until an automated workflow opens it.

Help Net Security's June 2026 coverage of OWASP found that prompt injection still ties most agentic security incidents together. The coverage identifies the architectural problem: system instructions, user requests, and retrieved content reach the model as tokens without a dependable boundary between commands and data.

TechStoriess describes prompt injection as a structural risk that filtering cannot fully remove. Its defensive guidance combines content filtering with sandboxing, output monitoring, and least privilege. That layered approach matters because no classifier gets the final word on every page an agent will encounter.

Direct injection is easier to frame as a user-input problem. Indirect injection is a web-trust problem. Your application did not choose the instruction, but its agent fetched, interpreted, and acted on the container that carried it.

Anatomy of a browser-agent hijack

A browser-agent hijack does not require a dramatic exploit. It needs untrusted content, useful permissions, and an action path. The following chain stays at the mechanism level. It omits payload language and operational details.

1. The agent receives a normal task. It may need to compare prices, summarize a support thread, or collect facts from a vendor site.
2. The browser retrieves hostile content. A page or document contains text aimed at an automated reader. The content presents an unrelated instruction as part of the task.
3. The model accepts the new objective. It treats the embedded instruction as authoritative enough to alter its plan, even though the user never approved the change.
4. An allowed tool supplies reach. The agent uses an authenticated tab, file-reading capability, clipboard access, or another tool already available to the workflow.
5. An outbound action carries the result. The agent places data into a request, form, message, or other channel the environment permits.

The page did not break the browser sandbox. It redirected the agent inside the permissions it already had. That distinction matters. Traditional browser defenses focus on code crossing a technical boundary. Prompt injection focuses on the model misusing an approved path.

The impact depends on what surrounds the session. An agent browsing from a daily profile may inherit live cookies, saved logins, history, extensions, and access to internal applications. A page that changes the agent's plan can turn those conveniences into reachable assets.

Exfiltration is only one outcome. A hijacked agent could submit a form, alter a record, send a message, or download a file. Disposal cannot reverse an action that already reached an external system. The goal is to remove unnecessary authority before the page gets a chance to steer it.

Why model-level defenses are not enough

Model instructions still matter. Tell the agent to treat retrieved content as untrusted. Delimit external text. Require confirmation before sensitive actions. Scan inputs for instruction-like language. These controls reduce easy failures and make the desired policy explicit.

They do not create a hard boundary. The model still interprets the task and the retrieved material in the same reasoning process. A legitimate page can contain imperative language. A malicious page can phrase its objective as ordinary data. The classifier has to infer intent from context, which is exactly the ambiguity the attack uses.

Placement creates another gap. A filter running before navigation cannot inspect content produced after client-side rendering. A text-only guard cannot assess instructions carried through an image. A guard that checks page text may not see later tool output. Each control evaluates the representation it receives, not every representation the agent may process next.

Even a correctly detected injection leaves an execution question. What happens if the model follows it anyway? What can the browser read? Which destinations can it contact? Which state survives? Model behavior can lower the chance of compromise. It cannot define the blast radius after compromise.

This is why alignment and filtering are necessary but insufficient. They operate at the decision layer. The durable security boundary belongs beneath that layer, where files, credentials, network reach, tool permissions, and session lifetime can be enforced regardless of what the model decides.

Containment: the execution-layer answer

Containment starts from a less comfortable assumption: one page will eventually fool the agent. The system should remain useful after that assumption. The question changes from whether the prompt was detected to what a hijacked session can touch.

Use a fresh browser for the task. Carry in no daily-profile cookies. Mount no local files by default. Add only the credentials the task requires. Restrict tools to the smallest useful set. Limit outbound destinations where the workflow allows it. Destroy the environment when the job ends.

Those controls do not make prompt injection disappear. They make the successful injection less valuable. The attacker reaches a short-lived browser instead of the operator's workstation. The session has less history to inspect, fewer systems to call, and less state that can survive the close.

The layers answer different failure modes. Filtering lowers exposure. Permissions narrow available actions. Network policy limits exits. Human approval adds friction at chosen boundaries. A disposable browser separates the agent from the durable endpoint and removes session residue after close.

Agents that reach browsers through MCP also need tool-level permission controls, but this threat model stays focused on the browser execution boundary.

Isolation has limits worth stating plainly. It cannot recover data already sent. It cannot undo a submitted form. It cannot protect a credential deliberately introduced and then exposed through an allowed action. Containment works when isolation, least privilege, and controlled egress are applied together.

Running agents with a smaller blast radius

Start by separating the agent from your normal browser profile. Legba's browser surface for agents gives the workflow a disposable real browser: it spawns a clean session, does the work, and destroys itself on close. The agent still reaches the real page. The operator's daily browser does not become the execution environment.

Computer-use agents need the same boundary around a wider surface. The OpenClaw environment keeps agent activity off the user's laptop. The detailed guide to running OpenClaw safely explains why a disposable environment should be the evaluation default before an agent receives a real machine.

Policy must follow the environment. Decide which credentials enter each session. Separate read tasks from write tasks. Put approval in front of messages, purchases, uploads, and record changes. Record tool activity outside the agent's control. End the session when its declared job ends.

• Spawn fresh. Do not inherit a daily browser profile.
• Scope the task. Give the agent one job and the tools it needs.
• Separate authority. Keep reading and state-changing actions on different approval paths.
• Control exits. Allow only the destinations required by the workflow.
• Destroy on close. Remove browser state when the task ends.

This also reduces the risk created by unsanctioned agent use. The guide to shadow AI covers the visibility gap when people route company data through unapproved AI tools. Browser agents add autonomous action to that same governance problem.

The web will keep mixing instructions with information. A browser agent cannot avoid untrusted content and still browse. You will not classify every hostile sentence correctly.

Build for the miss. Give the agent less durable state, less ambient authority, and fewer exits. Then make the browser disposable.