RAG Access Control: What Happens After Document Permission Is Revoked?

A document is removed from an employee’s access group at 10:00. At 10:01, an assistant answers their question using a chunk indexed yesterday. The retriever found relevant text. The product disclosed information the person should no longer receive.

This failure is easy to miss when a retrieval evaluation measures relevance but never changes permissions. The question is not only whether access control exists. It is when an access change becomes effective across documents, chunks, retrieval, generated answers, caches, and conversation history.

This guide proposes a serving contract for permission-sensitive RAG. The product must choose its acceptable revocation window. No vector similarity score can make that decision.

Identify every authorization boundary #

Start with the complete path:

identity -> entitlement resolution -> filtered retrieval
         -> source authorization -> prompt construction
         -> generation -> answer delivery -> answer history

A permission change can race with any stage. Filtering the initial query does not automatically authorize a stored answer replayed an hour later. Deleting a search record does not necessarily remove a cached response or an attachment already delivered to the client.

The system should preserve provenance through these stages. For each chunk, retain a stable source identifier, tenant boundary, content version, and relevant authorization version. For each answer, record which source identities contributed to it.

Provenance supports enforcement and investigation. It is not permission by itself.

Distinguish filters from an authorization service #

Microsoft documents a security-filter pattern in which indexed principal identifiers are matched against the caller’s authorized identities. Such a pattern depends on the application supplying the correct filter and identity context.

Build that context on the trusted server. Do not accept a tenant ID or group list from a browser and assume it is authoritative. Require every retrieval path to use the same authorization boundary, including fallback lexical search, related-document lookup, and citation expansion.

Microsoft also documents query-time ACL and RBAC enforcement. Availability and prerequisites depend on the specific service feature and data source. Verify those details before treating a provider capability as a general guarantee for every index.

The design review should name the component that actually enforces access and the state it consults.

Give revocation a measurable contract #

Suppose entitlement caches can remain stale for E seconds and indexed ACL updates can lag by I seconds. The effective exposure window depends on the architecture: one path may require both to be current, another may recheck the authoritative source before using retrieved text.

Do not blindly add these values or take their maximum. Draw the sequence and identify which stale view can independently authorize disclosure. Then test the worst permitted propagation path.

For sensitive material, an authoritative check immediately before prompt construction can reduce reliance on stale indexed ACLs. It also adds latency and a dependency to the serving path. If the authority is unavailable, a fail-closed policy may reduce answer availability.

For less sensitive material, a documented bounded-staleness policy may be acceptable. State the window to the product and security owners. “Eventually consistent permissions” without a bound is not a useful operating contract.

The generation race needs a decision #

Imagine authorization succeeds, generation begins, and access is revoked before the answer is delivered. There are at least two coherent product policies.

One permits completion under the authorization decision made at request start. Another requires authorization to remain valid at delivery. The second policy may need revalidation, output buffering, or cancellation support.

Streaming complicates the second policy because already delivered tokens cannot be recalled. If the product needs a strict delivery boundary, buffer the response until the final check or define exactly what ongoing streaming is allowed to disclose.

Label this as a product decision with an implementation cost. Do not advertise immediate revocation if the serving architecture knowingly permits already authorized generations to continue.

Design answer caches around provenance #

A cache entry keyed only by the question can bypass all the retrieval protections. Another user’s answer may contain restricted information, even when both people ask identical questions.

A proposed cache record might include:

{
  "answerId": "answer-example-28",
  "tenantId": "tenant-4",
  "authorizationScope": "scope-version-19",
  "sources": [
    {
      "documentId": "document-8",
      "contentVersion": "v6",
      "authorizationVersion": "acl12"
    }
  ],
  "requiresRevalidation": true
}

This is an application design example, not a vendor schema.

Before serving a cached answer, establish that the current principal may receive every source-derived part of it under your policy. If any source has become unauthorized, regenerating from the permitted set is often simpler than trying to surgically remove leaked facts from an already generated answer.

Permission-scoped cache keys reduce accidental sharing, but stale scopes still need expiry or invalidation. The broader cache boundary is discussed in shared cache keys and data isolation.

Retrieval quality must be measured after authorization #

Permissions change the candidate population. A query that retrieves excellent global neighbors can perform poorly for a person allowed to see only a small subset.

Azure documents different vector filtering modes, including effects on recall. Choose and evaluate the mode using the deployment’s supported features and the actual authorized population.

Post-filtering unauthorized results is not permission to put those results into the prompt first. The enforcement boundary must precede model exposure. If the permitted result set lacks evidence, return an insufficient-evidence response rather than quietly broadening access.

Failure policy and tests #

Create a test corpus with two tenants, shared documents, group changes, and a restricted source containing a distinctive phrase. Test retrieval, answers, citations, cache hits, exports, and resumed conversations. Observe whether the phrase appears anywhere outside its authorized context.

Measure revocation propagation time, denied-source retrieval attempts, cache revalidation failures, and answers with incomplete provenance. Keep document contents and sensitive identifiers out of broad operational logs.

The architecture decision #

Permission-aware RAG is a continuing authorization workflow. Indexing-time checks are one input, and the model is not the policy engine.

A review is ready when the team can state who enforces access, which copies may be stale, how long revocation can take, and what happens to an answer already in flight. Those answers are part of the product’s security contract, alongside its relevance and latency targets.

References #

• Azure AI Search security filters
• Query-time ACL and RBAC enforcement
• Vector search filtering modes
• Related: retrieval evidence