RAG Security Guide: Retrieval Poisoning and Vector Database Security

A retrieval-augmented generation (RAG) system answers with whatever its index returns, so anyone who can get content into the corpus, or reach the vector store behind it, can shape what the model says and what it leaks. This guide covers the whole pipeline: source trust and ingestion, corpus poisoning, indirect prompt injection through retrieved text, vector database access control, tenancy and encryption, embedding inversion, grounding and citation checks, logging and evaluation. Permission trimming at query time is covered separately in the Permission-Aware RAG Guide. It is written for AI platform engineers, application security teams and architects who build or approve RAG applications.

Key takeaways

• The corpus is an input channel. Every source you index is a place where someone can write instructions or false facts that the model will later read with authority; control who can write to indexed sources as tightly as who can deploy code.
• Small amounts of poison are enough. The PoisonedRAG researchers report a 90% attack success rate from five crafted texts per target question in a database of millions, so volume-based anomaly detection alone will not find it.
• Vector stores are databases, and often unprotected ones. Self-hosted Qdrant, for example, is documented as "not secure by default": no authentication, all interfaces, no TLS. Treat the vector store as a tier-one data store with authentication, network isolation, encryption and audit logs.
• Embeddings are not anonymised data. Inversion research recovered 92% of 32-token inputs exactly from their embeddings, so vectors carry the same classification as the text they came from.
• Grounding is a security control. Verifying that each answer is supported by cited chunks, and that citations point to sources the user may see, catches poisoned and injected content that screening misses.

The RAG pipeline and where it breaks

OWASP added LLM08:2025 Vector and Embedding Weaknesses to its Top 10 for LLM Applications for weaknesses in how vectors and embeddings are "generated, stored, or retrieved" that can be exploited to inject harmful content, manipulate outputs or reach sensitive information. MITRE ATLAS models the attacker's path through the same pipeline: AML.T0064 Gather RAG-Indexed Targets (reconnaissance), AML.T0066 Retrieval Content Crafting, AML.T0070 RAG Poisoning, AML.T0071 False RAG Entry Injection and AML.T0051.001 Indirect prompt injection.

Ingestion and source trust

Most RAG compromises start with a write, not a hack. The OWASP LLM08 entry lists poisoning sources as "insiders, prompts, data seeding, or unverified providers", and its first example scenario is a CV with white-on-white text instructing the screening system to recommend the candidate.

• Tier every source: curated (reviewed changes, such as policy libraries), internal-open (any employee can edit, such as wikis and tickets) and external (web pages, inbound email, forms, partner feeds). Record the tier on every chunk and use it in ranking and screening.
• Review write access before indexing: a SharePoint site, Confluence space or ticket queue that thousands of people or an external form can write to is an untrusted source, however internal it looks. Fix over-broad write rights or index it as external.
• Capture provenance per chunk: source URI, document ID, author or last editor, source tier, content hash, ingest timestamp, connector identity and the parser version. Without these fields you cannot trace a poisoned answer back or purge it.
• Normalise before chunking: extract to plain text, drop hidden and zero-size elements, HTML comments and off-page text, strip invisible Unicode, and flag documents whose extracted text differs sharply from their rendered text. OWASP's CV scenario is exactly this check.
• Quarantine external content: hold new and changed external content in a staging index, screen it, then promote.
• Propagate deletes and permission changes: a removed or corrected document must leave the index on a defined schedule, and caches must be invalidated. The ConfusedPilot research showed a leak path that "leverages the caching mechanism during retrieval".
• Scope connector identities: each connector gets its own read-only identity for its own sources, stored in a vault and rotated. See the AI Infrastructure Workload Identity Guide.

Corpus poisoning and retrieval manipulation

RAG poisoning (AML.T0070) differs from training data poisoning: the attacker does not need to touch the model, only content that the retriever will rank highly for a target question. ATLAS describes the goal as contaminating "a future thread through RAG-based search results".

• Targeted knowledge corruption: PoisonedRAG (Zou et al., 2024) crafts texts that are both retrieved for a chosen question and lead the model to a chosen answer, and reports that the defences it evaluated were insufficient. Expect a handful of documents, not a flood.
• Self-replicating prompts: the Morris II research (Cohen, Bitton and Nassi) demonstrated an "adversarial self-replicating prompt" that spread through a network of GenAI-powered email assistants using retrieval, compromising the retrieval data of each next assistant and extracting confidential user data. ATLAS records the behaviour as AML.T0061 LLM Prompt Self-Replication and the research as case study AML.CS0024.
• Confused deputy effects: the ConfusedPilot research described a class of vulnerabilities that confuse Copilot-style enterprise RAG assistants, causing integrity and confidentiality violations, because content any user can add to the corpus influences answers given to everyone.
• False entries: AML.T0071 False RAG Entry Injection covers content formatted to look like an authoritative retrieved record, so the model treats it as a trusted source.

Defences that work together

