RAG Security — Vector Store Leaks, Retrieval Hijacks, Embedding Inversion

RAG (Retrieval-Augmented Generation) is the dominant pattern for grounding LLMs in private data. You chunk documents, embed each chunk into a vector, store in a vector database (Qdrant, Weaviate, Pinecone, pgvector). At query time, you embed the user’s question, find the K nearest chunks, prepend them to the LLM prompt. The LLM answers based on retrieved context. The security model is non-obvious because the attack surface spans documents, vectors, retrieval, prompt construction, and LLM generation — five distinct layers, each with unique failure modes.

Multi-tenant vector store leaks

The most common production bug: customer A and customer B both have data indexed in the same vector collection. Customer A asks a question; their query embeds to a vector close to customer B’s data; B’s data ends up in A’s prompt. Salesforce Einstein (2024) had this exact issue — sales reps from Company A occasionally saw snippets from Company B’s knowledge base. Root cause: insufficient metadata filtering. Fix: every document in the index must carry tenant_id metadata; every retrieval must filter on it BEFORE similarity ranking. Most vector DBs support this (Qdrant filters, Pinecone namespaces, pgvector WHERE clauses) — but developers often skip it for “performance” or implement it loosely. Test for this: index two distinct corpora with different tenant_ids; query as tenant_a; verify zero tenant_b chunks come back.