Technical Guide

Retrieval Poisoning in RAG Systems

Retrieval poisoning compromises the external documents, embeddings, or vector store indexes a RAG system queries at inference time, causing the model to treat attacker-controlled content as trusted context. Unlike prompt injection, it targets the knowledge source rather than the prompt interface. Unlike training-data poisoning, it requires no access to model weights or training pipelines.

Talk to an Expert

Defining Retrieval Poisoning

Retrieval poisoning refers to attacks that target the external knowledge sources a RAG system queries at inference time, including source documents, vector embeddings, and the vector store index, rather than the model's weights or the prompt itself. When retrieval poisoning succeeds, the system treats attacker-controlled content as trusted context and incorporates it into generated output or tool-call decisions without any signal that the input has been compromised.

OWASP's Top 10 for LLM Applications treats this as a distinct risk category, Vector and Embedding Weaknesses, separate from prompt injection, reflecting that it exploits a different layer of the application stack than the prompt interface. Academic research, including the PoisonedRAG study, has demonstrated that inserting a small number of adversarial text entries into a RAG knowledge base is sufficient to cause the system to retrieve and generate attacker-chosen outputs for targeted queries.

This matters for enterprise deployments because RAG systems are frequently built on internal wikis, ticketing systems, and shared documentation repositories that carry looser access controls than production application code, widening the attack surface beyond what conventional security monitoring typically covers.

Key distinction: Retrieval poisoning corrupts external content at inference time. It does not require access to model weights, training pipelines, or the prompt interface itself.

How Retrieval Poisoning Differs from Related Attacks

Retrieval poisoning is often confused with related but distinct attack classes. The differences matter because each class implies a different adversary model and a different set of controls.

Aspect Retrieval poisoning Prompt injection Training-data poisoning
Primary target Documents, embeddings, vector index User or system prompt Training or fine-tuning data
When it lands Inference time (retrieval) Inference time (prompt) Before deployment
Model access required No access to weights or training Access to prompt interface Access to training pipeline
How influence appears Malicious content returned as trusted context Instructions override via the prompt Behavior baked into model weights

Training-data poisoning corrupts model weights during training or fine-tuning and requires access to the training pipeline itself; the resulting behavior is baked into the model before deployment. Retrieval poisoning corrupts external content accessed at inference time and requires no access to the model or its training data, which makes it accessible to a different and often broader set of adversaries.

Prompt injection targets the user or system prompt directly, attempting to override instructions through the interface the user or application controls. Retrieval poisoning instead targets the knowledge source, so malicious instructions or false information are introduced automatically as retrieved context that the system treats as trusted.

Research on indirect prompt injection established that content retrieved from external sources can carry adversarial instructions that influence model behavior without the attacker ever interacting with the prompt interface. That mechanism connects retrieval poisoning to downstream prompt-level effects even though the initial compromise occurs earlier in the pipeline.

Documented Attack Techniques

Three technique categories are consistently described across current research and threat frameworks.

Adversarial document injection

Attackers introduce a small number of crafted documents into a knowledge base so they are retrieved for targeted queries. The PoisonedRAG research demonstrated this can succeed with a limited number of inserted entries.

Embedding-space manipulation

Text is crafted so its vector representation lands close to anticipated target queries, increasing the likelihood of retrieval independent of genuine semantic relevance to the query.

Index tampering

Unauthorized write or update access to a vector database allows an attacker to insert or modify stored vectors and documents directly, bypassing any review applied at ingestion time.

MITRE ATLAS documents adversarial tactics against AI-enabled systems that include manipulation of external data sources consumed by ML applications, situating these techniques within a broader adversarial tactics framework rather than treating them as isolated incidents. Terminology across sources is not fully standardized; the same technique class is variously described as retrieval poisoning, RAG poisoning, or corpus poisoning depending on the source.

Where Poisoning Enters the RAG Pipeline

Each stage of a RAG pipeline is a separable injection point. Understanding where controls apply at each stage is a prerequisite for designing effective defenses.

  1. Ingestion

    Documents from internal or third-party sources enter the pipeline without content authentication, allowing adversarial text to be introduced at the source.

  2. Embedding and chunking

    Text is split and converted into vector representations; crafted text can be positioned near target queries in vector space independent of genuine relevance.

  3. Indexing

    Vectors and documents are written to the vector database; unauthorized or unmonitored write access allows direct insertion or modification of stored entries.

  4. Retrieval

    Similarity search surfaces content for a given query; poisoned entries designed to score highly on relevance are returned as if they were legitimate context.

  5. Generation

    Retrieved content is passed into the model context or a tool-call chain, where it can influence output or authorize downstream actions without further verification.

Runtime and Architectural Controls

Defenses work best when they span ingestion, index access, retrieval filtering, and tool-call authorization rather than relying on a single checkpoint.

Authenticate content at ingestion

Validate source documents against allow-listed sources or provenance signals before they enter the vector store.

Restrict index write access

Treat vector database write and update operations as privileged actions with dedicated access control and audit logging, separate from general application permissions.

Filter retrieval output before generation

Apply validation on retrieved content as a discrete step before it is passed into the generation context or a tool-call chain.

Scope tool-call permissions independently

Architect execution paths so retrieved content cannot independently authorize high-privilege or irreversible actions without separate verification.

Monitor for retrieval anomalies

Watch for documents surfacing across semantically unrelated queries, which can indicate embedding-space manipulation.

Log retrieval content separately

Distinguish retrieval-sourced content from system and user prompt content in logs to preserve traceability for post-incident analysis.

Governance and Accountability

No regulation currently mandates retrieval-layer or RAG-specific security controls; current guidance is derived from general AI risk-management and application-security frameworks. NIST's AI Risk Management Framework identifies data and content provenance tracking and integrity monitoring as core functions under its Govern and Map activities, applicable to externally sourced content consumed by AI systems.

OWASP guidance treats vector and retrieval-layer risks as requiring dedicated security review distinct from standard application security testing, which implies that existing web or API security processes are unlikely to fully cover this attack class without deliberate extension.

Enterprises deploying RAG-based agents should assign explicit accountability for vector store and content ownership separate from model or application ownership, since the parties responsible for curating source content are often distinct from those responsible for model behavior. Runtime governance platforms that enforce least-privilege tool-call permissions and maintain audit logs of retrieval-sourced content provide one layer of defense within this architecture, though they are not a substitute for ingestion-time content validation and access control on the vector store itself.

Operational takeaway: Treat the vector store and its source corpus as production data stores with their own owners, access policies, and audit trails. Model ownership alone does not cover this surface.

Reduce the Retrieval Attack Surface in Production AI Agents

Runtime governance and least-privilege tool-call controls address one part of the retrieval poisoning attack surface. Speak with a specialist about applying these controls to your RAG-based agent deployments.

Talk to an Expert