USENIX Security Research Puts Enterprise AI Agents on Notice About Web Prompt Injection

AI agents that browse websites, read pages and act through tools face a security boundary problem that ordinary chatbots largely avoid: the information they consume may also contain instructions designed to redirect them.

Research associated with the USENIX Security 2026 symposium examines that problem from both directions. MUZZLE, from researchers at Northeastern University and Mozilla, presents an automated way to find adaptive indirect prompt-injection attacks against web agents. A second paper, AttriGuard, proposes checking the causal basis of an agent’s proposed tool calls at runtime and reports blocking static attacks in its evaluation.

For companies deploying agents to research, update records, handle support workflows or complete online tasks, the central lesson is straightforward: web content is data, not trusted agent policy. Treating it otherwise can let a third party influence actions that were meant to follow a user’s request.

What indirect prompt injection looks like in an agent workflow

Indirect prompt injection does not require an attacker to type directly into an organization’s AI interface. Instead, hostile instructions are placed in content the agent is likely to encounter: a webpage, a document, a listing, a support page or another external resource. The agent may interpret those instructions alongside the legitimate material it was asked to process.

This becomes more consequential once an agent can do more than produce text. Web agents are built to navigate sites and perform tasks on a user’s behalf. If a malicious instruction changes what the agent does, the failure can affect confidentiality, integrity or availability—the three categories targeted in the MUZZLE evaluation.

Consider a simple, hypothetical procurement assistant. A user asks it to review vendor pages and prepare a purchase request. A page it visits could include hidden or prominent text attempting to make the agent disclose information from its working context, alter the requested vendor details, or take actions unrelated to the request. The issue is not that the page contains unusual language; it is that the agent might give that language decision-making weight it did not deserve.

MUZZLE shifts testing from fixed prompts to adaptive attacks

MUZZLE was designed around a limitation in much existing evaluation work: fixed attack templates and manually chosen injection locations can miss the ways attacks change according to what an agent actually does.

The framework uses an agent’s execution trajectories to identify high-salience places for injection. It then generates context-aware malicious instructions, observes the outcome, and refines its approach when an attempt fails. That feedback loop matters because an effective attack may depend on the particular task, the agent’s prior steps, the model behind it and the scaffolding used to give it browsing or action capabilities.

In its evaluation, the researchers report finding 44 new attacks across four web applications and 10 adversarial objectives, spanning confidentiality, availability and privacy violations across different LLMs and agent scaffolds. They also report three cross-application prompt-injection attacks and an agent-tailored phishing scenario.

The number should not be read as a universal rate of vulnerability for every enterprise agent. It is evidence of something more useful for operators: when testing is allowed to adapt to the agent’s behavior rather than replay a small library of known prompts, additional failure modes can emerge.

A defense aimed at the moment an agent acts

AttriGuard approaches the same enterprise concern at a different point in the system. Rather than focusing on finding injection surfaces and crafting attacks, it proposes runtime causal checks on proposed tool calls. The intended question is whether the action an agent is about to take can be attributed to the legitimate user task and authorized context, rather than to untrusted content the agent encountered along the way.

The paper reports blocking static attacks in its evaluation. That is promising, but it should not be mistaken for a blanket resolution of adaptive prompt injection. MUZZLE’s contribution is specifically to generate and refine attacks based on observed trajectories; AttriGuard’s reported result in the supplied research description concerns static attacks. These are complementary findings, not a like-for-like scorecard between attack and defense.

Still, the design direction is important. Agent safety cannot rest only on asking a model to ignore malicious text. Once an agent is preparing to send an email, modify a record, upload data, make a request or take another tool-mediated action, the system has a concrete checkpoint where it can inspect and constrain risk.

What enterprises should change in their threat model

The practical mistake is to view prompt injection as merely a content-quality issue. In an agentic system, untrusted content can sit on the path to a real action. The relevant security question is therefore not only, “Did the model encounter bad instructions?” It is also, “What permissions, tools, data and downstream systems were reachable after it did?”

• Separate instructions from retrieved content. Content from the open web and other external sources should not automatically gain the authority of a user instruction or internal policy.
• Limit tool permissions. An agent should receive the narrowest capabilities needed for a task, particularly where sensitive data or irreversible changes are involved.
• Put controls near consequential actions. Runtime validation of proposed tool calls offers a more specific control point than relying solely on the model’s interpretation of page content.
• Test adaptively, not just with a prompt checklist. The MUZZLE findings suggest that testing should account for task flow, browsing trajectories and attack attempts that evolve after failure.
• Keep meaningful oversight for high-impact actions. Review or explicit confirmation is especially relevant where an agent could disclose data, change financial or business records, or communicate externally.

What to watch next

The research points to a widening gap between a demonstration agent and an enterprise-ready one. An agent can appear reliable in a controlled workflow while behaving differently when exposed to adversarial material across the web. Evaluation has to include the messy environments in which agents will actually operate.

The next useful evidence will be how runtime defenses such as causal checks perform against adaptive attacks, across varied models, tool sets and business workflows. Organizations should also look for evaluations that measure not only whether an attack was blocked, but whether legitimate tasks remain workable under the same controls.

For now, the deployment principle is clear. Browsing agents should be engineered as systems that process adversarial input while holding limited authority—not as assistants that can safely follow whatever text appears in their context.