What is RAG security?

RAG security is the practice of identifying, assessing, and validating the security properties of Retrieval-Augmented Generation systems — with particular focus on what the retrieval layer exposes, to whom, under what conditions, and whether that matches the application’s intended access model.

What is Retrieval-Augmented Generation?

Retrieval-Augmented Generation (RAG) is an architecture pattern for building LLM applications that grounds responses in specific content. Instead of relying entirely on the model’s training data, a RAG system retrieves semantically relevant documents from an external knowledge store and provides them as context to the model before it generates a response.

The typical components of a RAG system are:

1. Content ingestion: Source documents are split, embedded using a text embedding model, and stored in a vector database.
2. Query path: A user query is embedded and used to retrieve the most semantically similar records from the vector store.
3. Generation: Retrieved records are passed as context to an LLM, which generates a response grounded in that content.

Why does RAG create new security risks?

RAG systems introduce security risks that do not exist in traditional web applications and are not caught by traditional security tools:

• Vector similarity search is not access control. Retrieving the “nearest neighbors” to a query is a mathematical operation — it does not know anything about who owns which records. Access control must be layered on top, and in most implementations it is an application-layer filter that is easy to miss or misconfigure.
• Multi-tenant RAG applications mix data at the storage layer. Many RAG applications serve multiple tenants using a shared vector index or collection, using namespace or metadata-filter-based separation. When that separation fails — even temporarily — one tenant’s content becomes retrievable by another.
• Retrieval failures are invisible to standard security tools. SAST, DAST, cloud configuration scanners, and LLM guardrails do not test whether tenant A can retrieve tenant B’s records. This requires a tool that understands vector database topology and can test retrieval against tenant boundaries.
• Content at rest in vector stores is often unclassified. Vector databases accumulate embedded content from many sources, often without consistent classification, provenance, or retention labels. This creates audit and privacy exposure even without an active breach.
• Prompt injection can travel through the retrieval layer. If an attacker can write records to a shared vector store — directly or through public-facing ingestion — those records can be retrieved and included in LLM context, carrying adversarial instructions that the model may follow.

The tenant isolation problem

The most critical RAG security property for multi-tenant applications is tenant isolation: every retrieval operation must return only records that the requesting identity is authorized to see. Breaking this property is a cross-tenant retrieval failure — and for applications that handle enterprise data, it is a data breach.

Cross-tenant retrieval failures happen in several ways:

• A required metadata filter is omitted from a retrieval call
• A namespace or tenant field is controlled by user input and can be manipulated
• Application code handles the correct tenant in most paths but misses edge cases (unauthenticated fallback, background jobs, administrative views)
• Multi-tenant collections lack tenant fields on some records due to a migration error
• An API key used for production retrieval has broader scope than intended and returns data from all tenants

Key attack surfaces in RAG systems

• Vector store access control: Credential scope, tenant isolation model, namespace and collection access
• Application retrieval path: Metadata filters, namespace selectors, tenant fields — and whether they are reliably enforced
• Content at rest: Sensitive content, unclassified data, missing provenance and retention labels
• Ingestion pipeline: Who can write to shared stores, whether adversarial content can be injected
• Credential management: Read-only versus write-capable keys, key scope, key exposure in client-side code