Enterprise RAG Security
RAG Security Checklist: 42 Controls to Prevent Data Leakage, Poisoning, and Cross-Tenant Exposure
A practical security framework for protecting document ingestion, embeddings, vector databases, retrieval, generation, caches and production operations.
Retrieval-augmented generation gives an AI application access to information the underlying model was never trained on: internal documents, customer records, contracts, support conversations, policies and proprietary knowledge.
That access is what makes enterprise RAG valuable—and dangerous. A conventional application retrieves data and displays it. A RAG system retrieves information, places it inside a model’s context, combines it with user instructions and generates a new answer. Weaknesses anywhere in that chain can expose protected information, amplify poisoned content, bypass source permissions or mix data belonging to different customers.
The most serious failures frequently begin with ordinary engineering shortcuts. A document is embedded without preserving its permissions. Tenant isolation depends on a metadata filter supplied by the browser. Deleted documents remain in the vector index or semantic cache. Retrieved text is treated as trusted instructions. A broad service account gives every user the same retrieval authority.
This checklist converts those risks into 42 testable controls. It can support architecture reviews, production-readiness decisions, security assessments and remediation planning. It is not a compliance certificate; it is an engineering baseline that should be adapted to your data, users and consequences.
What is RAG security?
RAG security protects the complete retrieval-augmented generation pipeline from unauthorized access, sensitive-data disclosure, document poisoning, prompt injection, vector-store compromise, tenant leakage and unsafe output. It includes the source systems, ingestion workers, parsers, chunk stores, embedding models, vector database, authorization service, generation model, caches, tools and operational logs.
Securing only the model API is therefore insufficient. The model may behave exactly as configured while the retrieval layer supplies a confidential chunk that the current user was never authorized to see. Likewise, a correctly authorized document can contain malicious instructions that attempt to influence the model or an attached agent.
Why traditional application security is not enough
Traditional controls remain essential: authentication, encryption, secure software development, dependency management, network restrictions and secrets handling. RAG introduces additional semantics. Access decisions must survive copying, parsing, chunking and embedding. Similarity search can retrieve information that does not share the exact words in the question. Generated output can paraphrase protected passages, making simple string-based detection unreliable.
RAG also turns content into part of the application’s runtime control surface. A document is no longer passive. Its text is placed beside instructions consumed by a probabilistic model. This is why poisoning and indirect prompt injection must be handled during ingestion, retrieval, generation and output enforcement—not with one prompt-level warning.
The three failure modes this checklist prioritizes
1. Sensitive-data leakage
Leakage occurs when confidential content appears in an answer, citation, log, trace, cache or error message. It can originate from overly broad connectors, missing document permissions, unsafe observability, excessive retrieval or weak output controls. Embeddings should also be treated as sensitive derived data rather than anonymous representations.
2. Knowledge-base poisoning
Poisoning occurs when an attacker, compromised source or careless process inserts misleading facts or instructions into the corpus. The content can alter answers long after ingestion and affect every user whose query retrieves it. Integrity, provenance, quarantine, monitoring and rebuild procedures are therefore production requirements.
3. Cross-tenant exposure
Cross-tenant exposure occurs when one customer, department, project or security group receives information belonging to another. The cause may be a missing filter, client-controlled tenant ID, stale permission metadata, unsafe cache key or administrative endpoint. Isolation must be enforced by architecture and continuously tested.
Interactive assessment
Your RAG security score
Critical exposure
Coverage by security layer
The complete framework
The 42-control RAG security checklist
Select every control you can verify with architecture, configuration, test evidence or logs. A policy statement without implementation evidence should not be marked complete.
How to interpret your RAG security score
A high percentage is useful only when every selected control is supported by evidence. The assessment deliberately gives each control equal visible weight, but your remediation plan should not. Missing tenant isolation, retrieval-time authorization or fail-closed behavior can outweigh several lower-impact operational improvements.
- 0–42%: Critical exposure. The system lacks foundational boundaries. Restrict sensitive data and production access until the critical controls are verified.
- 43–66%: High risk. Important protections exist, but exploitable gaps likely remain across retrieval, permissions, poisoning resistance or incident response.
- 67–85%: Moderate gaps. The architecture may be viable for controlled production, but specific weaknesses require assigned remediation and regression tests.
- 86–100%: Controlled. Strong baseline coverage exists. Continue adversarial testing, permission drift monitoring and reassessment after material changes.
How cross-tenant leakage happens
Consider a SaaS application that stores all customer embeddings in one index. The browser submits a tenant identifier, and the API adds it to the vector search filter. This looks isolated during normal testing. An attacker modifies the request, removes the tenant filter or invokes another retrieval endpoint that does not apply it.
The correct design derives tenant identity from the authenticated server-side session. Retrieval cannot execute without that scope. Every vector has mandatory tenant metadata, returned candidates are checked again and the semantic cache is partitioned by the same authorization context. Automated canaries continuously attempt to cross the boundary.
Client supplies tenant ID
Optional metadata filter
Another tenant’s chunk enters context
How poisoning travels through a RAG pipeline
A poisoned document may look legitimate to a human reviewer while containing hidden text consumed by the parser. Once chunked and embedded, it can be retrieved by semantically related questions. If the generation model interprets the passage as instructions, the poison may alter answers, suppress competing evidence or attempt to trigger tools.
Effective defenses form a chain: restrict who can write to sources, quarantine changes, compare extracted and visible content, preserve provenance, constrain context, treat retrieved text as untrusted, limit tools, validate output and maintain a rapid index-rebuild process. No single prompt or classifier provides the complete boundary.
RAG security testing methodology
Start with a data-flow inventory. Trace a document from its source through extraction, chunking, embedding, indexing, retrieval, prompt assembly, generation, output policy, caching and logging. Identify where identity, tenant and classification data are introduced, transformed or lost.
Next, test authorization using users with intentionally different permissions. Include recently revoked users, nested groups, shared documents, regional restrictions and records that change ownership. Exercise every retrieval mode, including keyword, vector, hybrid, recommendation, export and administrative search.
Poisoning tests should include visible instructions, hidden text, Unicode obfuscation, contradictory facts, malicious metadata and content planted in sources with different trust levels. Evaluate which chunks were retrieved, how the model treated them and whether generated output or tool calls crossed policy boundaries.
Finally, validate operational evidence. Confirm that an investigator can reconstruct why an answer was generated without exposing the content to unauthorized log viewers. Revoke a document and measure how quickly it disappears from indexes, replicas and caches. Simulate an authorization outage and verify the pipeline fails closed.
Standards and authoritative guidance
The checklist aligns with the risk themes described in the OWASP RAG Security Cheat Sheet, including document integrity, access-control metadata, tenant isolation, output validation, observability and fail-closed behavior.
OWASP’s guidance on vector and embedding weaknesses also highlights unauthorized access, cross-context leakage, embedding inversion and poisoning. These references should inform architecture and testing, but implementation decisions must reflect the organization’s own threat model.
When to commission an Embedding Exposure Assessment
A structured assessment is appropriate when the index contains customer, employee, financial, health, legal or proprietary information; multiple tenants share infrastructure; source permissions are complex; an agent can take consequential actions; or the team cannot produce evidence for the critical controls above.
The assessment should answer concrete engineering questions: Which identities can query each index? Can tenant scope be omitted? Do chunks preserve current source permissions? Can a malicious contributor poison the context? Do caches inherit authorization? Can the team reconstruct and contain an incident?
Qualified assessment request
Find the exposure before production does
Tell us what your RAG system can access. We’ll use your answers to determine whether an Embedding Exposure Assessment is the right next step.
Frequently asked questions
What is the biggest security risk in a RAG system?
The highest-impact risk is usually unauthorized retrieval: protected content is placed into the model context because source permissions, tenant boundaries or current user authorization were not enforced correctly. Document poisoning and indirect prompt injection become especially dangerous when the RAG system can also invoke tools.
Can embeddings leak sensitive data?
Yes. Embeddings are not a safe replacement for access control or encryption. Research and OWASP guidance describe information leakage and embedding-inversion risks. Protect vectors, minimize embedded content and retain the same authorization boundaries as the source information.
How do you prevent cross-tenant leakage in RAG?
Derive tenant identity from the authenticated server session, enforce tenant scope before vector search, attach authorization metadata to every chunk, validate candidates after retrieval, isolate caches and continuously test using tenant-specific canary documents.
Does metadata filtering provide sufficient tenant isolation?
Not automatically. It can be appropriate when the filter is created and enforced server-side, mandatory fields cannot be omitted and every retrieval path is tested. Higher-risk systems may require separate namespaces, indexes, accounts or encryption keys.
How often should a RAG security assessment be performed?
Assess before production and after major changes to data sources, parsers, embedding models, vector databases, permission models, generation models or agent tools. Continuous boundary tests should run as part of normal release engineering.
What should a professional RAG security assessment deliver?
It should document data flows, source permissions, tenant isolation, poisoning resistance, retrieval authorization, cache behavior, logging coverage and reproducible findings. The result should include prioritized remediation work and validation evidence.