Prompt Injection via Web Content in Agentic Pipelines

Prompt injection through web content is the central engineering problem in building AI agents that fetch and act on live data. When an agent reads a webpage, a PDF, or a database record and treats what it finds there as an instruction instead of information, whoever controls that content controls the agent. That's documented, it's growing, and it changes what "building an agent" means from an engineering standpoint. Chatbots never had this problem in any serious way. Agents can't avoid it.

Start with a basic split. Direct prompt injection is when the attacker types the malicious input themselves, right into the chat box. Indirect prompt injection is when the attacker plants instructions in a webpage, a document, an email, or a calendar invite that the model reads later, on its own, while doing some unrelated task. The attacker never touches the conversation.

That distinction barely mattered when the worst outcome was a chatbot saying something weird. It matters enormously now that agents have hands. A chatbot that follows a bad instruction gives a bad answer. An agent that follows a bad instruction sends the email, runs the shell command, calls the API, writes the row to the database. The failure moved from wrong text on a screen to action taken in the world. That's the whole shift, and it's why the old chatbot safety playbook doesn't cover this.

OWASP has ranked prompt injection as LLM01, the top slot in its Top 10 for LLM Applications, for three straight editions running. This isn't a fringe worry one security team raised and dropped.

SQL injection is the comparison people reach for, and it should worry you more than comfort you. Both bugs come from the same root cause: mixing untrusted data into trusted instructions and losing track of which is which. SQL injection got a real fix, though. Parameterized queries separate query structure from data values at the architecture level, and the problem mostly disappeared for anyone who adopted them. Prompt injection has no equivalent fix waiting in the wings, and it probably never will, because instructions and data both appear in the model as plain natural-language text. The model has no built-in way to tell "do this" apart from "here's a fact about this." There's no parameterized query for natural-language text.

The mechanism: how a fetched webpage becomes an instruction

Strip it down. An agent fetches a webpage, a document, a search result, whatever the task calls for. Somewhere inside, an attacker has hidden text that reads like a command. Sometimes it's white text on a white background. Sometimes it's tucked into a meta tag or an HTML comment. The agent doesn't draw a line between content to summarize and a command to obey. It reads the whole page, and if the hidden text sounds like an instruction, it follows it.

The user never typed anything malicious. The payload comes in through the agent's own retrieval step, not through the front door. That makes it hard to catch in a normal review.

A few real cases make this concrete. One involved a Google Docs file that got an AI coding assistant to reach out to a malicious MCP server and run a Python script that harvested secrets, all without the user doing anything beyond opening a document. Other payloads have shown up embedding full PayPal transaction details inside ordinary web content, clearly built for agents with payment permissions to pick up. Some hide injected text inside website meta tags aimed at rerouting financial actions to accounts the attacker controls. Others sit in code repository comments, built to trick AI coding agents with shell access into running recursive delete commands.

None of this is theoretical. Researchers at Google tracking malicious payloads embedded in web content found a 32% jump in these attacks between November 2025 and February 2026. A few months, one-third more attacks. The threat is worsening. It's compounding.

Every place web content enters an agentic pipeline

Every point where an agent pulls in outside content is a door. Some doors are obvious. The ones that actually get systems breached are the ones nobody thought to lock.

Webpages fetched by a browsing agent are the most direct route in. PDFs and documents pulled into a RAG pipeline carry the same risk under a different name. Database records read by a support agent or an ops agent during a routine lookup can carry a payload nobody thought to check. MCP tool descriptions load the moment a session starts, and a malicious server can bury instructions right inside a tool's name or description field, read by the model during discovery, before a single real task even begins. Memory stores carry state across sessions, so poison one session's memory once, and every future session inherits it.

The RAG risk deserves a hard number. Research published in 2026 found that five carefully placed documents can manipulate an AI system's output 90% of the time through RAG poisoning. Five documents, not five thousand. A poisoned file sitting quietly in a knowledge base is, from a security standpoint, no different from a poisoned webpage. Treating it as the safer, lower-risk case is exactly backwards.

MCP has widened this surface fast. The protocol has reached massive scale, with tens of millions of monthly SDK downloads and tens of thousands of servers indexed. That's a lot of production systems now carrying tool-description and tool-output injection as a live feature of how they run day to day. And a meaningful share of MCP servers ship with no authentication at all, which means anyone can stand one up and start feeding instructions to whatever agent connects to it.

Cross-Site Prompting, or XSP, is a term used in Prismata research to describe indirect injections planted on an otherwise ordinary site that manipulate a visiting agent. It's a close cousin of cross-site scripting, XSS, except the old XSS defenses don't carry over. XSS payloads are executable code, and you can pattern-match and block executable code. XSP payloads are just words, sometimes images, and there's no clean syntax check that flags a sentence as malicious.

How attacks escalate in multi-agent and orchestrated systems

Some attacks aim lower than stealing a file. They go after the agent's sense of purpose. Goal hijacking doesn't pull out one piece of data or trigger one bad action. It rewrites what the agent thinks it's supposed to be doing.

