RAG Poisoning: Security Risks When Retrieved Content Becomes an Agent's Context

RAG poisoning is SSA descriptive wording for a security-relevant change to the state a retrieval-augmented agent treats as ground truth: the documents, messages, or records indexed in a knowledge base or vector store that retrieval loads directly into the model's context on a live query. The defining cause is adversarial. A retrieval system that surfaces a genuinely low-quality or outdated document is a data-quality problem, not this working term.

What it is

The defining object is the retrieval corpus and the index built over it: any document store, message archive, wiki, ticket system, or vector database an agent queries at answer time and whose top matches are inserted into context without the same scrutiny applied to a direct user instruction. The defining cause is a party who can place content into that corpus, either by writing to it directly or by getting the pipeline to ingest it, and shapes that content to rank highly for a target query and to steer or redirect the agent once retrieved. The defining consequence is that the agent's answer, belief, or next tool call changes because it trusted retrieved content as fact, not because the user's own request changed.

This differs from the two other context-poisoning paths already documented on this site by when and how the untrusted content becomes operative. Compromised summaries target what a compactor keeps or drops from an agent's own session history. Persistent memory injection targets what an agent writes into its own long-term memory through a memory-write tool call. RAG poisoning targets a corpus that is usually external to the agent's own state, often shared across many users and many sessions, and re-injected fresh on every query that retrieves it rather than promoted once and then read from memory.

What it is not

A retrieval system returning a genuinely outdated, low-quality, or irrelevant document with no adversary involved — a data-quality or relevance-tuning problem, not this working term.
Model hallucination that occurs with no poisoned document in the retrieved set.
Direct prompt injection carried purely through user-supplied chat text with no document store, index, or retrieval step in the chain, covered by agent state attack's broader definition instead.
Training-data poisoning that changes model weights, which is a different attack surface than a runtime retrieval corpus.
Reproducible attack payloads or step-by-step exploitation instructions.

In scope

Content deliberately written or planted so it ranks highly for a target query and steers the answer the retrieval-augmented model generates.
Ingestion paths that pull untrusted external material, such as email, public channels, or shared drives, into a corpus an agent later queries as if it were internal knowledge.
Hidden instructions embedded in a retrieved document that the model reads as an operating instruction rather than as retrieved data.
Propagation where one poisoned document affects every user and every session whose query happens to retrieve it, including sessions with no relationship to the one that planted it.
Defensive controls for corpus provenance, ingestion gating, retrieval-time inspection, and recovery.

Target state, trust boundaries, and impact

The target state is the indexed corpus itself and, transitively, the context window of any session whose query retrieves a poisoned entry. The trust boundary sits at retrieval: the moment a similarity search pulls a passage out of storage and inserts it into the prompt the model reads next. Most RAG pipelines do not re-apply the scrutiny given to a direct user instruction at that moment, because the passage arrives labeled as "retrieved knowledge" rather than as untrusted input.

Three preconditions are usually present. First, an adversary needs a position to write to the corpus, either directly, through an ingestion pipeline that indexes email, tickets, or shared documents automatically, or through a public or semi-public source the pipeline trusts by default. Second, the retrieval step must surface that content for a query the attacker can predict or influence, most often by embedding the anticipated question directly in the planted text so it ranks well on similarity search. Third, the model must act on the retrieved passage as fact or instruction rather than as one unverified source among several. Resulting effects include false or attacker-chosen answers presented with the appearance of grounded, cited authority; hidden instructions that redirect a subsequent tool call toward exfiltration or an unauthorized action; and, in a multi-tenant or shared-workspace corpus, compromise reaching every user whose query happens to retrieve the same poisoned entry.

Persistence

A single poisoned passage is re-read on every query that retrieves it for as long as it stays in the index, which places this working term's persistence between session-scoped context poisoning and fully durable memory. Nothing needs to be promoted, saved, or written to a separate memory store the way persistent memory injection requires: the corpus itself is the durable object, and any session, including sessions belonging to users the attacker never interacted with, inherits the poison the moment its query happens to match. In a shared enterprise knowledge base, a single document can therefore reach shared-system persistence without ever touching an individual agent's own memory or configuration.

