The Web Page is Part of the Prompt

A browser-using AI agent does more than retrieve information. It reads pages, interprets their contents, chooses its next step, and may click links, submit forms, use saved credentials, or call other tools.

That sequence creates a security problem. The agent receives instructions from its user, but it also processes text, code, images, and interface data supplied by websites. If the system does not keep those sources separate, a page can become a second, untrusted source of instructions.

Researchers call this indirect prompt injection. Instead of typing a malicious instruction directly into an AI assistant, an attacker places it inside content the assistant may encounter. A person might see an ordinary product page or support article while the agent also processes hidden text, manipulated HTML, or a visual pattern designed to influence its behavior.

The practical lesson is broader than “filter suspicious prompts.” A browser agent needs a content-to-action security boundary: external content may provide information, but it must not gain the authority to approve consequential actions. The model can recommend an action. A separate control should decide whether that action is permitted.

Traditional browsers render pages for people. A browser agent may consume much more than the visible page. Depending on its design, it can receive raw or parsed HTML, an accessibility tree that describes page elements, screenshots, or some combination of them.

Each representation can carry hostile input.

A 2025 demonstration by Sam Johnson, Viet Pham, and Thai Le embedded adversarial triggers in webpage HTML. The evaluated agent used a parsed-HTML accessibility tree, and the researchers demonstrated attacks across real websites that included credential exfiltration and forced advertisement clicks.[1] Another 2025 paper, WebInject, targeted agents that act from screenshots. Its authors manipulated the rendered page's pixel values to induce attacker-specified actions.[2]

These studies used particular agents and experimental setups, so they do not establish that every browser agent will fail in the same way. They do establish that switching from HTML to screenshots, or hiding malicious text from the human visitor, does not create a dependable trust boundary.

The problem also extends beyond a single model or browsing system. A 2026 public red-teaming competition evaluated indirect prompt injection across tool-calling, coding, and computer-use agents. It collected 272,000 attack attempts from 464 participants against 13 frontier models. All 13 were vulnerable in the evaluated scenarios, although measured attack success rates varied substantially by model.[3]

That study also tested concealment. An agent could carry out a harmful action while giving the user a final response that contained no obvious sign of compromise. The interface may therefore look normal after the important failure has already happened.

Prompt injection is often discussed as a strange conversation with a gullible chatbot. For a browser agent, the more useful framing is workflow integrity. Which inputs are allowed to shape an action, whose authority permits it, and what system enforces that decision?

“Content-to-action boundary” is an explanatory label, not an established industry standard. It describes an architecture in which the component interpreting a page does not get the final say over sensitive operations.

A practical design separates four responsibilities:

The distinction between a proposal and permission is the heart of the design. A model may suggest “submit this form,” but it should not be able to grant itself permission to submit it. Text from the form should have even less authority.

This resembles a familiar security principle called least privilege: give each component only the access it needs. The browser can read a page without receiving payment credentials. A research agent can collect sources without gaining access to email. A support assistant can draft a response without being allowed to send it automatically.

The Open Worldwide Application Security Project, or OWASP, recommends several related mitigations for prompt injection, including separating external content, restricting privileges, validating outputs, and requiring human approval for high-risk actions.[4] These measures work best as layers. None should be mistaken for a universal prompt-injection detector.

The policy layer must inspect the proposed effect, not merely scan the model's wording for suspicious phrases. At minimum, it should be able to answer:

Consider a hypothetical internal assistant asked to summarize a supplier's webpage. The page contains an instruction telling the agent to open a customer database, copy recent records, and upload them through a form.

The model might still generate that plan. The security boundary succeeds when the plan reaches the policy gate and fails several checks: the user asked for a summary, the database is outside the requested task, customer records are sensitive, and the upload destination was never authorized. The executor never receives approval, so the action does not occur.

This example exposes a weakness in systems that rely only on a confirmation dialog. If the dialog says “Allow the assistant to continue?”, the page may have already shaped what “continue” means. Meaningful approval should name the action, destination, account, and affected data in language the user can understand. “Send the drafted message to [email protected]” is useful. “Approve tool call” is not.

Approval should also be proportional. Requiring a person to confirm every scroll and ordinary navigation step creates fatigue and trains users to click through warnings. A better policy can allow low-risk reading, restrict medium-risk actions to a defined scope, and require explicit confirmation for operations such as sending data, publishing content, making purchases, changing permissions, or deleting records.

Prompt and content filters can catch known patterns. They can reduce noisy attacks and provide useful signals to the policy system. They are weaker as the final control because malicious instructions can be obfuscated, split across content, embedded in HTML, or delivered visually.

System prompts that tell the model to ignore webpage instructions are also worth using, but they leave the same model responsible for distinguishing trusted instructions from hostile content. Current evidence does not support treating that distinction as consistently reliable.

Sandboxing limits what an agent can reach. It can prevent a compromised browser process from accessing the wider machine, which is valuable containment. A sandbox does not decide whether an authorized action matches the user's intent. An agent confined to an email tool can still send the wrong message if that tool grants broad sending authority.

Least-privilege credentials reduce the damage an attack can cause, but they do not detect misuse within the allowed scope. Human approval can catch dangerous actions, but vague or frequent prompts create approval fatigue.

The defenses are therefore complementary:

Useful audit records should connect the content the agent observed, the action it proposed, the policy decision, the approval shown to the user, and the effect that was executed. Sensitive values may need redaction, but without that chain, a team may see only a normal final answer and an unexplained side effect.

A security review for a browser agent should trace one hostile page through the entire system. The review can start with a few concrete questions:

Testing should include pages that hide instructions, disguise them as ordinary interface text, spread them across multiple inputs, or ask the agent to conceal its behavior. The goal is not only to measure whether the model follows the attack. It is to verify that the surrounding system prevents an influenced model from converting that mistake into an unauthorized effect.

No available evidence supports a universal fix for indirect prompt injection. OWASP explicitly presents its controls as mitigations, and the research remains active.[4]

A content-to-action boundary also carries costs. Separating browsing from execution adds engineering work and sometimes latency. Policies can become stale or overly broad. Approval interfaces can fail if they omit important details. A compromised source that the organization has classified as trusted may bypass controls designed for unknown websites.

Most importantly, an action boundary does not guarantee truthful output. A malicious page may still distort a summary, hide relevant information, or persuade a user to make a bad decision manually. The architecture primarily limits the path from untrusted content to machine-executed consequences. Source verification, provenance, and careful presentation remain necessary for information quality.

That limitation clarifies the goal. A browser agent does not need perfect judgment before it can be made safer. It needs an application around it that assumes its judgment can be influenced.

The web should be treated as evidence the agent may consider, never as authority the agent may inherit. Once a browser can act, the most important boundary is no longer between the user and the model. It is between everything the model reads and everything the system permits it to do.