cswork / libraryOpen practice workspace

Articles

RAG Access Control Interview Questions: Permissions, Revocation, and Retrieval Leaks

Prepare for RAG access-control interviews with retrieval-time authorization, permission-aware indexing, revocation, caches, citations, and adversarial tests.

A RAG assistant can answer with text the caller is not allowed to read even when the source application has perfect permissions. The leak happens when indexing, retrieval, caching, or generation loses the relationship between a chunk and its authorization policy.

The interview is therefore about more than adding a role check to the chat endpoint. You must establish the principal, restrict retrieval before content enters the prompt, handle revocation across derived artifacts, and prove the boundary with negative tests. Practise the broader architecture with Design an enterprise RAG assistant for internal docs.

Evidence boundary: Microsoft officially documents document-level access patterns for Azure AI Search and recommends applying access control at retrieval time for RAG. NIST supplies general zero-trust principles. The architecture, timelines, and test matrix below are editorial designs, not claims that one vendor implements every control.

Where should authorization happen?

Authenticate the user or workload at the application boundary, but authorize each retrieval against the resource policy. A valid login proves identity; it does not prove access to every indexed chunk. Carry a stable principal, tenant, group or entitlement context, and policy version through the request.

Enforce the filter before the retriever returns content to the prompt builder. Microsoft describes security-filter patterns in which user or group identities are compared with permission metadata, excluding nonmatching documents. Some native identity-aware features are preview capabilities, so the interview answer should distinguish a general design pattern from a particular service's release status.

Do not retrieve broadly and ask the model to ignore forbidden text. Once the text enters the prompt, it can influence the answer, citations, tool calls, or logs. A post-generation redactor does not erase that exposure.

What permission metadata belongs in the index?

Every retrievable unit needs a resource identity and policy linkage. Store tenant, source document ID, chunk ID, policy or ACL version, allowed principals or groups where appropriate, sensitivity class, source modification time, and tombstone state. Keep provenance so a citation resolves to the same authorized resource.

Choose chunk semantics carefully. If one chunk combines paragraphs with different permissions, filtering at document level may be too coarse. If permissions inherit from folders or spaces, preserve the inheritance source and update it when the hierarchy changes. Avoid expanding enormous group memberships into every chunk without a plan for fan-out and updates.

The embedding is also a derived artifact. Even if vectors are not directly human-readable, the vector store and nearest-neighbor responses belong inside the security boundary. Backups, replicas, evaluation datasets, prompt traces, and caches need compatible controls.

Push permissions into the index or evaluate them at query time?

Materializing allowed group IDs on each document makes retrieval filters fast and explainable, but group changes can require broad reindexing. Storing a policy reference and consulting an authorization service reduces duplication but adds latency and availability dependence. Partitioning by tenant or sensitivity reduces blast radius but can multiply indexes and operational cost.

A hybrid is common: hard tenant isolation, coarse index filters, and a current policy decision for the final candidates. The exact design depends on policy complexity, update rate, query latency, and the search engine's filter capabilities.

State the failure mode. If the policy service is unavailable, protected retrieval should fail closed or use a deliberately bounded, recently validated decision cache. Returning unfiltered results because authorization timed out converts an outage into a data breach.

How should revocation propagate?

Treat revocation as an event with a measurable deadline. When a user loses a group or a document changes classification, emit a policy-change event. Update or tombstone affected index entries, invalidate retrieval and answer caches, and advance a policy version. Queries compare their authorization context with that version or consult a current decision.

Define the maximum exposure window. “Eventually consistent” is incomplete unless you say whether the target is seconds, minutes, or a scheduled rebuild and what the product does before convergence. For high-sensitivity content, synchronous removal or a deny overlay may be required while the index catches up.

Test the race: user A can retrieve document D; access is revoked; an old query result, semantic cache entry, conversation memory, and generated answer must not return D. The audit should show which policy version authorized each retrieval.

What caches can leak data?

A cache key based only on normalized question text is unsafe. Two users can ask the same question with different permissions. Include tenant and an authorization scope or policy fingerprint, plus corpus and model versions. Better, cache authorized evidence IDs and reauthorize them before reuse when revocation requirements are strict.

Conversation memory is another cache. A user may change roles during a long session, or a shared conversation may be opened by someone else. Reauthorize cited resources on every turn and prevent hidden context from crossing tenant or principal boundaries.

Logs can become a shadow corpus. Avoid recording full protected chunks by default. Apply access controls and retention to traces, evaluation samples, thumbs-up exports, and debugging dashboards. Redaction is useful, but minimization and controlled access are stronger boundaries.

How do prompt injection and access control interact?

Treat retrieved documents as untrusted input. A document can contain instructions asking the model to reveal other context or call a tool. Access control decides which content may enter the prompt; instruction hierarchy and tool authorization limit what that content can cause.