What the research and documented cases establish

Zou, Geng, Wang, and Jia formalized the attack as PoisonedRAG, a knowledge-corruption attack that injects a small number of adversarial texts into a RAG knowledge database to make the system return an attacker-chosen answer for an attacker-chosen question. Their evaluation reported a 90% attack success rate when injecting five malicious texts per target question into a knowledge database containing millions of texts, and found that several existing defenses were insufficient against it (arXiv 2402.07867, v1 2024-02-12, v3 2024-08-13, accepted at USENIX Security 2025). This article does not reproduce the optimization technique the paper describes; it treats the reported success rate as evidence that a small, targeted set of planted documents can reliably dominate retrieval for a chosen query, not as a benchmark for any specific production system.

The technique reached production systems the same year. Zenity Labs published "RAG Poisoning: All You Need is One Document" on 2024-08-03, demonstrating that a single file shared inside a Microsoft 365 tenant, crafted so its content matches an anticipated question, could cause Microsoft 365 Copilot to answer that question with attacker-chosen false content, attributed with apparent confidence, once the file was automatically indexed for retrieval (Zenity Labs, RAG Poisoning: All You Need is One Document). The same researchers presented the broader technique, including RAG poisoning via indexed email, at Black Hat USA 2024 under the title "Living off Microsoft Copilot."

Independently, a security researcher publishing as PromptArmor disclosed on 2024-08-20 that Slack AI's retrieval system indexed messages from public channels workspace-wide, including channels a target user had never joined. An attacker who posted crafted instructions into such a channel could cause Slack AI to retrieve that content alongside a victim's genuine query and follow the attacker's embedded instruction, in the disclosed case rendering a link that exfiltrated an API key the victim had shared in a private channel (PromptArmor, Data Exfiltration from Slack AI via Indirect Prompt Injection). Slack patched the reported issue and stated it had no evidence of unauthorized access to customer data at the time of disclosure.

Cohen, Bitton, and Nassi went further, showing that a poisoned retrieval corpus can propagate on its own. Their paper, "Here Comes the AI Worm: Unleashing Zero-click Worms that Target GenAI-Powered Applications," demonstrates a self-replicating adversarial prompt, which the authors name Morris-II, that spreads across a GenAI email assistant ecosystem by getting each compromised application's RAG-indexed output to poison the next application's retrieval corpus in turn, requiring no click from any victim (arXiv 2403.02817, v1 2024-03-05, v2 2025-01-30). The same paper proposes a detection guardrail, Virtual Donkey, reporting a true-positive rate of 1.0 and a false-positive rate of 0.015 against the worm's variations in their test setup. This article does not reproduce the propagation technique; it is cited as evidence that a poisoned corpus is not necessarily a contained, single-system incident.

Detection: observable signs

A retrieved passage's content, once traced to its source document, was authored or modified by a party with no legitimate reason to answer the query it was retrieved for.
The agent's answer states a fact with high apparent confidence that contradicts an independently verified source, while citing a retrieved document as its basis.
A single document or message ranks as the top retrieval result for an unusually broad or specific range of unrelated queries, consistent with content engineered to match anticipated questions rather than to answer one naturally.
Retrieved content contains directive language addressed to the model or the agent, rather than declarative content addressed to a human reader.
The same questionable claim or instruction appears in answers given to unrelated users or sessions that never interacted with each other, only with the same corpus.
A newly ingested document produces a measurable shift in the agent's retrieved answer to a previously stable, verified query.

Useful telemetry includes the source and ingestion timestamp of every indexed document, the query-to-passage similarity score and rank at retrieval time, a record of which passages were actually inserted into which session's context, and a way to trace an answer back to the specific documents that produced it. Without that last piece, an incident review cannot tell which corpus entries influenced a given user's session.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders, not a standard requirement or a measured effectiveness ranking, except where a specific published result is noted.

