Guides › Secure RAG › Indirect prompt injection

Indirect Prompt Injection in RAG Pipelines

Hunter Moore, Founder and CTO · Updated August 4, 2026

Indirect prompt injection places attacker instructions inside content the model will retrieve, so the model reads them as part of its context and acts on them. The attacker never touches the victim's prompt. RAG is the main delivery channel, because inserting third-party text into a trusted context is precisely what RAG is for.

At a glance
  • The attacker never touches the prompt. Instructions are planted in content the system will retrieve, and a different user triggers them later.
  • Any writable source that feeds the index counts. Tickets, wikis, shared mailboxes, CRM notes and vendor PDFs, including sources owned outside the organization.
  • Tool access sets the blast radius. A read-only assistant returns a manipulated answer. An assistant with tools can be steered into an exfiltration path.

How is it different from prompt injection?

Direct prompt injection is a user typing adversarial instructions into the chat box, affecting their own session. Indirect injection puts those instructions into content the system retrieves later, so a different user triggers them without knowing. The attacker and the victim are different people, and the payload waits.

Greshake and colleagues described the class in Not what you've signed up for in 2023, showing that content pulled in at inference time can hijack an application without the attacker touching the user's input. OWASP lists Prompt Injection as LLM01 in its 2025 Top 10 for LLM Applications, its highest-ranked entry.

HOW INSTRUCTIONS REACH A MODEL WITHOUT TOUCHING THE PROMPT 1 Attacker writes into a source your pipeline already indexes: a support ticket, a shared mailbox, a public page, a wiki comment 2 Ingestion accepts the text is content, not a command, as far as the parser is concerned 3 Retrieval picks it an unrelated user question matches it on similarity, which the attacker tuned for 4 Context is assembled the instructions now sit beside the system prompt, in the same channel 5 The model acts summarises restricted context into the reply, or calls a tool it was allowed to call The attacker never sees your prompt, your model or your users. They only need write access to something you index. Every writable source that feeds the corpus is therefore part of the attack surface, including ones owned by other teams.
Indirect prompt injection is a delivery problem before it is a model problem. Retrieval is the delivery channel, which is why the corpus is where the control belongs.

Where does the injected content come from?

Any repository users can write to that also feeds your index. A ticketing system where customers file issues. A wiki open to contractors. A shared mailbox. A CRM notes field. A vendor PDF.

In many deployments that set includes people outside the organization. If a vendor can file a support ticket and tickets are indexed, that vendor can write to your model's context.

Common mistake

Reviewing a document visually tells you nothing about what the extractor pulled out of it. White text on a white background, document metadata, image alt attributes and comment fields all survive text extraction and reach the model the same way body copy does.

What can an injection actually do?

It depends on what the assistant is allowed to do. Tool access is the difference between a manipulated answer and an exfiltration path.

A read-only assistant

the blast radius is one response

  • The injection produces a wrong or manipulated answer.
  • That matters where answers drive decisions.
  • The consequence stops at the single reply.

An assistant with tools

the injection takes actions

  • Instructions can tell the model to search the index for credentials and fold them into a summary.
  • Instructions that trigger an outbound connector turn a content problem into a data transfer.
  • A retrieved document becomes an untrusted party issuing instructions to something that holds privileges.

Why do classifiers not solve it?

Prompt-injection classifiers score text against learned patterns of adversarial phrasing. They catch obvious attempts and raise the cost of casual ones, which is worth something.

An attacker gets unlimited attempts to find phrasing that scores as benign. The classifier gets one pass.

That asymmetry does not close with a better model, because the classifier is trying to separate instruction from information in text where the distinction is genuinely ambiguous. Run one as a layer in a stack that assumes some fraction gets through.

What mitigations actually hold?

Structural separation first. Retrieved content should be marked as data, kept syntactically distinct from instructions, and treated as untrusted for the life of the request. This does not make the model immune, and it removes the easiest attacks.

Then authorization. Tool calls that a retrieved document appears to have triggered deserve a different authorization path than tool calls the user requested. If the model wants to call an outbound connector immediately after reading an untrusted document, that is the moment for a confirmation step rather than a log entry.

Then provenance. Log which chunks entered the context for which response, so that when something goes wrong you can identify the document that caused it. Without that record, an injection incident is unattributable.

And narrow the corpus. Content from sources that arbitrary external parties can write to deserves separate treatment from content authored internally. Indexing everything and defending at the model is the harder version of the problem.

MITIGATIONS, AND THE HONEST LIMIT OF EACH Mitigation Sits at Catches Misses Scan content at ingestion Ingestion Hidden text in metadata, alt attributes and comments, plus known instruction patterns. Novel phrasing, and anything that arrives after the scan was tuned. Separate instructions from data Prompt assembly Retrieved text being read as a command in the common case. Models still attend to persuasive text wherever it sits. Authorize tool calls separately Action boundary A retrieved document causing a write, a send or an external fetch. Disclosure that needs no tool, where the answer is itself the exfiltration. Log provenance, cap blast radius Retrieval and runtime Nothing, in advance. Nothing. It decides what an injection that worked is able to reach. No row here is a solution. The first three raise the cost of an attempt; the fourth decides what a success is worth. Assume some injections get through and size the permissions of the agent accordingly.
Layered mitigation with the limits stated. The controls that reduce blast radius matter most, because the classifier will eventually be wrong.

How does this relate to poisoning?

They overlap at the edges. Injection targets one response by placing instructions in retrieved content. Data poisoning targets the system's behaviour by corrupting what it learns from or retrieves. Content injected into a retrieval corpus that persists and shapes many answers behaves like poisoning, which is why NIST's 2025 adversarial ML taxonomy keeps the categories distinct but adjacent.

The practical difference

Reversibility. Correct the source document and reindex, and retrieval-side injection ends. Poisoning that reached model weights does not.

Frequently asked questions

Can we detect injection attempts in our corpus?

Partially, and scanning at ingestion is worth doing because it is cheap and catches the unsophisticated cases. Treat it as filtering rather than prevention. Hidden text in metadata and alt attributes is the specific thing to check for, since it is invisible to a human reviewing the document.

Does a system prompt telling the model to ignore instructions in documents work?

Not reliably. It helps against naive payloads and is trivially bypassed by ones written to expect it. Instructions to a model are a preference, not a boundary. Anything you need to be a boundary belongs outside the model.

Is this a problem if our assistant is read-only?

Smaller, but not absent. A read-only assistant can still be made to produce a misleading answer, and if people act on those answers the consequence is real. It also tends not to stay read-only, because tool access is usually the next feature request.

Does indirect injection get more dangerous with agents?

Substantially. Every tool an agent holds is a capability an injected instruction can attempt to invoke. Assess the risk against what the agent can do, not against how likely an injection is, because the second question is not one you can answer confidently.

Sources

Greshake and colleagues, Not what you've signed up for, 2023. · OWASP, Top 10 for LLM Applications, 2025. · NIST, adversarial machine learning taxonomy, 2025.