Indirect prompt injection: poisoned RAG, emails, and tool data

Indirect prompt injection (sometimes called cross-prompt injection, XPIA) is the variant where the malicious instruction is not typed by the user — it is hidden in content the AI system later retrieves and reads as data: web pages, emails, documents, database rows, or tool output (Microsoft Learn — AI prompt injection). Greshake et al. formally defined it in 2023 as attacks "Not What You've Signed Up For" (arXiv:2302.12173). It is the higher-impact sibling of direct injection and the dominant way production RAG and agent systems get compromised in 2026. See also what prompt injection is and AI agent security risks.

1. Why indirect injection is the dangerous case

In direct injection the attacker is also the user, so the blast radius is one session. In indirect injection the attacker never talks to the model — they poison a data source the model will read later. Any user who fetches that content becomes the victim, with their own permissions (Pentest Testing Corp — Indirect Prompt Injection in RAG).

The model's trust boundary is fuzzy. LLMs are trained on text that mixes instructions and data; they have no hard distinction between "system says X" and "retrieved content says X" the way a process boundary works in classical computing.

This bypasses every control focused on the chat layer — input sanitization, rate limiting, session management — because the payload enters through the retrieval mechanism, not the user channel.

2. RAG poisoning: the retrieval corpus is the attack surface

Retrieval-Augmented Generation (RAG) assumes retrieved context is safe to inject into the prompt — an assumption most deployments never test (Eresus — LLM and RAG data poisoning). If an adversary can get content into the knowledge base — a support ticket, a product review, a scraped page, a synced doc — they can embed an instruction the model later obeys.

A documented pattern: an attacker submits a "support ticket" that gets ingested into the vector store. When a future user asks an unrelated question, retrieval pulls the poisoned ticket as context, and the LLM treats its embedded directive as a real instruction — e.g. steering customers to a phishing portal (rag-prompt-injection-demo, OWASP LLM01). Three things make it dangerous:

  • No chat access needed — poison email systems, ticket queues, scraped docs, or user-generated vector DBs.
  • Persistent — the poison survives until the document is removed and the index rebuilt.
  • Scales automatically — one poisoned chunk affects every query that retrieves it, across every user.

3. Adversarial-passage and data-poisoning techniques

Beyond natural retrieval, attackers can optimize payloads to be retrieved on purpose. Zhong et al. (2023) showed "Poisoning Retrieval Corpora by Injecting Adversarial Passages" (arXiv:2310.19156): given a target query and embedding model, craft a passage that ranks highly for that query regardless of its real content, so the poison activates only on targeted queries and is harder to detect. This maps to OWASP LLM04 (Data and Model Poisoning) at inference time, and to multiple MITRE ATLAS techniques (RAG Poisoning, Retrieval Content Crafting, LLM Data Leakage).

4. Defences (layered, not perfect)

No single control stops indirect injection, but a stack makes it rare and detectable (Pentest Testing Corp):

  1. Treat all retrieved content as untrusted — never let retrieved text override system policy by default.
  2. Spotlighting / delimiting — clearly mark retrieved data as data, separate from instructions (e.g. canary tokens, structural separators).
  3. Content review before indexing — scan ingested documents for embedded directives; constrain write access to the corpus.
  4. Output filtering & DLP — catch exfiltration attempts, secret patterns, and instruction-following of retrieved text.
  5. Network allowlists — stop the agent from calling attacker-controlled endpoints.
  6. Cross-tenant isolation — bind retrieval to a single tenant/scope so one user's poison can't reach another.

5. How AgentRedTeam surfaces it (honestly)

AgentRedTeam runs automated indirect-injection simulations — poisoned-document, poisoned-email, and poisoned-tool-output fixtures — and surfaces likely gaps in a prioritized report. It does not guarantee finding every poisoned source, and it is not a substitute for a formal security audit or penetration test. Use it to probe your retrieval boundary before attackers poison it. Also see the LLM red-teaming guide.