Pick where permission checks belong in a RAG pipeline with per document ACLs

MCQ·Medium·4.0 · 0·~1 min·Asked atAutodesk Locus N8n

Attempt it

RAG pipelines retrieve relevant chunks for the model to use as context. When some documents are restricted to specific users, the question is where to enforce the permission check. The wrong answer is to do it in the prompt. The model is not a security boundary. A prompt injection or a small model error spills restricted content into the response, and you find out only after a user reports it. The other wrong answer is to filter after retrieval. The global top-k is fetched, then chunks the user cannot read are dropped. The leak into the final answer is closed, but two problems remain. Recall drops because a popular restricted document can dominate the top results and leave the user with too few usable chunks. And the result count varies based on what restricted content exists near the query, which is itself a side channel revealing that something restricted is there. The right answer is pre-filtering inside the search. Index permission metadata next to the vectors. At query time, pass the user's groups as a filter so the similarity search only considers chunks the user can read. Fail closed if the permission data is stale, so the system never silently grants access on uncertain data.

**The defensible placement is inside the similarity search, before scoring.** ACL metadata is indexed alongside each vector. The user's group set is resolved at query time and passed as a filter expression. The ANN engine returns the top-k from only the authorized subset. Why the other options fail: - After generation (option A): the model is not a security boundary. Prompt injection breaks instructions; small model errors leak. The model has already seen the restricted content and cannot un-see it. - After retrieval (option B): the leak into the answer is closed, but recall is silently destroyed when popular restricted documents crowd the top-k, and the user-visible result count varies with restricted-content density, which leaks the existence of restricted documents through a side channel. - Nowhere (option D): per-department indexes fail the moment ACLs are finer than department boundaries or membership changes faster than reindex cadence. Pre-filtered retrieval avoids all three failure modes. Recall is preserved because the search ranks among authorized chunks only. The result count is stable because the search never considered restricted chunks. The model never sees content the user cannot open. Fail closed when ACL data is stale: better to return a temporary error than to serve potentially leaked content.

TL;DR

Enforce ACLs inside the vector search as a pre-filter, not in the prompt and not after retrieval. Pre-filtering preserves recall and closes the result-count side channel.

Memory aid

Easy to grasp

Think of a librarian helping you find books. If the librarian first grabs the ten best matches and then puts back the ones you cannot read, you sometimes leave with only three books, and the missing seven tell you that secret books exist on your topic. If the librarian instead checks your library card first and only searches among books you can read, you always get ten good matches and never learn the secret books are there. Now imagine asking the librarian to whisper the answer but skip secret parts. One slip of the tongue and the secret is out. RAG access control is exactly the same. Check before searching, never after, never in the answer.

Key concepts

LLM System Design Retrieval-Augmented Generation Vector Databases

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

RAG access control is one of the most consistently mishandled areas in production LLM systems. The reason is that the problem looks like it has three plausible solutions and only one of the three is actually safe. The two unsafe options feel reasonable in a whiteboard discussion and only reveal their failure modes under attack or scale.

This deep dive walks the three placements, explains the specific failure mode of each unsafe option in enough detail to defend the choice in a review, and ends with the operational details that make the safe option actually safe in production.

Why prompt-level enforcement fails

The model is not a security boundary. Saying so out loud is the first move when this option comes up.

The failure modes stack. Prompt injection: an attacker writes content that hijacks the model's instruction-following and overrides the redaction directive. Model upgrades: a new model version may comply differently with the same prompt, and the system silently degrades from safe to leaky. Stochastic error: even without an attack, the model occasionally outputs content it was instructed to redact. Side-channel leaks: even when the prose obeys, citation lists, snippet previews, and oblique references can leak the existence of restricted content.

The more fundamental issue is that the restricted content has already been placed in the context window. Whatever happens next is the model's compliance with a request, not an enforcement boundary. Compliance is statistical; enforcement is binary. They are different things, and treating one as the other is how data leaks reach the news.

Production systems treat the model layer as inside the trust boundary, not as the trust boundary itself. The model can be asked to format, summarize, or organize authorized content. It cannot be asked to keep unauthorized content secret.

Why post-retrieval filtering fails

What pre-filtering looks like in practice

Operational details that make pre-filtering actually safe

Why option D (no per-document checks) is almost never right

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Glean and Atlassian Rovo enforce ACLs as metadata filters at search time, never as prompt instructions
AWS Bedrock Knowledge Bases supports metadata filtering on vector queries so permission predicates run inside the search

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you implement the pre-filter in a typical vector database?

Most production vector databases (Pinecone, Weaviate, Qdrant, pgvector, AWS Bedrock KB) support metadata filtering as part of the query. Index the allowed-group list per vector and pass the user's resolved group set as the filter expression. Confirm the engine pre-filters rather than post-filters under the hood.

3 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Letting the model decide what to omit, or filtering top-k after retrieval. The first leaks under injection, the second leaks through visible result-count variation.

60 second bullets to scan on the way to the call.

Why prompt-level enforcement is not a security boundary
How post-retrieval filtering destroys recall when restricted content outranks authorized content

Primary sources. Browse if you want the original framing.