| Control | Transition it interrupts | Applicability | Residual risk and verification | | --- | --- | --- | --- | | Ingestion-time provenance and access gating | Untrusted or public content entering a corpus the agent treats as internal knowledge | Any pipeline that auto-indexes email, public channels, tickets, or shared drives | A previously trustworthy source can still be compromised or misused; re-verify source trust rather than trusting it permanently once granted. | | Retrieval-time content segregation | A retrieved passage read as an instruction rather than as one unverified source | Any agent that inserts retrieved passages directly into the model's operating context | Bypassable by content engineered to mimic the segregation markers; test with payloads that target the separation mechanism itself, not only the model. | | Outlier and rank-anomaly monitoring on retrieval | A small number of planted documents dominating retrieval for a target query, the mechanism PoisonedRAG's reported 90% success rate depends on | Corpora large enough that a handful of documents should not plausibly dominate a broad query set | Effective against the documented planting pattern, not against a single well-placed document matched to one narrow query; pair with source-count checks per answer. | | Answer-to-source traceability | A false or steered answer reaching a user with no way to audit which document produced it | Any deployment where answers are treated as authoritative by their recipient | Traceability enables audit and recovery; it does not itself stop a poisoned answer from being generated and read before review. | | Cross-session propagation tracing on confirmed findings | A single poisoned document's influence being underestimated once discovered | Any shared or multi-tenant corpus | Requires the query-to-passage logging above; without it, propagation cannot be reconstructed after the fact. |

Prevention should treat every ingestion path into a queryable corpus as a trust decision, not a storage operation, and should re-apply that decision when a source's trust level could plausibly have changed. Detection should watch retrieval behavior, not only final answers, since a single planted document can produce plausible-looking output on any one query while still being anomalous across the query set it was engineered to dominate. Containment should remove or quarantine a confirmed-poisoned document from the live index immediately, since every later query against the same corpus is a fresh exposure, not a one-time event the way a single compromised session summary can be. Recovery should re-index from a verified-clean corpus snapshot where one exists, and should treat every answer traceable to the poisoned document as suspect until reviewed, not only the answer given to the user who first reported the problem.

Boundaries with similar concepts

Compromised summaries and context compaction targets the artifact a compactor produces from an agent's own session history; RAG poisoning targets an external or shared corpus the agent queries, and the two can compound when a compacted summary is itself written back into a retrieval index. Persistent memory injection requires an agent's own memory-write tool call to promote content into durable state; RAG poisoning requires no such call, since the corpus is already durable by design and retrieval alone is sufficient to reintroduce the poisoned content on every matching query. Shared state poisoning in multi-agent systems covers blackboards and handoff payloads written by one agent for another to read directly; a retrieval corpus overlaps that pattern once multiple agents query the same index, but stays within this narrower path when the corpus is queried by single-agent sessions rather than passed hand to hand between agents. MCP tool poisoning's tool-result path is adjacent: a tool call that performs a live web or database lookup and returns adversarial content is functionally a one-off retrieval, though it is not backed by a persistent index the way a RAG corpus is.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | arXiv 2402.07867 (v3, 2024-08-13) | PoisonedRAG | Formal knowledge-corruption attack methodology and reported 90% attack success rate; direct research evidence for the retrieval-domination mechanism this article describes without reproducing. | | arXiv 2403.02817 (v2, 2025-01-30) | Morris-II; ComPromptMized; Virtual Donkey | Documented self-replicating propagation across RAG-indexed applications, plus a published detection guardrail with reported true- and false-positive rates. | | Zenity Labs (2024-08-03) | RAG Poisoning: All You Need is One Document | Documented real-world instance against Microsoft 365 Copilot's retrieval indexing. | | PromptArmor (2024-08-20) | Data Exfiltration from Slack AI via Indirect Prompt Injection | Documented, patched production instance of workspace-wide retrieval indexing enabling cross-user exfiltration. | | OWASP Top 10 for LLM Applications 2025 | `LLM08:2025 Vector and Embedding Weaknesses` | Standard risk category covering embedding poisoning and retrieval-layer weaknesses this article's target state overlaps with. | | OWASP Top 10 for Agentic Applications 2026 | `ASI06 Memory & Context Poisoning` | Broader agentic risk category for malicious context or memory state. | | MITRE ATLAS v2026.06 | `AML.T0070 RAG Poisoning` | Attacker-behavior classification naming this technique directly; this article is a defender-side treatment of the same target state, not a restatement of ATLAS's own technique page. | | Agent State Attack | RAG poisoning | SSA descriptive phrase bundling the above under one target state, not attributed to the sources above. |

