What Is Indirect Prompt Injection and Why Your RAG Pipeline Is Vulnerable

When your LLM reads a document, it does not just extract information. It follows instructions.

That distinction — invisible in most architecture diagrams — is the root cause of indirect prompt injection: one of the most exploited attack vectors in production AI systems today. If your application uses Retrieval-Augmented Generation to give the model access to internal documents, customer data, web content, or third-party tool outputs, you have exposed yourself to a class of attack that most teams have not fully modelled.

This article explains how indirect prompt injection works, why RAG architectures are structurally vulnerable, what real-world attacks look like, and what engineering teams can do to reduce the risk without abandoning the architecture.

Direct vs. Indirect Prompt Injection: What Is the Difference?

Most developers who have thought about LLM security have encountered the concept of prompt injection — a user crafting input designed to override the model’s system instructions. That is the direct variant: the attacker has access to the model’s input surface and abuses it.

Indirect prompt injection is different in a critical way: the attacker does not need access to the model at all.

Greshake et al. formalised this distinction in a 2023 paper presented at the ACM Workshop on Artificial Intelligence and Security, titled Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection.¹ Their core insight was that LLM-integrated applications routinely blur the boundary between data and instructions. When a model retrieves content from the web, reads a document from a knowledge base, or processes the output of a tool call, it does so using the same mechanism — attention — that it uses to interpret instructions. There is no native distinction at the model level between “this is data to be summarised” and “this is an instruction to be followed.”

An attacker who can influence the content the model retrieves has therefore found a path to influence what the model does, without ever sending a single message to the application directly.

The Greshake et al. paper demonstrated this against real production systems at the time of publication, including Bing Chat and GitHub Copilot. That was 2023. The attack surface has grown substantially since.

How RAG Pipelines Extend the Attack Surface

Retrieval-Augmented Generation has become the dominant architecture for giving LLMs access to current and domain-specific knowledge. A RAG pipeline typically works as follows: a user query triggers a retrieval step that fetches semantically relevant documents from a vector database or search index, those documents are inserted into the model’s context window, and the model generates a response grounded in the retrieved content.

The RAG architecture is exactly what indirect prompt injection requires: a pathway through which adversary-controlled content can enter the model’s context without passing through the application’s input validation layer.

A 2026 comprehensive survey on RAG security identified four primary attack families targeting this architecture:²

Corpus poisoning attacks involve injecting adversarial documents into the knowledge base itself. The attacker does not need write access if the knowledge base is populated from external sources — web scraping, uploaded user files, third-party data feeds, email ingestion, or public document repositories. A single poisoned document that is retrieved on a high-frequency query can silently redirect model behaviour on every invocation of that query.

Retrieval manipulation attacks exploit the semantic similarity function used to retrieve documents. By crafting content that scores highly on cosine similarity to target queries — without the similarity being genuine — attackers can ensure their payload is consistently retrieved above legitimate documents. Research has demonstrated this using surrogate models to optimise adversarial passages specifically for retrieval.²

Embedding inversion attacks treat the vector embedding itself as sensitive data. Embeddings generated from proprietary documents can be partially reversed to recover the original text, constituting a data leakage pathway that is independent of the model’s output behaviour.²

Data extraction attacks use the model’s instruction-following behaviour against it. An instruction-tuned model operating in a RAG context can be induced to include verbatim content from the datastore in its responses — content the user was never authorised to see — through carefully crafted prompts that exploit the model’s tendency to be helpful.

The OWASP GenAI Top 10 (2025) lists prompt injection as LLM01:2025 — the highest-priority risk for LLM applications — and explicitly notes that neither RAG nor fine-tuning eliminates the vulnerability.³ Grounding a model in retrieved content does not make that content safe. It makes the attack surface larger.

What Agentic Systems Change

In a standard RAG application, the model generates text. A human reads the output and decides what to do with it. Even if the model is injected, the blast radius is bounded by the human’s attention and judgment.

Agentic systems remove that boundary.

When a model is given tools — the ability to send emails, write to databases, call external APIs, execute code, or coordinate with other agents — a successful injection does not produce a misleading response. It produces an action. The attacker’s payload becomes an instruction that the model executes with whatever permissions the agent holds at that moment.

A 2025 paper studying prompt infection in multi-agent systems demonstrated that compromised agents can propagate malicious instructions to peer agents in the pipeline, even when agents do not share all communications explicitly.⁴ The researchers showed this as a five-stage kill chain — initial access via a poisoned document, privilege escalation through tool call chaining, persistence by writing to shared memory or knowledge bases, reconnaissance of accessible resources, and lateral movement to other agents.

The Promptware Kill Chain paper, published in early 2026, documented how this attack pattern evolved through 2024 and 2025 into a sophisticated lifecycle comparable to traditional malware campaigns — without requiring any executable code.⁵ The payload is natural language. The vector is the knowledge base.

For teams operating RAG pipelines with tool-calling capabilities — and this is now the majority of enterprise AI deployments — the threat model must account for this expanded blast radius.

