Securing a RAG pipeline: permissions, ingestion and what leaks if you get it wrong
A retrieval system is a search engine that answers in complete sentences. Every access control mistake it inherits becomes a confident, quotable disclosure.
By Quality AboveAll · · 9 min read
- Filter by permission inside the retrieval query, never after results are returned.
- Ingested content is untrusted input, because anything indexed can carry instructions the model will read.
- Test cross-tenant isolation explicitly, with a suite that tries to retrieve another tenant's documents.
Permission filtering belongs inside retrieval
The failure we find most often is retrieval running unrestricted, with permission filtering applied to the results afterwards. That leaks in two ways: the top results get discarded so answers degrade, and any gap in the post-filter becomes a disclosure.
Permissions must be part of the query, so the index only ever returns what this user may see. That requires permission metadata attached at ingestion time, which is why data preparation treats it as non-negotiable rather than a nice-to-have.
Permissions change, indexes forget
Access is not static. People change roles, documents are reclassified, projects close. If your index holds a snapshot of permissions from ingestion day, it will happily serve documents to people who lost access months ago.
Either re-evaluate permissions at query time against the live source of truth, or maintain an update path that propagates permission changes into the index promptly. Both are work; neither is optional in a multi-tenant or role-based product.
An index that remembers who could read a document last quarter is an access control system that runs a quarter behind your HR system.
Treat ingested content as untrusted
Anything in your corpus will be read by the model as authoritative context. If users can upload documents, or if you ingest external content, that is an injection surface, as covered in prompt injection.
Scan ingested content, be cautious about indexing user-generated material alongside official documentation, and consider separating trusted and untrusted corpora so the model knows which is which. Where both are needed, mark provenance in the context you pass through.
Protect the index itself
The vector store contains your organisation's knowledge in a form that is convenient to exfiltrate. It needs the same network isolation, authentication, encryption and access logging as any database holding the source content.
Embeddings are not anonymised data. Substantial information about the source text can be recovered from them, so treating a vector index as less sensitive than the documents it was built from is a mistake that shows up badly in a security review.
Test isolation deliberately
Write tests that attempt to retrieve another tenant's documents, that query with a user whose permissions were revoked, and that inject instructions through an uploaded document. Run them in CI so a change to retrieval logic cannot silently break isolation.
This is exactly the kind of adversarial testing our security testing practice runs on AI features, and it belongs in your own suite as well, since a regression here is a disclosure rather than a bug.
Frequently asked questions
Can we just filter results after retrieval?
No. Post-filtering degrades answer quality and turns any gap in the filter into a data leak. Permission must constrain the query itself.
Are embeddings safe to store without the source text?
Treat them as sensitive. Meaningful information about the original content can be recovered from embeddings, so they warrant the same protection as the documents.
How do we handle documents with mixed sensitivity?
Chunk and classify at a granularity that matches your access rules, and attach permission metadata per chunk. Document-level permissions on a mixed document either over-restrict or over-expose.
Running retrieval over documents with different audiences? A free 30-minute security review will test whether isolation actually holds.