Related terms

Agent state attack: the SSA Working Term this article's scope sits under.
Compromised summaries and context compaction: the adjacent context-surface working term for an agent's own session history rather than an external corpus.
Persistent memory injection: the adjacent working term for content promoted into an agent's own durable memory through a write tool, rather than reloaded fresh from an external index on every query.
Shared state poisoning in multi-agent systems: the working term for state more than one agent reads as trusted, overlapping this one when a corpus is queried by multiple agents.
MCP tool poisoning: the adjacent working term for a single tool call's result rather than a persistent, repeatedly queried index.
OWASP and MITRE ATLAS crosswalk: the broader framework mapping this entry draws its standards references from.

FAQ

Is "RAG poisoning" an official standard term?

Partially. MITRE ATLAS v2026.06 names `AML.T0070 RAG Poisoning` directly, and OWASP's Top 10 for LLM Applications 2025 covers the same target state under `LLM08:2025 Vector and Embedding Weaknesses`. This article's scope, framing the corpus itself as a distinct agent-state surface alongside compaction, memory, and shared state, is SSA editorial organization; cite the ATLAS and OWASP identifiers to their own owners, not to this site.

Does this only affect systems with a dedicated vector database?

No. The documented Slack AI and Microsoft 365 Copilot cases both poisoned retrieval indexes that most users would not describe as a "vector database" in the standalone sense, an internal message index and a tenant document index respectively. Any retrieval mechanism that ranks stored content by relevance to a query and inserts the top matches into an agent's context is in scope, regardless of the underlying storage technology.

Can a small, well-placed document really beat a knowledge base with millions of legitimate entries?

The PoisonedRAG evaluation reported a 90% attack success rate with five injected texts against a database of millions, because the injected text is engineered to rank highly for one specific, anticipated query rather than to compete generally across the whole corpus. A document does not need to be a plausible answer to every question; it needs to dominate similarity search for the one question the attacker is targeting.

Does removing a poisoned document from the index fully resolve an incident?

Removal stops new queries from retrieving it, but it does not undo an answer already given, a tool call already made based on that answer, or a copy of the poisoned content that was itself retrieved into a summary or another agent's context before removal. Recovery should trace and review every answer the poisoned document could plausibly have influenced, not only confirm the document is gone.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for LLM Applications, 2025 edition; OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30).

Last verified: 2026-09-01. The PoisonedRAG attack-success figure and publication dates were read from the arXiv record; the Morris-II propagation description, Virtual Donkey guardrail figures, and version dates were read from the arXiv record; the Zenity Labs publication date, author, and target were read from Zenity Labs' own post; the PromptArmor disclosure date and attack description were read from PromptArmor's own post; the OWASP LLM08:2025 scope was read from the official OWASP Gen AI Security Project page; the OWASP Agentic and MITRE ATLAS identifiers were reused from this site's previously verified crosswalk entries.

Change history: 2026-09-01, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** `AML.T0070 RAG Poisoning` is a MITRE ATLAS Standard Term. `LLM08:2025 Vector and Embedding Weaknesses` and `ASI06 Memory & Context Poisoning` are OWASP Standard Terms. "PoisonedRAG", "Morris-II", "ComPromptMized", and "Virtual Donkey" are Research Terms attributed to their respective papers. "RAG poisoning" as the umbrella covering the corpus, ingestion, and retrieval paths together, as used on this site, is SSA descriptive wording bundling those sources, not a term attributed to any single one of them.