Real Incidents: From Theory to Production

The concern here is not theoretical. The following incidents were documented in the research literature and public security reporting through 2024 and early 2025.

Slack AI (August 2024): Researchers demonstrated a four-stage attack chain against Slack AI. Adversarial instructions embedded in messages in accessible channels were retrieved when a user queried Slack AI. The model, following the embedded instruction, extracted content from private channels the user had legitimate access to — and formatted it as a tool output, making the exfiltration indistinguishable from a legitimate response. The Promptware Kill Chain paper categorised this as the first widely documented case of RAG-dependent persistence in an enterprise productivity platform.⁵

Microsoft 365 Copilot (2024): Security researchers demonstrated ASCII-encoded prompt injection attacks against M365 Copilot operating across the Microsoft 365 document ecosystem. By embedding obfuscated instructions in SharePoint documents and emails, attackers could redirect Copilot’s behaviour when it processed those documents as context — including inducing it to forward sensitive content to external endpoints through legitimate-looking tool invocations.⁵

ZombAI and multi-agent propagation (2024–2025): Research published in the Promptware Kill Chain paper documented cases where injected agents in multi-agent pipelines maintained persistent influence across sessions by writing malicious instructions into shared knowledge bases — a form of AI-resident persistence with no direct analog in traditional malware taxonomy.⁵

These are not edge cases from research labs. They are incidents against production systems from enterprise vendors with dedicated security teams.

The Trust Classification Problem

The root cause of RAG injection vulnerability is a classification failure: the system treats all content in the model’s context window with the same level of trust, regardless of where that content originated.

A user’s verified query and an adversarially crafted document retrieved from an external web page occupy the same context window. The model has no native mechanism to apply different processing rules to content from different trust tiers. Whatever instruction-following behaviour the model exhibits, it exhibits uniformly across all context — because that is how attention-based language models work.

The most promising architectural response to this problem is explicit trust classification — enforcing different processing paths for content of different provenance. The Prompt Flow Integrity (PFI) framework, evaluated in 2025, formalised this as a security property: data-flow constraints that identify untrusted data, enforce least privilege on what that data can cause the model to do, and validate any data flows before they result in consequential actions.⁶

The PFI evaluation reported that enforcing these constraints on a ReAct agent benchmark reduced attacked task completion rate from 57.99% to 0.00% on the AgentDojo evaluation suite. That is a complete elimination of successful attacks in the benchmark — not a marginal improvement.⁶ The architecture change, not a better model, produced this result.

This matters for practitioners: the security improvement available through architectural controls significantly exceeds what is achievable through model selection or prompt hardening alone.

A Practical Hardening Framework for RAG Pipelines

The following controls are grounded in published research and can be implemented by engineering teams without requiring specialised AI security expertise. They are presented in order of implementation priority, not alphabetically.

1. Classify all context by trust tier before it enters the model

Every piece of content in the model’s context window should be labelled by trust level at the time it enters. Content from verified system instructions occupies the highest trust tier. Content retrieved from external sources — web pages, uploaded files, emails, third-party tool outputs — occupies a lower tier. Content from user input occupies a tier determined by authentication state.

This classification does not prevent the model from reading lower-trust content. It constrains what the model is permitted to do based on what it has read. A response grounded in lower-trust retrieved content should not be able to trigger tool calls that require higher-trust authorisation.

2. Enforce least privilege on tool calls triggered by retrieved content

If an agent’s tool-calling behaviour can be triggered by injected instructions in retrieved content, the damage from a successful injection is bounded only by the agent’s permission scope. Reduce that scope.

Per-task scoping — granting the agent only the permissions required for the current task, not ambient permissions inherited from the session — limits the blast radius of any successful injection. The GrantBox study found that current LLMs cannot reliably police their own privilege usage under adversarial conditions.⁷ Permission enforcement must happen at the infrastructure layer, not the model layer.

3. Sanitise and validate retrieved content before insertion

Before inserting retrieved documents into the model’s context, apply input sanitisation appropriate to the risk level of the source. For high-risk sources (user-uploaded files, external web content, emails from unknown senders), this includes:

• Stripping known injection pattern prefixes (instructions targeting common system prompt formats)
• Normalising encoding to prevent ASCII obfuscation attacks of the type demonstrated against M365 Copilot
• Truncating content to the minimum length required to answer the query (shorter retrieved content = smaller attack surface)
• Applying a secondary classification pass using a lightweight, sandboxed model to flag suspicious instruction patterns before the primary model processes the content

No sanitisation approach is complete — the research on defensive failures shows that ML-based detectors can be bypassed by optimisation-based adversarial attacks.⁸ Sanitisation reduces risk; it does not eliminate it. Combine with structural controls.

4. Separate the retrieval index from the write path

A compromised agent that can write to the same knowledge base it retrieves from can establish persistence by poisoning its own retrieval source. Keep the write path and the read path structurally separated: the retrieval index should be read-only from the model’s perspective, with writes handled by a separate, authenticated pipeline that includes content validation before indexing.