In a multi-agent setup, that kind of hijack doesn't stay put. An agent whose goal gets flipped can pass bad instructions to the next agent in the chain, poison a shared memory store other agents read from, or feed an orchestrator false signals that shape every decision downstream. The more autonomy and tool access an agent has, the further this spreads, and the harder it gets to trace back to where it started.

Two production incidents show what this looks like at scale. EchoLeak hit Microsoft 365 Copilot. An attacker sends a crafted email. Later, on some completely unrelated task, the victim asks Copilot an ordinary question. Copilot's RAG system pulls up the malicious email during retrieval, reads the embedded instructions, and follows a command to search for sensitive data. The results get encoded into an image URL pointing at the attacker's server. The victim's browser loads that image like any other, and the data walks straight out. Zero clicks. The victim did nothing wrong at any point.

GeminiJack, aimed at Google Gemini Enterprise, runs the same play on a different stack. An attacker shares a Google Doc, sends a calendar invite, or just sends an email. The hidden instructions get indexed by Gemini Enterprise's own RAG system. Any employee later running a routine search triggers the payload, and data exfiltrates the same way, through an image URL request. Different company, same architecture flaw, same outcome.

GitHub Copilot had its own version too, tracked as CVE-2025-53773, rated 9.6 on the CVSS scale. Malicious instructions buried in externally fetched content got the agent to run commands the attacker chose. That's remote code execution wearing a coding assistant's clothes.

The Data Ingestion Layer: Where Defense Begins

The ingestion layer is the first place attacker content touches the pipeline, so it's the right place to start cutting the problem down to size. It can't finish the job alone, and any team that treats it as the whole fix is writing next quarter's incident report early.

How a page gets cleaned before it reaches the model matters for security, not just for cost. Raw HTML off a fairly ordinary website can run past 50,000 tokens once you count every script tag, nav menu, and tracking pixel. Clean that same page down to plain Markdown, and it often fits under 5,000 tokens, cheap to run and easy to defend. That's cheaper to run, sure. It also leaves an attacker fewer places to hide a payload, since footers, sidebars, and menu boilerplate are exactly where injected text likes to sit unnoticed.

Clean ingestion has limits, and nobody should overtrust this step. It cuts the token surface, strips the boilerplate hiding spots, and forces some structure onto the fields the agent reads. It leaves a plain text string free to carry an instruction. It's no substitute for actually detecting malicious intent or running guardrails at execution time. Cleaning the page makes the payload easier to spot. It doesn't make the payload go away, and treating it like it does is how systems get burned.

The five defense layers production systems need across the pipeline

OWASP's own position is blunt: no single technique stops prompt injection. The right architecture is defense-in-depth, several independent layers stacked so beating one doesn't mean beating the whole system. Each layer just has to raise the cost of getting through, and skipping any one of them to save time is how a team ends up as the next case study.

Semantic detection at input catches injection attempts in what the user types, before the request ever reaches the model. It partially covers indirect injection too, when poisoned content arrives through a channel the user controls. Azure's Content Safety Prompt Shield runs a dedicated model trained to spot jailbreaks and indirect injection, checking user prompts and attached documents as separate inputs instead of one blob of text. AWS Bedrock Guardrails does something similar, combining pattern matching with semantic analysis. Neither one touches content that arrives through retrieval or through a tool's own output, though, and that's most of the attack surface described above.

Inspecting what RAG retrieves matters because every document sitting in a retrieval corpus is a candidate payload. Five well-placed files can swing an AI system's answers 90% of the time. Five files. That number should set the bar for how seriously a knowledge base gets audited.

Governing MCP tools means running an allow-list, so only pre-approved tools can get called, and even a successful injection has nowhere to go if it tries to invoke something outside that list. Tool descriptions need review at connection time too, since tool poisoning hides its payload right in the server metadata the model reads during discovery, before any task starts. Security and access control remain a widely cited challenge among MCP builders, and with an unknown but significant share of servers running no authentication at all, the sane default is to treat any unvetted MCP server as untrusted content, same as a random webpage. Audit which servers are actually connected, keep them off untrusted networks, and keep the tooling patched.

Emerging research-backed defenses for web agents specifically

Beyond the standard layers, research aimed squarely at web agents is starting to produce sharper tools. Prismata's approach centers on contextual least privilege: instead of granting a web agent broad standing permissions across an entire browsing session, the agent's privileges narrow down to what the current task actually needs, in the specific context it's operating in at that moment.

An agent reading a page to summarize it shouldn't carry the same authority as one that's been asked to submit a payment, and the system is built to keep those two modes from bleeding into each other. That framing, permission as something that shrinks and grows with context instead of sitting fixed for a whole session, is where a lot of the newer defense work for web agents is headed. The standard input-layer filters were never built with a browsing, clicking, form-filling agent in mind. It shows every time one of these incidents ends up in a postmortem.