TL;DR: Copy each document's tenant and access list into its chunks' metadata at ingestion, isolate tenants in the store itself (separate indexes or enforced namespaces), and filter every query by the asking user's tenant and principals inside the search, before ranking. Keep permissions and deletions in sync with the source with a known maximum lag, re-check against the source for sensitive results, scope caches by effective permissions, reauthorize or invalidate them after access changes, and test revocation and cross-tenant access continuously. The model never decides what the user may see.
How to approach it
Split the answer into tenant isolation (between customers) and document-level permissions (between users within a customer). Then cover time: permissions change. Interviewers want to hear that authorization is enforced in retrieval, in code, and that you know where it usually breaks.
A strong answer
Filter after search
Search all chunks
every tenant
Drop forbidden results
after ranking
Scores, counts, timing still leak
Outcome, unsafe: Leaks and misses
Top-k filled with forbidden docs
Filter inside the search
ACL in chunk metadata
copied at ingestion
Query scoped to user
tenant namespace enforced
Re-check source for sensitive hits
Outcome, safe: Only permitted chunks rank
Synced deletions, access-aware caches
Tenant isolation.
- Strongest: a separate index per tenant, so a query physically cannot reach another tenant's vectors.
- Common: a shared index with a tenant namespace enforced by the vector store's access controls or a mandatory filter applied in a single retrieval service that every caller must use.
- Weak: tenant filter added in application code at each call site; one missed path exposes everyone.
Document-level permissions.
- At ingestion, record the principals allowed to read each source document (users, groups, roles) on every chunk.
- At query time, resolve the user's principals from the identity provider and pass them as a filter in the search, so ranking only considers allowed chunks.
- For highly sensitive sources, re-check the final chunks against the source system's permission API before they enter the prompt (defence against stale metadata).
Time and change.
- Subscribe to permission-change and deletion events from source systems, or re-sync on a schedule with a documented maximum lag.
- Treat group membership changes too: removing a user from a group must remove their access.
- Make deletion real: remove chunks, embeddings and cached answers.
Adjacent leaks.
- Response and retrieval caches scoped to tenant and effective permissions, with a permission version or invalidation on ACL changes. Check current access to the cached source IDs before serving sensitive answers; a stable user ID does not capture a revoked document grant.
- Conversation history scoped per user.
- Logs that contain retrieved text treated as sensitive.
Tests. Automated checks that tenant A cannot retrieve tenant B's chunks, that a revoked user loses access within the agreed lag, and that deleted documents no longer appear.
What interviewers probe next
- "Group lists are huge. How do you filter efficiently?" Index by group IDs and resolve the user's groups at query time; use the store's metadata filtering rather than post-filtering.
- "The source system has complex inherited permissions." Compute effective permissions at ingestion, record their version, and re-check for sensitive sources at query time.
- "Can the model be trusted to refuse restricted content?" No; if it is in the context it can be extracted. Restricted content must not be retrieved.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A multi-tenant SaaS adds a RAG assistant over customers' documents, which have per-document sharing settings.
Start here
Where must the permission check happen?
Once the model reads a chunk, can you stop it using it?
In retrieval, before chunks enter the model's context, using the requesting user's identity and the document's current permissions. Filtering after generation is too late, because the model has already read restricted text and can paraphrase it. The search query should only ever return chunks the user could open in the product.
Carry it forwardFilter before context, not after generation.
Weak answerFiltering the answer instead of the retrieval.
Constraint changes
What if group membership changes often?
How long after removal could a user still retrieve a document?
Stale permissions in the index leak documents to people who just lost access. Resolve group membership at query time from the identity provider, or sync with short, measured delays, and check document access again against the source of truth for the final result set when stakes are high.
Carry it forwardPermission freshness is part of correctness.
Weak answerCopying permissions at ingestion and never updating them.
Constraint changes
What if two tenants share one vector index with a metadata filter?
What happens if one query forgets the filter?
A single missed filter in any code path returns another tenant's data, and similarity search can behave unexpectedly with filters. Prefer separate indexes or namespaces per tenant, enforced by the data layer, and test that cross-tenant queries return nothing.
Carry it forwardTenant isolation should be structural, not a filter.
Weak answerRelying on application code to add the filter every time.
Constraint changes
What if answers are cached?
Would two users with the same question get the same cached answer?
A cache keyed on the question alone can serve an answer built from one user's documents to another user. Key caches on tenant, user or permission set and the retrieved document IDs, or do not cache answers that used private data.
Carry it forwardCache keys must include who asked and what was in scope.
Weak answerCaching on prompt text only.
Constraint changes
How would you test this?
How would you prove a user cannot retrieve a document?
Create test users with known, differing permissions and documents with unique canary phrases, then query as each user and assert that restricted canaries never appear in retrieval results or answers. Include permission changes and cross-tenant queries, and run the tests in CI.
Carry it forwardCanary documents and permission matrices make leakage testable.
Weak answerTesting only that authorised users get good answers.
Now defend it
How would you build and test this?
Per-tenant indexes or namespaces enforced by the data layer; retrieval filtered by the user's current permissions resolved at query time; source-of-truth checks for sensitive results; caches keyed on tenant, permissions and retrieved IDs; and a CI permission matrix with canary documents covering revocation and cross-tenant queries.
How it's scored
Weak: Puts permission rules in the system prompt or filters after generation.
Hire: Copies ACLs into metadata, filters by user before ranking and isolates tenants.
Strong Hire: Compares isolation strengths, handles change over time and deletion, re-checks sensitive results against the source, covers caches and history, and specifies tests.
Common mistakes
- Post-filtering top-k results.
- Syncing permissions only once at ingestion.
- Shared caches across users.
- Treating the index as less sensitive than the documents it was built from.