RAG Access Control: What Happens After Permission Is Revoked?

Enforce document access before content reaches a model or another downstream processor that is not authorized to receive it. Then apply the same policy to cached answers and conversation history. A filter on fresh vector searches does not cover a response served without a new search.

For a document assistant, “we use metadata filters” is the beginning of the review. The harder question is what happens when someone leaves a project, a document becomes restricted, or an existing conversation changes audience.

This guide gives you a revocation checklist and test matrix. It is a documentation-based design review, not a tested RAG implementation or a claim that a particular product leaks data.

Separate identity, eligibility, and freshness

Three questions belong in the request path:

• Identity: Who is requesting the answer, for which tenant and audience?
• Eligibility: Which source records may that identity use for this operation?
• Freshness: Which version of the permissions produced that decision?

Microsoft’s security-filter pattern is string matching. The filter value is not itself authentication. Your application must establish the caller and supply the correct filter on each relevant query; a user-provided group name is not proof of membership. Azure security-filter pattern

Supabase demonstrates a different enforcement location: Postgres row-level security can restrict section retrieval according to the linked document’s owner. That also applies to similarity queries when they execute under the intended user context. Its example is not a complete multi-tenant policy for every application. RAG with Permissions

Check the actual database role and identity propagation, not just the policy’s presence. Supabase documents roles and service keys that can bypass RLS, and notes that authorization data in JWTs can remain stale until the token refreshes. This matters when a backend service uses broader credentials than the person asking the question. Row Level Security

A current query can still use old permissions

Azure’s native token-based document checks use permission metadata stored in the index. The overview explicitly ties enforcement to synchronization and describes different source-specific refresh mechanisms. The native ACL/RBAC capabilities discussed there are marked preview; the page references the 2026-08-01-preview API. Do not equate “checked at query time” with “checked against the source’s latest state.” Document-level access overview

For your own system, write down the revocation contract. A useful contract names:

1. The authoritative permission store.
2. The event that starts revocation, such as a committed membership removal.
3. The point after which new requests must be denied.
4. The treatment of requests already in progress.
5. The behavior when permission freshness cannot be established.

Those are product and security decisions, not numbers to copy from a tutorial. If your requirement is stronger than an index’s synchronization behavior, consider an authoritative authorization check on candidate IDs before releasing their content, or a correctly synchronized deny mechanism. Both require implementation and testing. A version field alone does not help if you never compare it with an authoritative version.

Follow every route into the answer

Conceptual review map. The authorization decision may be implemented in several services; the diagram does not prescribe one database or claim atomic revocation.

Consider a fictional assistant for project documents. On Monday, a user can read a launch plan and asks for a summary. On Tuesday, that access is removed. A fresh search correctly excludes the plan, but the assistant may still have two other inputs: Monday’s cached summary and the previous conversation supplied as context.

Our design recommendation is to make those derived artifacts reviewable, rather than treating them as harmless text. Retain the source identifiers and policy context needed to decide whether reuse is allowed. Protect that metadata too: document titles and identifiers can themselves reveal sensitive information.

Route	Review question	Conservative behavior when authorization is unknown
Fresh retrieval	Are tenant, identity, source status, and current permissions checked before unauthorized downstream disclosure?	Exclude the candidate; do not ask the model to decide access
Cached answer	Can every contributing restricted source still be used for this recipient?	Treat it as a cache miss and rebuild from eligible sources
Conversation history or summary	Can old restricted content be supplied again under the current audience and policy?	Omit or regenerate affected context; do not reuse an unverifiable summary
Citation, preview, or download	Does opening the supporting object perform its own access check?	Deny the object; hiding the citation label is insufficient

Microsoft’s semantic-cache policy retrieves answers by prompt similarity and recommends user or group partitioning to control cross-user reuse. That recommendation is not a guarantee of same-user revocation handling. LLM semantic-cache lookup

This is application answer caching, not merely the provider prompt caching covered in our cache-cost guide. A cache key containing a user ID can prevent some cross-user collisions, but it does not notice that the same user’s access changed. A time-to-live also permits reuse until expiry unless another check intervenes.

Not every prior message must disappear after every membership change. Decide whether your policy allows continued viewing of a previously authorized transcript, prohibits reuse in new answers, or requires both removal and non-reuse. State that distinction to users. Revocation cannot make a person forget information already received or retract copies outside your control.

Test revocation without a real secret

Use fictional documents with unique markers and two test identities. Observe the content handed to downstream components, not only the final answer: a model can omit a marker despite receiving it. The following are proposed fixtures, not results we measured.

Fixture	Expected behavior under a no-new-use-after-revocation policy
Warm the cache, revoke access, repeat the same question	No answer reused from the revoked source; eligible alternatives may still answer
Reopen an old conversation after revocation	Revoked source text is not reintroduced into a new model request
Revoke while index updates are paused	The documented freshness boundary is respected, or the request fails closed
Remove a group membership while an old token exists	The identity/token freshness rule produces the documented denial point
Start a request before revocation, finish afterward	The explicit in-flight policy is followed; no accidental timing guarantee
Ask the same question from another tenant	No cross-tenant cache, snippet, citation, or document reuse
Make the permission service unavailable	Unknown access is not silently treated as allowed

Keep answer quality separate from authorization. Denying everything can pass a leakage fixture while making the assistant useless. Include allowed-document controls, and measure whether authorized relevant passages survive retrieval. Do not relax permissions just to refill a top-k result set.

Before shipping, identify the owner of each reuse path and one test that exercises it after revocation. Record the effective identity, policy/version reference, source IDs, and decision where appropriate, with restricted log access and minimal retention. Avoid logging full restricted prompts by default. For the next boundary, see why valid structured output still needs independent validation.