RAG Security

Retrieval-Augmented Generation changes how applications use data — and introduces security risks that traditional controls were not designed to handle. This hub covers RAG security fundamentals, testing methodology, and provider-specific security considerations.

What makes RAG security different

RAG applications combine three components that each have their own security model: a vector database that stores embedded content, a retrieval query path that selects what the model can see, and an LLM that generates responses from whatever was retrieved. The security failures that matter most happen at the boundary between the retrieval layer and access control — specifically, when records belonging to one tenant are retrievable by another.

Vector similarity search does not natively enforce access control. You can build it, but most implementations rely on application-layer filters that are easy to misconfigure, bypass, or forget. The result is a class of failure that does not show up in standard penetration tests, SAST tools, or cloud configuration scanners — because none of them were built to inspect vector database topology and test retrieval against tenant boundaries.

Topics in this hub

The core security question for every RAG application

The fundamental question is whether the retrieval layer enforces the same access boundaries that the rest of your application does. A signed-in user who should only see their own organization’s data — can the retrieval path return records belonging to a different organization? In most implementations, this is not tested at all. RAGSec tests it directly.