• Limit writers to high-trust tiers: the most effective control is fewer people and systems able to write to curated sources, with reviewed changes.
• Cap per-source influence: limit the number of chunks from one document or author in the top-k, and prefer agreement across independent sources for factual answers.
• Weight by trust tier: rank curated content first, and keep external content out of high-impact answers (finance, HR, security procedures) unless requested.
• Detect query-targeted content: flag new chunks that are near-duplicates of each other, unusually similar to frequent queries, or that suddenly dominate retrieval for a query cluster.
• Run canary questions: known-answer questions run after each ingest; a changed answer or top source triggers review.
• Version the index: keep immutable snapshots or versioned collections so a poisoned ingest can be rolled back and investigated.

Indirect prompt injection through retrieved content

Greshake et al. first showed that attackers can exploit LLM applications remotely by "strategically injecting prompts into data likely to be retrieved", because these applications "blur the line between data and instructions". OWASP LLM01:2025 lists poisoned RAG documents and hidden instructions in CVs among its scenarios. The general defences are in the Prompt Injection Guide; the RAG-specific points are:

• Label retrieved text as data: wrap each chunk in delimiters with its source and tier, and instruct the model that retrieved content carries no authority. Some services go further: Microsoft's Prompt Shields spotlighting (preview, off by default) base-64 encodes documents "to indicate lower trust to the model".
• Screen retrieved chunks, not just the user prompt: document-attack classifiers such as Prompt Shields accept retrieved documents separately (up to five per standalone call). Microsoft notes that a "No prompt attack" result does not establish that a request is benign, so screening reduces volume rather than proving safety.
• Do not combine untrusted context with powerful tools: a RAG assistant that reads external email and can also send mail or fetch URLs is an exfiltration path. The EchoLeak zero-click Copilot flaw relied on an attacker's email being retrieved into the assistant's context and on an output channel that could carry data out.
• Treat inbound business records as external: CRM leads, web forms and support tickets submitted by outsiders are attacker-controlled. The ForcedLeak Agentforce case started with a web form.

Classifier and filter choices are compared in the AI Guardrails and AI Firewalls Guide.

Vector database security

Vector stores hold your most useful documents as chunks, vectors and metadata, yet are often run from a quick-start container. Check each property below in the vendor documentation.

Ask the same five questions of Milvus and managed vector services, and ask for documentation.

Tenancy and segregation

