How would you handle access-controlled documents in RAG?
- 1 min — enforce at retrieval with the requester's permissions.
- 2 min — group ids on chunks, membership resolved at query time.
- 2 min — leaks beyond retrieval.
- 1 min — audit log and team ownership.
Permissions must be enforced at retrieval, as a pre-filter, using the requesting user's permissions resolved at query time. Store ACLs as indexed metadata on each chunk, inherited from the source document. Never filter after retrieval and never rely on the LLM to respect instructions about what not to reveal.
The hard part is that permissions change faster than ingestion runs. Two approaches: store group IDs on the chunk and resolve the user's group membership at query time (so a group membership change takes effect immediately), or sync ACL changes as priority events. Group-based resolution is almost always the better default — it moves the fast-changing part out of the index.
Name the leaks beyond retrieval: a cached answer built from a document the user later lost access to; summaries and derived content that inherit the source's sensitivity but not its ACL; conversation history replayed into a later turn after permissions changed; and the generated answer itself, which may paraphrase restricted content with no citation to filter on. Also mention the audit requirement — log which documents were used to produce each answer, because in regulated environments that log is the control.
Org scope: the identity team owns group membership (IdP / directory), source-system owners own document ACLs, and the retrieval platform owns the sync and enforcement. Write that split down — permission bugs live in the seams between those three teams.
What the answer sounds like at each level
Store who can see each document and filter results by the user's permissions.
Pre-filters on chunk-level group ids resolved at query time, keeps ACL sync as priority events, and never relies on the LLM for access control.
Covers derived content, caches and conversation history, makes per-answer document audit logs the control for regulated tenants, and assigns ownership across identity, source and platform teams.
Follow-ups the interviewer will push
1A user is removed from a group at 10:00. When can they no longer see that content?
With query-time group resolution, at their next query (subject to the IdP token/claims cache, typically ≤5–15 minutes — shorten it for sensitive groups). Also evict their cached answers and drop prior-turn context that cited now-forbidden chunks.
2A user has 4,000 group memberships. Does the filter still work?
A 4,000-term filter is slow on most engines. Precompute a compact 'principal set' per user (hashed groups, cached), use engines that support large terms filters efficiently, or partition the index by top-level ACL domain so the per-query filter is small.
Red flags interviewers listen for
- Filters after retrieval or asks the LLM not to reveal restricted content.
- Copies per-user permissions into the index, so revocations lag ingestion.
- Ignores caches, summaries and conversation history as leak paths.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Enforcement point | Pre-filter at retrieval using query-time permissions. |
| Freshness | Revocation takes effect quickly; knows the latency of each path. |
| Completeness | Covers caches, derived content, history and audit logging. |
Sources
- Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — Greshake et al., 2023paper
- Text Embeddings Reveal (Almost) As Much As Text — Morris et al., 2023paper