RAG Security: Threat Model, Attack Vectors & Hardening Guide for Enterprise AI (2025)

Retrieval-Augmented Generation has become the default architecture for enterprise LLM applications — connecting models to internal knowledge bases, documentation, databases, and real-time data. But RAG is not just a capability upgrade. It introduces a retrieval layer that fundamentally expands the LLM attack surface, creating threat vectors that don't exist in standalone model deployments.

The RAG Architecture and Its Attack Surface

A typical enterprise RAG pipeline has four stages, each with distinct security considerations:

• Ingestion: Source documents are chunked, embedded as vectors, and stored in a vector database
• Retrieval: User query is embedded; similar vectors are retrieved from the knowledge base
• Augmentation: Retrieved chunks are injected into the LLM's context window
• Generation: The model generates a response conditioned on both the query and retrieved context

Attackers can target any of these stages. The retrieval stage is particularly dangerous because content that passes ingestion security checks may still contain adversarial patterns that activate only when combined with specific queries.

Attack Vector 1: Knowledge Base Poisoning

Knowledge base poisoning involves injecting adversarial documents into the knowledge base with the goal of corrupting the RAG system's outputs for targeted queries. The seminal research on this is PoisonedRAG, published at USENIX Security 2025.

How PoisonedRAG Works

The attacker crafts a small number of adversarial documents (as few as 1–5) designed to be highly similar to legitimate documents for targeted queries. When the target query is issued, the poisoned documents rank in the top-k retrieved results. The adversarial content then influences generation — causing the model to output incorrect, biased, or harmful information.

Key findings from the research:

• Effective with as few as 1 injected document per target query in standard vector databases
• Works against dense retrievers (embeddings) and sparse retrievers (BM25) alike
• Poisoned documents can be crafted to appear legitimate to human reviewers
• Attack remains effective across different embedding models

Real-World Poisoning Scenarios

• Customer service RAG: Poisoned FAQ entry causes bot to give incorrect refund policy, leading to financial loss
• Internal knowledge assistant: Injected document in a connected SharePoint or Confluence causes the assistant to recommend incorrect security procedures
• Medical information RAG: Adversarial document causes incorrect drug interaction information to be retrieved and surfaced
• Financial services RAG: Poisoned regulatory document causes compliance assistant to give incorrect guidance

Defenses Against Knowledge Base Poisoning

• Document provenance: Track and verify the source of every document before ingestion
• Ingestion access control: Restrict who can add documents to the knowledge base
• Anomaly detection at ingestion: Flag documents with unusually high semantic similarity to existing content on different topics
• Source integrity checks: Hash-verify documents at ingestion and periodically against source systems
• Retrieval diversity: Don't rely solely on top-1 retrieval; use diversity-aware retrieval to reduce single-document influence

Attack Vector 2: Indirect Prompt Injection via Retrieved Content

Even without poisoning the knowledge base, attackers can embed prompt injection payloads in documents that legitimately end up in the knowledge base — web pages, user-submitted content, emails, or third-party data feeds.

The injection may be invisible in rendered documents but visible to the LLM processing raw text. Common injection locations include:

• HTML comments and metadata fields
• White-text-on-white-background in PDFs and Word documents
• Image alt-text and hidden form fields
• Markdown or HTML encoded as plaintext
• Footnotes and page headers/footers processed as body text

Attack Vector 3: Embedding Inversion and Privacy Leakage

Vector embeddings are often assumed to be one-way transformations — but research published in 2024-2025 demonstrates that embeddings can be partially or substantially inverted to reconstruct source text. This has significant privacy implications for RAG systems storing sensitive data in vector databases.

The Threat

If an attacker gains read access to the vector database (or can query the embedding API), they may be able to reconstruct approximate versions of the source documents. For knowledge bases containing:

• Patient records or medical history
• Legal documents and contracts
• Employee personal information
• Customer financial data
• Internal strategy documents

…this represents a significant privacy breach even if the original documents are access-controlled but the vector store is not.

Defenses Against Embedding Inversion

• Apply the same access controls to vector stores as to source documents — do not treat vectors as non-sensitive
• Implement context-aware access control at retrieval time (retrieve only documents the querying user is authorized to access)
• Consider differential privacy techniques for sensitive embeddings
• Audit vector database access with the same rigor as database access logs

Attack Vector 4: Membership Inference Attacks

Membership inference attacks allow an attacker to determine whether a specific document was part of the RAG knowledge base — even without direct access to the store. This leaks information about what data an organization has collected and indexed, which may itself be sensitive.

The attack works by querying the RAG system with content from the suspected document and observing whether the system's response shows evidence of having seen that content. Defenses include output attribution masking and retrieval confidence threshold controls that prevent highly specific matches from being surfaced.

Secure RAG Architecture: End-to-End Hardening

Stage 1: Secure Ingestion Pipeline

• Implement document provenance tracking with cryptographic signatures where possible
• Strip HTML, metadata, and hidden content before embedding to remove injection vectors
• Scan document content for prompt injection patterns before ingestion
• Require approval workflows for adding new data sources to production knowledge bases
• Maintain an immutable audit log of all ingestion events

Stage 2: Secure Retrieval Layer

• Implement per-user or per-role access control on retrieval — users only retrieve documents they are authorized to see
• Use retrieval diversity techniques (MMR - Maximal Marginal Relevance) to reduce single-document dominance
• Apply minimum relevance thresholds to filter out low-confidence retrievals
• Log all retrieval queries and results for anomaly detection

Stage 3: Context Sanitization Before Generation

• Scan retrieved chunks for instruction-like patterns before injecting into LLM context
• Wrap retrieved content in explicit markers that differentiate it from system instructions
• Truncate retrieved chunks to reasonable lengths to limit injection payload size

Stage 4: Output Validation and Attribution

• Validate that generated responses are grounded in retrieved content (hallucination detection)
• Surface source attribution to users so responses can be verified
• Scan outputs for sensitive data patterns (PII, credentials) before returning to users
• Monitor for outputs that significantly deviate from retrieved content (potential injection influence)

RAG Security Compliance Considerations

Enterprise RAG deployments face specific compliance obligations beyond general LLM security:

• GDPR Data Minimization: Vector stores should only contain personal data necessary for the RAG use case. Embeddings of personal data are still personal data under GDPR.
• Right to Erasure: Implement mechanisms to delete source documents and their corresponding vectors when deletion requests are received
• EU AI Act Article 10: Training and fine-tuning data governance requirements apply to knowledge bases used to ground model outputs
• HIPAA (healthcare): PHI embedded in vector stores must meet the same security controls as PHI in traditional databases
• SOC 2 Type II: Access control, logging, and anomaly detection requirements extend to vector store infrastructure

Conclusion

RAG security requires defending four distinct stages — ingestion, retrieval, augmentation, and generation — each with unique attack vectors. Knowledge base poisoning, indirect prompt injection via retrieved content, embedding inversion, and membership inference are all credible threats against production RAG systems. Organizations building enterprise RAG applications must treat the retrieval layer with the same security rigor as the model layer, implementing provenance controls, access-aware retrieval, context sanitization, and output validation to maintain security guarantees across the full pipeline.