• Separate instances: strongest isolation, highest cost.
• Collection per tenant or sensitivity level: enforced with per-collection credentials (for example Qdrant JWT access claims); a good default.
• Shared collection with metadata filters: cheapest, but a single missing filter leaks across tenants. OWASP LLM08 lists cross-context leaks in shared multi-tenant vector databases as a core risk. Acceptable only when the filter is enforced server-side (for example PostgreSQL RLS keyed to the session's tenant).

Network, encryption and credentials

• Network: no public endpoint; bind to a private interface (Qdrant documents service.host: 127.0.0.1 for local use), private endpoints for managed services, and allow only the retrieval service and ingestion workers.
• Encryption: TLS on every hop including peer replication, encryption at rest with keys you manage for sensitive corpora, and encrypted snapshots and backups. See the Encryption Guide.
• Separate write and read identities: ingestion workers write, the query service reads, and neither holds the admin key. Vault and rotate vector store keys like any other API key; see the API Key Management Guide. An exposed database full of agent keys, as in the Moltbook exposure, shows how quickly open data stores in AI stacks are found.

Embedding inversion and the sensitivity of vectors

Teams sometimes treat embeddings as a safe, irreversible representation and share or log them freely. Research says otherwise: Morris et al. (2023) describe a method that iteratively corrects and re-embeds text and is able to "recover 92% of 32-token text inputs exactly", and recovered full names from a dataset of clinical notes. OWASP LLM08 lists embedding inversion as a named risk.

• Classify vectors as their source: an index built from HR files is HR data. Apply the same retention, residency and access rules, and include the vector store in data maps and records of processing.
• Do not export embeddings casually: analytics exports and debugging dumps leak content even without the chunk text.
• Delete completely: erasure must remove chunk text, vectors, metadata, caches and snapshots. See the AI and Privacy Guide.

Output grounding and citation checks

Grounding checks require every answer to be backed by retrieved text the user may see, and they catch poisoned or injected content whose influence shows up as unsupported claims.

• Cite by chunk ID: the model must reference retrieved chunk identifiers; the application renders citations from its own metadata, not from URLs the model writes.
• Verify citations exist and match: every cited ID must be in the retrieved set for this request, and quoted spans must appear in the cited chunk. Drop or flag answers that fail.
• Score faithfulness: Ragas defines faithfulness as the share of claims in an answer that the retrieved context supports, scored 0 to 1. Use a threshold in production for high-impact assistants and route low scores to a refusal or human review.
• Refuse when retrieval is weak: with no chunk above the similarity threshold, answer "not found" rather than from model memory.

Logging, evaluation and detection

OWASP LLM08 recommends "detailed immutable logs" of retrieval activity. Log enough to reconstruct any answer:

• Per request: requesting user or agent, tenant, query text (or a hash where policy requires), retrieved chunk IDs with scores and source tiers, screening verdicts, grounding score, tools invoked and output links rendered.
• Per ingest: connector identity, documents added, changed and deleted, hashes, screening results and the index version produced.
• Vector store audit: authentication failures, admin operations, collection creation and deletion, snapshot downloads and unusually large scroll or export queries.

Run an evaluation suite before release and after every ingest or model change: canary questions, an injection set planted in a test index, cross-tenant queries that must return nothing, and faithfulness scoring on sampled real queries.

Metrics that show it is working

• Source coverage: percentage of indexed sources with a recorded trust tier and write-access review; target 100%.
• Provenance completeness: percentage of chunks with source, author, hash and ingest time; target 100%.
• Canary stability: canary answers or top sources that changed unexpectedly per ingest; target zero unexplained changes.
• Grounding rate: share of production answers above the faithfulness threshold, tracked weekly.
• Deletion latency: time from source deletion to removal from index, caches and snapshots; set a target such as 24 hours.
• Exposure: vector store endpoints without authentication or reachable from outside the private network; target zero.

Choosing controls for your deployment

Small teams get most of the benefit from an authenticated, private vector store, provenance metadata, curated sources only and citation checks. Large estates with many connectors also need staging, canaries and SOC integration, because nobody can review every source by hand.

Implementing RAG security in phases

1. Inventory: list every RAG application with its sources, connectors, vector store and tools. The Shadow AI Discovery Guide helps find unofficial ones.
2. Lock down the store: enable authentication and TLS, remove public exposure, split read and write identities, enable audit logging. Test by confirming that unauthenticated and wrong-tenant requests fail.
3. Add provenance and tiers: re-ingest with full metadata and drop sources with uncontrolled write access.
4. Screen in monitor mode: run normalisation, injection screening and anomaly flags on new content, logging only for two to four weeks to measure false positives.
5. Enforce: block flagged content, apply per-source caps and trust weighting, and make citation and faithfulness checks blocking for high-impact assistants, piloting with one assistant and user group first.
6. Roll back safely: keep the previous index version and configuration so a bad ingest or an over-aggressive filter can be reverted in minutes; record the index version in every request log.
7. Operate: canaries after each ingest, quarterly red teaming of the corpus, and incident runbooks for purging poisoned content. See the Red Teaming AI Agents for Identity Abuse.

Framework mapping

CIS Controls v8.1 Control 3 (Data Protection), Control 6 (Access Control Management) and Control 8 (Audit Log Management) apply to the vector store as to any other data store. For a broader LLM control set see the LLM Security Guide.

Common failure patterns

• Indexing everything a connector can read. Broad connectors pull in sources anyone can edit, so thousands of users become corpus authors.
• Vector store left on quick-start defaults. No API key, no TLS and a public port, found by scanners first.
• Tenant isolation by client-side filter. One missing where tenant_id = ... in a new code path returns another customer's chunks.
• Treating external records as internal. Web forms and inbound email indexed alongside policies give outsiders a direct line to the model; SalesBleed used poisoned Web-to-Lead records against CRM agents.
• Deletes that never reach the index. Documents removed for legal or privacy reasons keep being cited from stale chunks, caches and snapshots.
• Citations generated by the model. The model writes plausible URLs that do not match retrieved content, so users trust answers no source supports.

Practitioner checklist

• Inventory RAG applications with their sources, connectors, embedding models, vector stores and tools.
• Assign every source a trust tier and review write access before it is indexed.
• Record source, author, hash, tier and ingest time on every chunk, and propagate deletes within a defined time.
• Normalise documents and strip hidden text and invisible Unicode before chunking; stage and screen external content.
• Enable authentication, TLS, RBAC and audit logging on the vector store, with separate read and write identities and no public exposure.
• Enforce tenant and sensitivity segregation server-side, and test cross-tenant queries in CI.
• Classify embeddings as their source data and include them in retention and erasure.
• Render citations from retrieved metadata, verify them, and apply a faithfulness threshold to high-impact answers.
• Run canary questions after each ingest and keep versioned index snapshots for rollback.
• Send retrieval, ingest and vector store audit logs to the SOC.

Standards and references

• OWASP: LLM08:2025 Vector and Embedding Weaknesses
• OWASP: LLM01:2025 Prompt Injection
• MITRE: ATLAS data (AML.T0070 RAG Poisoning and related techniques)
• Qdrant: Security documentation
• PostgreSQL: Row Security Policies
• arXiv: PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models
• arXiv: Text Embeddings Reveal (Almost) As Much As Text
• arXiv: Here Comes The AI Worm: Unleashing Zero-click Worms that Target GenAI-Powered Applications

Related NHI Mgmt Group resources: Permission-Aware RAG Guide · Prompt Injection Guide · LLM Security Guide · AI Guardrails and AI Firewalls Guide · Enterprise AI Copilot Security Guide