Tool calls require fresh authorization on the requested action and resource. Do not let the model's statement “the user is an administrator” become a credential. Bind tools to the authenticated principal and validate structured arguments server-side.

Prompt-injection defenses do not replace retrieval filters, and retrieval filters do not eliminate injection. The interview answer should keep the controls separate so each failure has a clear owner and test.

What should the request path look like?

  1. Authenticate the caller and establish tenant, principal, groups, and session context.
  2. Build an authorization constraint from trusted identity data, not model output.
  3. Retrieve only candidates allowed by that constraint; optionally recheck top results with the policy service.
  4. Package authorized text with provenance and treat it as untrusted data.
  5. Generate an answer; authorize any tool action independently.
  6. Return citations only if the caller can still open the source.
  7. Record policy version, evidence IDs, and decision outcome without copying sensitive content unnecessarily.

Include a bounded fallback. If the permission-aware retriever fails, return no protected answer or use an approved public corpus. A generic model response must not pretend it was grounded in inaccessible documents.

Which tests demonstrate the boundary?

Create two tenants, two users, nested groups, one public document, one private document, and one document whose access changes. Test exact queries, paraphrases, follow-up turns, citations, autocomplete, and semantic cache hits. Assert that forbidden document and chunk IDs never appear in retrieval traces or prompts.

Run revocation tests during concurrent traffic. Delay the index update, warm every cache, remove a user from a group, and measure the last possible exposure. Test restoration separately; a denial cache that survives a legitimate grant is an availability bug, while an allow cache that survives revocation is a confidentiality bug.

Add adversarial documents that request secrets or tool actions. The expected outcome is both permission-safe retrieval and tool denial. Measure unauthorized retrieval rate as a hard security metric, alongside answer quality, latency, and abstention.

How should you discuss trade-offs?

Name the protected asset, trust boundaries, consistency target, and failure policy before choosing services. Then compare index-time ACL expansion, query-time policy checks, tenant partitioning, and hybrid filtering by latency, update cost, policy expressiveness, and blast radius.

Be precise about preview features and vendor behavior. Azure's official documentation, for example, distinguishes security filters from identity-based document authorization features that may be in preview. A portable answer describes the invariant—unauthorized chunks do not enter the prompt—then maps it to the chosen stack.

Practice related RAG design questions

The records below train architecture and evaluation reasoning. They do not establish that every employer asks an access-control variant.

QuestionPractice focusWhy it helps
Design a RAG-Based Agent SystemAgent architectureAdds tool and identity boundaries
Design enterprise RAG search systemEnterprise retrievalMakes permissions and tenancy concrete
Design an enterprise RAG assistant for internal docsInternal knowledgeExercises citations and source access
Evaluate RAG System Accuracy and Cost Control StrategiesEvaluationAdds security tests to quality metrics
Design an ML search system with RAGSearch designConnects filtering with retrieval quality

The decisive principle is that authorization is part of retrieval correctness. If a chunk is not authorized for the current principal at the current policy version, it cannot be context, a citation, or a cached answer.

Build a permission test matrix before choosing a vector database

Create rows for anonymous user, employee, group member, document owner, administrator, recently revoked user, and service principal. Create columns for keyword search, vector search, hybrid search, answer text, citation open, conversation follow-up, semantic cache reuse, export, and tool call. Every cell needs an expected allow or deny result and an audit event.

This matrix exposes inconsistent paths. Keyword search may apply a filter while vector search forgets it. The answer may be safe while autocomplete leaks a title. A citation may render even though opening the source now fails. An administrator path may bypass document checks without producing the required audit record.

Run the matrix against two tenants and after every permission transition. Seed a unique canary phrase in each protected document so accidental retrieval is observable without using real secrets. Store only the evidence IDs needed for the test, and clean the fixture afterward.

In the interview, distinguish prevention from detection. Query-time authorization and fail-closed behavior prevent exposure. Policy-version logs, canary alerts, and unauthorized-retrieval metrics help detect regressions. Both are necessary, but monitoring is not permission enforcement. Finish by naming the owner and service-level objective for revocation so the security requirement can be operated rather than admired on a diagram.

Include deletion and legal-hold cases. Removing a source should remove or tombstone its chunks, cached answers, evaluation copies, and summaries according to policy. A legal hold may retain the source while denying ordinary retrieval. These are lifecycle states, not one deleted flag.

Test identity changes during a request. If a query starts before revocation and finishes after it, define which policy version controls the result. High-risk systems may reauthorize final evidence immediately before generation or response. The choice must be explicit and measurable. Include this race in release tests under load, because a happy-path permission check cannot expose it.

Sources and Further Reading