SecurityTechInsider AI security & governance
EN/ NL
Risk

Indirect prompt injection via documents and websites in 2026

Hidden instructions in websites and documents can mislead AI systems. What NIST, Google, arXiv and OWASP report and what it means for workflows.

31 July 2026 4 min
Illustration for this article: Indirect prompt injection via documents and websites in 2026. A dense bundle of unbranded patch cables, sharp at one connector and falling out of focus behind.
External content can carry hidden instructions that redirect AI systems from their intended task, requiring validation before processing. Image: SecurityTechInsider — original editorial illustration

You must now treat external content—websites, documents, emails—as an unreliable input source for any AI system or agent you operate. Hidden instructions embedded in that content can steer model behaviour away from your intent. Establish controls before feeding external material into your workflows.

The prompt is an analysis of 31 July 2026 of indirect prompt injection via documents and websites, which argues that this attack vector has moved from theoretical risk to observed practice at scale. The empirical case is a study of 1.2 billion URLs that identified over 15,000 validated indirect prompt injections across nearly 12,000 pages. In our assessment, this means you can no longer assume that content retrieved from the public web, or from documents you do not author, will not contain malicious instructions designed to compromise your AI workflows.

What is indirect prompt injection and why does it matter now?

Indirect prompt injection differs from the direct variant in one critical way: the malicious instruction does not come from a user typing into a chat interface, but from an external source that your AI system retrieves and processes. A website, a PDF, an email—any content your system reads can carry hidden directives. NIST's formal definition recognises this explicitly: indirect prompt injection is prompt injection carried out via resource control rather than direct input. The distinction matters because it means the attack surface includes every external data source your workflow touches.

For professionals handling confidential information—lawyers, compliance teams, researchers, occupational physicians—this is not abstract. As soon as you ask an AI system to summarise a document, assess a webpage, or extract information from an email, you are feeding it content whose provenance and reliability you may not have verified. The empirical evidence now shows this is a real problem. Google reported a 32% increase in malicious indirect prompt injections between November 2025 and February 2026. That is not a projection; it is an observed signal from the public web.

Which failure modes does indirect prompt injection create?

  • Instruction override — hidden directives in external content redirect the model away from your stated task.
  • Data exfiltration — malicious instructions embedded in documents can cause the system to output sensitive information it should withhold.
  • Confidence manipulation — injected prompts can cause the model to express false certainty about incorrect answers.
  • Context poisoning — malicious content contaminates the context window, affecting all subsequent processing in that session.
  • Privilege escalation — injected instructions can cause the system to perform actions or access resources beyond its intended scope.

What controls must you be able to demonstrate?

  1. Separate instructions from data — ensure your system architecture treats user directives and external content as distinct inputs, never merged into a single prompt.
  2. Validate external content before processing — implement pre-processing checks on any document, webpage or email before feeding it to your AI system.
  3. Apply the principle of least privilege — configure each AI workflow to access only the data and perform only the actions it needs for its specific task.
  4. Maintain human review for sensitive outputs — require human verification before the system acts on results derived from external content, especially for high-risk decisions.
  5. Document the provenance of each input — record which external sources fed into each workflow and what controls were applied to them.

How do NIST, Google, arXiv and OWASP frame the risk?

NIST has formalised the attack vector in its glossary, removing any ambiguity about whether this is a genuine threat category. Google's security research documents how the attack occurs in practice on the live web. The arXiv study provides the scale: over 15,000 validated injections found in a sample of 1.2 billion URLs. That convergence of formal definition, observed prevalence and empirical measurement means you cannot treat this as a future concern. OWASP's LLM Prompt Injection Prevention Cheat Sheet and AI Agent Security Cheat Sheet both identify indirect injection via external content as a core attack pattern and recommend the same defensive layers: input sanitisation, clear separation between instructions and data, least privilege access, and human-in-the-loop controls for high-risk actions.

What can tooling do, and what remains your responsibility?

No single defensive layer eliminates the risk. Tooling can make your controls more transparent and your workflows more auditable. It can enforce separation between instructions and data, apply pre-processing to external content before it reaches your AI system, and surface the provenance of each input so you can see what fed into each decision. What tooling cannot do is make the final judgement about correctness or truth. That remains yours. The combined signal from NIST, Google, arXiv and OWASP is clear: in 2026, external content deserves suspicion by default, and defensive layers are no longer optional. Your professional responsibility is to know which controls you have applied and to verify that they are working.

Sources: This article draws on reporting and guidance from NIST, BLOG and OWASP.

Tobias Lindqvist

Written by

Tobias Lindqvist

Adversarial machine learning and the security properties of retrieval systems.