This control directly addresses the RAG-dependent persistence attack pattern documented in the Promptware Kill Chain research.⁵

5. Add retrieval audit logging with anomaly detection

Logging retrieval queries and retrieved document hashes is the forensic foundation for identifying injection attacks after the fact — and for detecting them before they complete. Anomalous retrieval patterns (high-frequency retrieval of specific documents that do not correspond to user query patterns, retrieval of documents from recently added or modified sources, tool calls that follow retrieval from external sources) can be flagged for review.

Without retrieval-level logging, injection attacks are effectively invisible. The application appears to function normally; the exfiltration or manipulation occurs silently.

6. Implement a human review gate for consequential actions

For actions with significant real-world consequences — sending external communications, writing to databases, calling financial APIs, modifying files — introduce a human approval step between the model’s proposed action and its execution. This is not a limitation on agentic capability for routine tasks. It is an architectural acknowledgement that an agent operating on potentially injected context should not execute high-consequence actions autonomously.

The OWASP Agentic Top 10 (December 2025) identifies the absence of this pattern — excessive agency without human oversight — as one of the highest-priority risks in agentic AI deployments.³

7. Test your pipeline against injection scenarios before launch

Most teams test RAG pipelines for retrieval quality and answer accuracy. Few test them for injection resistance. Before a RAG system goes to production, run adversarial evaluations:

• Can an injected instruction in a retrieved document redirect the model’s response?
• Can an injected instruction in a retrieved document trigger a tool call?
• Can an injected instruction cause the model to include content from other retrieved documents in its output?
• Does sanitisation catch encoded variants of the same injection (base64, ASCII, Unicode lookalikes)?

The AgentDojo benchmark provides a structured evaluation framework for the first two questions.⁶ Red-teaming with domain-specific injection scenarios, tailored to your knowledge base’s content types, should complement automated benchmark evaluation.

The Gap Between Model Safety and System Security

A frequently observed misconception among teams deploying RAG applications is that using a safety-trained model addresses injection risk. It does not.

Safety training is primarily designed to prevent models from producing harmful content in response to direct user requests. It is not designed for adversarial instruction injection through retrieved content — a threat that was largely theoretical at the time most safety training datasets were constructed, and one that operates through a different mechanism.

The empirical evidence supports this. A 2025 study evaluating 17 state-of-the-art models — including the most safety-trained frontier models — found that 94.1% exhibited vulnerability to at least one attack vector across direct injection, RAG backdoor attacks, and inter-agent communication.⁹ Models that resisted direct injection were frequently vulnerable through the RAG pathway.

Model safety and system security are related but distinct properties. A safe model running in an insecure system architecture remains insecure. The architectural controls described above are necessary regardless of which model is in use.

Connecting This to the Broader Threat Landscape

Indirect prompt injection through RAG pipelines is not a standalone vulnerability. It is the most common initial access vector for a broader class of agentic AI attacks.

The attack pattern documented in the Promptware Kill Chain research — poisoned content → initial access → privilege escalation through tool chaining → persistence → lateral movement — mirrors the MITRE ATT&CK kill chain for traditional software exploitation.⁵ The difference is the medium: natural language instead of executable code, a vector database instead of a filesystem, tool permissions instead of OS-level privileges.

The controls that reduce RAG injection risk — content trust classification, least privilege tool execution, structural separation of read and write paths, retrieval audit logging, human review for consequential actions — are not AI-specific inventions. They are established security engineering principles applied to a new attack surface.

That framing matters for teams making the case for security investment. RAG injection hardening is not a speculative research exercise. It is the application of defence-in-depth to a production system with a documented attack history.

If you are deploying a RAG-based system in 2026 and have not modelled this attack surface, the question is not whether the risk exists. It is whether you will find out about it from your own audit or from an incident.

What This Means for Your Team

If you are an engineering director or CTO with a RAG pipeline in production or in development, the practical questions to ask are:

• Have we classified every content source that enters our model’s context window by trust level?
• Can content retrieved from external or user-controlled sources trigger tool calls? If so, with what permissions?
• Do we have retrieval-level logging that would let us reconstruct an injection attack forensically?
• Have we run adversarial injection tests against our retrieval pipeline before launch?
• Is there a structural separation between the read path (retrieval) and the write path (knowledge base updates)?
• Do we have human review gates on any consequential actions the agent can take?

If the answers to any of these are unclear, your RAG pipeline’s trust boundary is not explicit. That is the starting point for most production deployments today — and the starting point for most avoidable incidents.

References

Daljit Singh is a Director at an IT consulting firm specialising in AI, security, and full-stack development, with a security-first engineering approach. He is currently reading for an MSc in Cybersecurity at IU International University. His work sits at the intersection of applied AI systems and adversarial security — building production systems that take the threat model seriously from day one. Book a free 30-minute consultation to review your RAG pipeline’s security posture.