Prompt injection is not a bug that gets patched. It is a consequence of the fact that a language model receives instructions and data through the same channel and has no reliable way to tell them apart. The practical implication, which the 2026 evidence supports fairly bluntly, is that every defence which asks the model to police itself degrades under adaptive attack, and the defences that hold are the ones enforced deterministically in your application code, outside the model entirely.
That is not a new argument. What is new is that we have measurements on both halves of it: how much injected content is out there, and what happens to each class of defence when someone keeps trying.
How much of this is actually in the wild
Researchers at CISPA Helmholtz Center for Information Security, with co-authors from the University of Louisiana, published the first large-scale measurement of indirect prompt injection on the open web in April 2026. They crawled 1.2 billion URLs across 24.8 million hosts and found roughly 15,300 validated indirect prompt injection instances across about 11,700 pages.
Three details from that study change how you should think about ingestion.
Roughly 70% of injected instructions sit in non-rendered HTML. Headers, comments, metadata. Content that never reaches a human reader and that a naive text extractor hands to the model verbatim. If your pipeline strips tags and keeps everything else, you are specifically preserving the part of the page that was written for your model rather than for your user.
A small number of templates account for most of it. The study found 54 templates covering about 95% of cases, and that around 80% of injections appear in first-party content rather than in third-party embeds or ads. That is a useful finding in both directions: the current population is narrow enough to pattern-match, and it is sitting on the pages themselves rather than in the ad slot you were already suspicious of.
Compliance rates are low but not zero. The authors report compliance up to around 8% for smaller models on plain-text inputs, with structured input representations reducing it. An 8% compliance rate is not a rounding error when your agent reads a few hundred pages a day.
What happens to a defence under sustained attack
A study published in April 2026 by researchers at Swept AI and the University of Michigan built an adaptive attacker that evolves its strategies over hundreds of rounds and ran it against nine named defence configurations, from a bare security directive in the system prompt through input sanitisation, delimiters and instruction hierarchy to output filtering and layered combinations. Their finding, in their own words: "Every defense that relied on the model to protect itself eventually broke."
Two configurations held, and they are the same idea twice: output filtering implemented as hardcoded rules in separate application code, and a multi-layer defence that contains it. Across the paper's six extended runs those two produced a zero percent leak rate. The conclusion the authors draw is that "security boundaries must be enforced in application code, not by the model being attacked."
We should be straight about the provenance and about the numbers. Swept AI sells a tool for testing exactly this, and the paper's abstract closes by recommending it. The headline figure of more than twenty thousand attacks is a scope claim rather than a total the results section adds up to, and the extended-run passage does not reconcile: six runs of five hundred rounds at ten attacks a round is thirty thousand, not the fifteen thousand the paper states. It is a preprint, not peer-reviewed work. We cite it because the configurations are enumerated and the direction matches what the CISPA measurement and the standards guidance below independently suggest. It is corroboration, not proof, and we would not build an argument on it alone.
The argument it corroborates is old and boring: a system that can be talked out of a rule is not enforcing the rule.
The framing that makes this tractable
Simon Willison's "lethal trifecta", published in June 2025, is the most useful way we have found to explain the risk to a non-specialist stakeholder. An agent becomes dangerous when three things are true at once: it has access to private data, it is exposed to untrusted content, and it has a way to communicate externally. Remove any one leg and the attack has nowhere to go.
It is a threat model rather than a statistic, and its value is that it turns a vague "the AI might get tricked" conversation into a question you can answer per integration: which of the three does this component have, and can we take one away? Most of the time you can. An agent that reads external pages does not also need read access to the customer database in the same context window. An agent that drafts a reply does not need to be the thing that sends it. We made a related argument in agents versus workflows and in what is an AI agent: most jobs people describe as agentic are workflows, and a workflow has fewer legs of the trifecta by construction.
What the NSA says about the connector layer
In May 2026 the NSA published a Cybersecurity Information Sheet on the Model Context Protocol, and its framing is unusually direct for a standards document: MCP adoption has "outpaced the development of its security model".
Three of its named risks map straight onto things we see in real integrations. That "MCP components can be configured to access or process data without any required access control measures". That "some MCP implementations allow malicious actor-controlled inputs to reach execution environments without appropriate constraints". And the one that should be printed and stuck to a wall: "Outputs from tools and models should never be treated as implicitly trusted."
Its recommendations are the unglamorous ones: trust-zone boundaries, schema validation on every message, OS-level sandboxing, message signing with expiry, and monitoring outputs for injection. None of it is clever. All of it is code you write rather than behaviour you request.
The CVE record backs the point up. CVE-2026-34070 is a path traversal in the legacy prompt-loading functions of langchain-core before 1.2.22, CVSS 7.5. CVE-2026-35394 is a missing URL scheme validation in the mobile_open_url tool of mobile-mcp before 0.0.50, which allowed arbitrary Android intents including USSD codes, calls, SMS and content provider access, CVSS 8.8. Both are ordinary input validation failures in the plumbing, not exotic model attacks.
What this means for how you build
Six things, in rough order of how much risk they remove per hour of work.
- Treat every tool result as untrusted input. Not just web pages. Database rows a user can write to, ticket bodies, PDF text, filenames, calendar invites, the contents of a shared drive. If a person can put text in it, an attacker can put instructions in it. This is the same discipline as never letting the model be the source of truth, applied in the other direction.
- Strip what nobody reads. Given that roughly 70% of observed injections live in non-rendered HTML, extracting only visible text removes most of the current population for the cost of a better parser.
- Put the boundary in code, not in the prompt. An allowlist of permitted actions with typed arguments, evaluated by your code, beats any amount of instruction telling the model which actions are permitted. A system prompt is a suggestion with good intentions.
- Gate every irreversible action. Sending, paying, deleting, publishing, granting access. If the action cannot be undone, a human confirms it, and the confirmation shows what will happen rather than asking whether to proceed.
- Filter the output as well as the input. Deterministic checks on what leaves the system: no secrets, no unexpected URLs, no markdown images pointing at domains you did not approve. Data exfiltration through a rendered image URL remains one of the cheapest attacks there is.
- Log the whole trace. Prompt, retrieved content, tool calls, arguments, results, final output. The difference between a two-hour investigation and a two-week one is whether you kept the intermediate steps. We make the same point about AI system integration generally: the logging is not overhead, it is the product.
None of this makes prompt injection go away. It makes the blast radius small enough that an injection is an incident rather than a breach, which is the realistic goal.
The uncomfortable bit
If your architecture depends on the model reliably ignoring instructions embedded in the content it processes, you do not have a security control. You have a preference. The measurements above put a number on how often that preference is honoured, and the number is not high enough to build on.
That is worth saying plainly, including to ourselves, because the alternative design is slower to build and less impressive to demo.
FAQ
What is the difference between prompt injection and jailbreaking? Jailbreaking is a user trying to make a model ignore its own guidelines. Prompt injection is a third party placing instructions in content the model processes on someone else's behalf. Jailbreaking mostly risks embarrassment; injection risks your data and your systems, because the attacker is not the person the model is acting for.
Can a better system prompt stop prompt injection? No. It raises the effort required. The 2026 adaptive-attack work found every defence that relied on the model to enforce its own rules eventually broke, and a system prompt is the weakest version of that category. Use one, but do not count it as a control.
Does using MCP make this worse? MCP standardises how tools are described and invoked. It does not address permissions, write boundaries, logging or failure handling, and the NSA's May 2026 guidance says adoption has outpaced its security model. It neither causes nor solves injection; it makes it easier to connect many tools quickly, which enlarges the surface if the boundaries are not enforced separately.
How common is this really? The best available measurement found roughly 15,300 validated indirect injections across about 11,700 pages in a crawl of 1.2 billion URLs. That is rare per page and unavoidable at scale. If your agent reads the open web, it will encounter injected content.
What is the single cheapest thing to do first? Stop rendering agent output as HTML or markdown that can load remote resources, and require human confirmation on irreversible actions. Together those remove the two most common exfiltration and impact paths for a few hours of work.
Do we need a security vendor for this? Mostly no, and be careful here: this topic is heavily content-marketed, and a large share of the published statistics come from firms selling scanners. The controls that matter are ordinary application security practice applied to a new input source.
References
- Khodayari, S., Zhang, X., Acharya, B. and Pellegrino, G., "Indirect Prompt Injection in the Wild: An Empirical Study of Prevalence, Techniques, and Objectives", arXiv:2604.27202, 29 April 2026. https://arxiv.org/abs/2604.27202
- Deep, P., Emmons, S., Fox, A., Bacon, K., McAllister, K., Ortiz, P. and Flautner, K., "Evaluation of Prompt Injection Defenses in Large Language Models", arXiv:2604.23887v2, revised 12 May 2026. Authors are affiliated with Swept AI and the University of Michigan; Swept AI sells prompt injection testing tooling. https://arxiv.org/html/2604.23887v2
- National Security Agency Artificial Intelligence Security Center, "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation", Cybersecurity Information Sheet Ver. 1.0, May 2026, announced 20 May 2026. https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF
- Willison, S., "The lethal trifecta for AI agents: private data, untrusted content, and external communication", 16 June 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
- CVE-2026-34070, path traversal in
langchain-coreprompt loading, CVSS 3.1 base score 7.5, CWE-22, fixed in 1.2.22. https://github.com/langchain-ai/langchain/security/advisories/GHSA-qh6h-p6c9-ff54 - National Vulnerability Database, CVE-2026-35394, mobile-mcp URL scheme validation, CVSS 3.1 base score 8.8, CWE-939, fixed in 0.0.50. https://nvd.nist.gov/vuln/detail/CVE-2026-35394
- OWASP GenAI Security Project, Top 10 for LLM Applications 2026, published 3 August 2026. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
Written by JP Dippenaar, Sixees Labs. Last reviewed September 2026.