Indirect prompt injection is no longer a lab curiosity in 2026. Whereas a classic prompt injection runs via direct user input, in the indirect variant the malicious instructions come from external sources: a web page, a document or an email. The NIST CSRC Glossary defines indirect prompt injection as prompt injection carried out via resource control rather than via direct input. External sources are thereby explicitly recognised as an attack vector for AI systems.
For professionals who work with confidential information, this is relevant. As soon as an AI system or AI agent retrieves and processes content that is not fully under its own control, the risk arises that hidden instructions steer the system's behaviour. This makes the way external content is handled a core question in every AI workflow.
What the sources show
In the article AI threats in the wild: The current state of prompt injections on the web on the Google Security Blog, Google describes how indirect prompt injection occurs in practice on the public web. Websites, emails and documents can carry malicious instructions. Google reports a 32% increase in the malicious category between November 2025 and February 2026. It is therefore no longer a theoretical possibility, but an observed signal.
The scale is substantiated by an empirical study on arXiv titled Indirect Prompt Injection in the Wild: An Empirical Study of Prevalence, Techniques, and Objectives. The researchers analysed 1.2 billion URLs and found 15.3 thousand validated indirect prompt injections on 11.7 thousand pages. Their conclusion is sober but important: web pages and HTTP responses are an unreliable input source for LLM-driven systems.
That conclusion serves as a useful starting point for a concrete premise: external content is unreliable by default until proven otherwise.
Defence according to OWASP
Where the attack side is clearly described, OWASP offers practical guidance on the defence side. The LLM Prompt Injection Prevention Cheat Sheet classifies remote or indirect prompt injection as an attack pattern in which malicious instructions are hidden in external content such as web pages, documents and emails. As defensive layers, OWASP mentions among other things input sanitisation, a clear separation between instructions and data, the principle of least privilege and validation of the output.
OWASP's AI Agent Security Cheat Sheet places the same risks specifically with AI agents. Prompt injection via websites, documents and emails is identified there as a core risk. The recommended measures include input sanitisation, separation between instructions and data, human-in-the-loop for high-risk actions and isolation of context between users and sessions.
The common thread in both OWASP documents: do not treat data and instructions as the same, do not give systems more rights than needed, and keep a human in the loop for sensitive steps.
What this means for sensitive workflows
For lawyers, notaries, occupational physicians, journalists, researchers and compliance teams, the underlying principle is recognisable. Anyone who has an external document or a web page summarised or assessed by an AI is in fact feeding in content whose provenance and reliability are not established. The empirical findings on arXiv and Google's observation underline that this is real.
The practical translation that follows from these sources consists of a few principles:
- Treat external content as unreliable by default and explicitly separate instructions from data.
- Limit the rights of AI systems to the minimum a task requires.
- Keep a human in the loop for actions involving high risk or sensitive data.
- Make validation and logging visible, so that it can be checked afterwards what happened.
The connection with verifiable control
These principles align with the way a verification console such as I am Vera is set up. Vera is not a chatbot and not a language model of its own, but a verification layer around working with AI. In the architecture, pre-processing and anonymisation take place on EU infrastructure, and the workflow is designed to send only anonymised content to the selected AI models. If the privacy check fails, nothing is forwarded.
That set-up touches on what OWASP describes as separation, control and minimal access rights. By making verification steps visible and weighing multiple models against each other, Vera can help to gain more insight into what underpins an AI answer. Anyone who wants to view and edit documents within the same secure environment does so via Vera Office; the Semantic Privacy Shield describes the pre-processing on EU infrastructure.
The sober reading remains important: no single layer offers certainty about correctness or truth, and no measure fully eliminates the risk of misleading instructions. What is possible is to make control more transparent. The professional final judgement always remains with the user. The combined signals from NIST, Google, arXiv and OWASP make one thing especially clear: in 2026, external content deserves suspicion by default, and defensive layers are no longer a luxury.