Vector and Embedding Weaknesses: The Security of RAG

Retrieval-augmented generation is how most enterprises make an LLM useful: embed your documents into vectors, store them, and retrieve the relevant ones to ground each answer. LLM08 is the new-for-2025 recognition that this pipeline — the embeddings, the vector database, and the retrieval step — is itself a security boundary, and one that is routinely built without the access controls the original data always had.

When you copy documents into a vector store, you often strip them of the permissions that governed the originals. The source file lived behind a folder ACL; its embedding now sits in a shared index with no notion of who is allowed to see it. Retrieval then treats every vector as equally accessible, and the model faithfully summarises whatever comes back. The access-control check that a file system or database would enforce simply isn't in the loop.

Where RAG goes wrong

The most common failure is cross-context and cross-tenant leakage. In a shared vector database, a query that isn't scoped to the requesting user's permissions can retrieve another user's — or another tenant's — documents, and the model will happily explain their contents. This is the retrieval-layer twin of the context leakage in LLM02, and it is depressingly easy to ship.

A subtler risk is embedding inversion: embeddings are not a one-way hash, and research has shown that a surprising amount of the original text can be reconstructed from its vector. Treat an embedding store as though it holds the source data, because functionally it does. Add to that knowledge-base poisoning — injecting crafted documents so the retriever surfaces attacker content as ground truth, the LLM04 poisoning path — and retrieval of stale or conflicting data that quietly corrupts answers.

Securing the retrieval pipeline

• Make retrieval permission-aware. Every vector carries the access metadata of its source, and every query filters to what the requesting user is entitled to — authorise at retrieval time, before documents reach the context.
• Partition by tenant. Isolate tenants at the index or namespace level rather than trusting a runtime filter alone, so a missing WHERE clause can't bridge customers.
• Treat embeddings as sensitive data. Encrypt and access-control the vector store to the same standard as the source, on the assumption that the source text can be partially recovered from it.
• Validate and govern ingested content. Vet documents entering the knowledge base and monitor for anomalous or crafted entries to blunt poisoning and stale-data drift.
• Log retrieval. Record what each query retrieved and returned, so cross-tenant exposure is detectable after the fact and provable during an investigation.

The uncomfortable pattern of LLM08 is that RAG makes data more reachable while making it less governed — the whole point is to surface relevant documents, and permissions are the first thing lost in the copy to vectors. Rebuild those controls at the retrieval layer, treat the vector store as the sensitive datastore it is, and start by knowing which of your RAG systems exist at all.