How Do You Stop a RAG Assistant Revealing Documents After Access Is Revoked?

Revoking access to a document must also stop future disclosures through the assistant that the changed policy no longer permits. I would enforce the changed policy before protected material crosses each relevant service boundary, and before a cached or newly generated answer is released. That requires current identity and permission information, traceable source versions, and explicit handling of stored conversations and work already in flight. Removing someone from a folder while leaving the assistant's other access paths untouched is an incomplete revocation.

There is an unavoidable limit: you cannot retract information someone has already received. You can govern future service behavior, restrict retained copies and investigate an exposure. Those are different claims. My question here is narrower and testable: after the system acknowledges a revocation, what prevents another protected disclosure through retrieval-augmented generation, or RAG?

A useful answer needs more than a setting called “permission aware.” It needs an account of which policy the system evaluates, how fresh that decision is, and which outputs it covers. The analysis below develops a proposed design and acceptance method from access-control research, standards and provider documentation. Its timing example and test cases are hypothetical; no customer assistant or production tenant was tested.

Define the disclosure that revocation must stop

Start by naming the recipient and the operation. A user reading an answer, a reranking service processing candidate passages, and a model provider receiving a prompt are different recipients. Your organization may authorize a trusted retrieval service to inspect the corpus while forbidding another component from seeing restricted passages. “The model didn't print the secret” is not sufficient evidence that those boundaries held.

I would distinguish three commitments. First, newly admitted requests must use permission information that incorporates the relevant revocation. Second, pending work must meet a stated release rule before its output leaves the service. Third, stored answers and conversation context must have an explicit reuse policy. If the product promises only the first commitment, it should not advertise the stronger protection implied by all three.

This is an old protection problem with a new distribution path. Saltzer and Schroeder (1975, Part I, §A) describe complete mediation, including the danger of remembered access decisions when authority changes, and fail-safe defaults based on permission. Their principles do not prescribe a RAG implementation. They do explain why an ingestion-time decision cannot automatically authorize every later use of the derived material.

A revocation also needs a completion event. The source may acknowledge an ACL update before downstream components receive it. I would record “source policy updated” separately from “assistant revocation barrier established.” The latter should mean that every in-scope path either enforces the changed decision or is prevented from serving the affected information. A green source-system response must not silently stand in for a downstream guarantee.

Bind the decision to the right person, object and action

NIST's ABAC definition evaluates subject attributes, object attributes, requested operations, environment conditions and policy (Hu et al., 2014, §2.2; updated 2019). That is a useful starting vocabulary. For this assistant, I would bind the decision to the authenticated subject, tenant, source object, source version, requested use and relevant policy revision. A chunk identifier alone is a poor substitute for that relationship.

Consider a connector running under an account that can read every department's files. Its ingestion permission establishes what the connector can collect. It does not establish what any employee can ask the assistant to disclose. The application must preserve the distinction between service access and the requesting person's entitlement. Otherwise the connector's broad capability becomes a route around the source's narrower rules.

I would also identify who may assert each attribute. The browser should not be able to select another tenant or supply its own list of privileged groups. A document's text should not be able to redefine its classification. The trusted application needs to derive identity and policy inputs from designated authorities, validate their scope, and reject ambiguous mappings. A correctly evaluated rule still produces the wrong result if its inputs describe the wrong person.

This connects to making data classification enforce actual access rules, but the remaining problem is temporal. The mapping may have been correct yesterday. Today the person has changed teams, the folder has moved, or inherited permissions have changed. A sound design must explain how those events alter the next disclosure, including when the source and index disagree.

A search filter is only as trustworthy as its inputs

Microsoft's documented security-filter pattern for Azure AI Search uses principal identifiers as strings in an OData filter. The documentation explicitly distinguishes that pattern from authentication and authorization through the principal itself; it also points to separate built-in ACL support (Microsoft, 2026b, “About the security filter pattern”). I am discussing the string-filter pattern here, not claiming that every Azure permission mechanism behaves identically.

For an application using that pattern, I would keep filter construction inside the trusted service. The application should derive permitted identities from its validated security context, constrain the requested corpus, and prevent callers from replacing or omitting the security predicate. It should also reject a search response that cannot be associated with the intended policy and tenant. A filter supplied by an untrusted caller is a search preference, not an adequate security boundary.

Filter placement introduces a separate retrieval issue. Azure documents prefiltering, filtering after per-shard vector selection, and strict filtering after global top-k selection; strict postfiltering is marked preview. Postfiltering can produce false negatives for selective predicates or small candidate sets (Microsoft, 2026a). These are search-processing semantics. They do not establish that the filter expresses current authorization.

The operational consequence is easy to miss: a safe filter may return fewer useful results, and someone may propose removing it to restore answer quality. I would instead investigate retrieval configuration, corpus coverage and permission accuracy. Returning an honest insufficient-evidence answer is preferable to expanding the user's authority as an undocumented fallback. Measure useful authorized retrieval separately from successful denial; either can fail while the other looks healthy.

Keep content and permission changes in the right order

A continuously running index is not necessarily a consistently authorized index. Imagine that a manager removes a reader from a project and then adds a confidential update. A worker can ingest the new content while another worker still holds the previous permissions. The assistant then evaluates fresh information under an obsolete entitlement. Fast ingestion has made the exposure easier, not solved it.

Pang et al. (2019, §2.2) call related ordering failures the “new enemy” problem. Zanzibar uses consistency properties and content-associated tokens so access checks do not evaluate new content against authorization state older than the required causal point. The paper's protocol depends on cooperation between the authorization system and its clients; storing an arbitrary timestamp beside a chunk does not reproduce it.

My design requirement would be to preserve the source-content and policy relationship through extraction, chunking and indexing. If a document version arrives without a trustworthy authorization association, hold it out of the answer path. If an old ingestion retry arrives after revocation, it must not restore an older permission state merely because the job completed successfully. Ordering needs to survive retries and reprocessing, not only the normal happy path.

A content-associated revision alone is also insufficient for every revocation promise. A later permission removal may occur without any content update. The next check must incorporate that later event when the product claims it does. I would distinguish the minimum revision needed to interpret a content version safely from the minimum revision required by the current revocation barrier. Losing that distinction can leave unchanged documents accessible after membership changes.

For implementation specificity, Authzed documents SpiceDB's at_least_as_fresh checks using a ZedToken, while minimize_latency can favor cached state. Its documentation also warns that fully_consistent does not guarantee read-after-write consistency with CockroachDB and directs that case toward a ZedToken-based approach (Authzed, n.d., “Levels”). The practical lesson is to verify actual datastore and API semantics. A reassuring consistency-mode name is not evidence that your application observes the removal it just acknowledged.

Budget staleness across the whole path

The word “current” needs an operational definition. Membership information may be cached at login, the index may lag the source, and an answer may be reused without another retrieval. I would inventory each such decision point, its authority, its refresh behavior and its failure mode. Only then would I choose an acceptable revocation interval for the corpus and reader task.

NIST's zero-trust tenets require dynamic authentication and authorization before resource access, with policy-driven reevaluation during transactions (Rose et al., 2020, §2.1). They do not supply one universal timeout for assistants. RFC 7662 provides a more specific example: caching OAuth token-introspection responses can leave a window in which a revoked token is accepted, trading freshness against load (Richer, 2015, §4). Token validity and document permission remain separate checks; neither automatically proves the other.

Consider a hypothetical design where source-permission propagation can take 90 seconds. At 89 seconds, a worker still observes the old allow decision and stores it for another 120 seconds. It can then authorize an answer at 208 seconds, just before that cached decision expires, and store the answer for 300 seconds without further checks. That answer could be served until just before 508 seconds after the original change: approximately eight minutes and 28 seconds.

Those numbers are illustrative, not a recommended timeout or a measured product result. The example assumes each later cache can be filled from an earlier stale allow, and that the answer path performs no fresh release check. It demonstrates why taking the largest individual timeout, 300 seconds, would understate this particular path. A conservative sum of the three stated maxima is 510 seconds before other delays; an unbounded conversation-reuse path would defeat even that bound.

Your actual architecture may behave differently. Independent caches refreshed from an authoritative revision can have a different relationship, and a final decision that incorporates the revocation can stop disclosure despite stale upstream artifacts. I would model permitted transitions rather than automatically adding every timeout. Include scheduler delay, retries, stalled workers and unavailable authorities in the analysis. A bound that assumes they never fail is a normal-operation estimate, not a robust completion promise.

Treat answer reuse as another protected read

Partitioning an answer cache by user prevents some cross-user reuse, but it does not handle the same user losing permission. The cache key still matches. I would associate a reusable answer with the source objects and versions that contributed to it, then require the relevant authorization decision again before serving it. Where reliable dependency tracking is unavailable, avoid reusing protected answers across permission changes.

A citation list is not automatically a dependency record. The model may have used a passage without citing it, or a summary may have combined several chunks. My conservative design would retain the provenance of all protected inputs that could have influenced the stored result. That can over-restrict reuse, which is an explicit availability cost. It is still preferable to claiming a precise dependency map that the generation process never produced.

HTTP cache controls address another layer. RFC 9111 restricts shared reuse of responses to requests carrying an Authorization header unless specified directives permit it, defines no-store, and discusses application caches above HTTP separately (Fielding et al., 2022, §§3.5, 5.2.2.5, 6). Setting an HTTP response header does not, by itself, implement permission invalidation inside a semantic answer cache or conversation store.

I would therefore inspect each cache independently: retrieval results, authorization decisions, generated answers, browser delivery and any application history. For each, ask whether revocation triggers deletion, invalidation, fresh authorization or temporary suspension. Deleting a cache entry may be operationally useful, but concurrent workers can recreate it from stale inputs. An invalidation event needs a barrier against such repopulation if the system claims completion.

The same concern applies to broad cache keys such as “same question, same department.” Department membership may change, and two people in one department may hold different document permissions. Shared reuse requires an authorization basis for the actual recipient and contributing sources. Similarity between questions is a relevance judgment; it cannot establish equivalent access rights.

Decide what happens to conversations and work already running

A new retrieval query can deny access while a resumed conversation still sends the old passage back to the model. I would treat retained context as an input requiring a reuse decision. For protected conversations, store enough source provenance to reconstruct an authorized context, or suspend continuation when that provenance cannot support the promised boundary. Simply hiding an old citation leaves its content available elsewhere in the prompt.

Historical display and future model reuse need separate product decisions. An organization might allow a person to retain previously delivered correspondence while prohibiting the assistant from generating new answers from the underlying revoked source. Another may require the application to stop displaying retained protected history. State the chosen behavior and enforce it at the application. Neither choice can erase a screenshot, downloaded response or information already learned by the recipient.

In-flight requests create a race between checking permission and releasing information. A check at request admission can precede the revocation; generation may finish afterward. For a strong post-acknowledgment promise, I would coordinate revocation with output admission: block or cancel affected pending work, establish the new authorization barrier, and acknowledge completion only when the defined release paths comply. A check immediately before release narrows the race but is not an atomic guarantee unless the implementation coordinates those operations.

Streaming makes that commitment more demanding. Bytes already delivered cannot be recalled, while buffers and downstream components may still hold unsent output. The release contract must define which endpoint counts as delivery and what cancellation can actually stop. For a high-consequence corpus, buffering until a final controlled release may be justified. Where streaming remains necessary, document the interruption boundary and residual exposure instead of promising retrospective secrecy.

Permission to read a source also differs from permission to execute an instruction found inside it. That separate problem is addressed in preventing agents from acting on instructions in documents. Combining the two into one vague “AI guardrail” makes it difficult to tell whether a failure came from unauthorized retrieval or an authorized document inducing an unauthorized action.

Test transitions, including cases that should still work

I would build a controlled corpus with harmless, distinctive markers and known expected permissions. Include an authorized account, an initially unauthorized account and a user whose access will change. Use separate objects for direct grants, group-derived grants and inherited folder permissions. Keep the test environment isolated, and avoid real confidential material merely to make the demonstration convincing.

The test must observe intermediate boundaries, not only the final sentence. Capture which source versions were selected, which policy revision authorized them, whether protected text entered a reranker or model request, and whether a cached response bypassed evaluation. Record identifiers and decisions by default; restrict any deeper synthetic traces. A refusal in the visible answer can conceal an earlier unauthorized transfer.

These are proposed acceptance cases, not results from an executed test suite:

Transition	Required observation	Failure that a final-answer-only test can miss
Never authorized	Protected source excluded at the defined boundary; permitted source still usable	Model receives restricted text but declines to quote it
Grant, then revoke direct access	Post-barrier request denies the removed entitlement	Index keeps an ingestion-time allow
Remove group membership	Effective subject membership incorporates the removal	Old session claims preserve access
Revoke, then update content	New content is never checked against pre-removal authority	Fresh chunk paired with stale permissions
Revoke after an answer-cache hit	Reuse rechecks dependencies or becomes unavailable	Same-user cache key returns the old answer
Resume a protected conversation	Context reconstruction follows the stated history policy	Old retrieved material reenters the prompt
Revoke during generation	Delivery follows the declared in-flight contract	A preapproved request releases after acknowledgment
Interrupt policy lookup or event delivery	Affected protected path denies or holds; recovery preserves ordering	Timeout fallback or delayed retry restores access

A negative result is meaningful only if the test could have retrieved the material. Establish that the marker is indexed and available to the authorized control under the same query conditions. Then make the permission transition and repeat. Otherwise a broken connector, poor retrieval or an empty corpus can produce a reassuring absence without testing authorization at all.

I would repeat the selected transitions across the actual query paths: vector, keyword or hybrid retrieval, direct source previews, cached answers and conversation continuation where present. Include a request attempting to substitute another tenant or group filter. Test the failed lookup, delayed event and replay path as deliberately as the successful removal. Report tested combinations explicitly; a handful of cases cannot establish coverage of every connector and permission model.

A completion record should identify the revocation event, affected object or group, accepted policy revision, enforcement paths and observation interval. I would keep source acknowledgment, assistant acknowledgment and final release observations as separate events. Wall-clock timestamps help reconstruct the sequence, but a timestamp alone does not prove that a worker consumed a particular policy change. Where available, carry the authoritative revision or event identifier through the trace. Label uncertainty rather than inferring causality from two nearby log times.

Recovery deserves its own acceptance decision. After an interrupted policy service returns, clearing the outage alarm should not immediately reopen a corpus if queued workers still hold old allow decisions. I would verify the barrier, discard or revalidate pending protected results, and check that late retries cannot overwrite the newer state. Then rerun an authorized positive control as well as the denial case. Otherwise a system that has become permanently unusable can appear to have achieved perfect revocation.

Privacy remains wider than a correct ACL

OWASP's LLM08:2025 guidance identifies unauthorized access and cross-context leakage in vector-based systems, and recommends fine-grained controls and separation between user groups (OWASP Foundation, 2025). That supports treating the vector store as a protected component. It does not establish that every permitted use of the retrieved information is appropriate, or that every permission-aware product implements equivalent safeguards.

Embeddings also need their own boundary. Morris et al. (2023) demonstrate text reconstruction under studied conditions, including black-box access to the embedding model. Their limitations discuss the short sequence lengths investigated and the unexamined limits for longer text. The warranted conclusion is that a vector representation is not automatically anonymous. The paper does not establish universal reconstruction of every document or provide a measured leakage rate for your assistant.

I would consequently include embeddings, extracted chunks, support exports and debugging traces in the data-flow review. Revoking one user's answer access does not necessarily revoke an operator's administrative access or erase a vendor's retained copy. Those recipients need separate authorization and retention decisions. Keep the access-revocation evidence distinct from deletion evidence so that success in one does not falsely close the other.

NIST's generative AI profile also discusses sensitive inferences assembled from multiple sources and privacy harms beyond direct disclosure of training data (Autio et al., 2024, §2.4). A user who may read several documents can still obtain a new, sensitive synthesis through aggregation. I would ask the data owner whether the assistant's purpose and combinations are acceptable before broad ingestion. A correct access check cannot make that governance decision on its own.

Choose a defensible tradeoff, then state its limits

The strongest objection is operational: fresh authorization, dependency tracking and coordinated release add latency and failure modes. A small assistant serving public manuals does not need the same controls as one serving confidential personnel records. I would match the commitment to the corpus, consequences and service requirements. The design should earn its complexity through a specific disclosure risk, not through a fashionable architecture diagram.

An asynchronous model can be reasonable when the owner knowingly accepts a bounded delay. Its acceptance record should identify when the interval begins, what propagates within it, which paths are excluded, and what happens if the deadline is missed. “Eventually consistent” alone provides no deadline. If the assistant cannot establish the required state, I would suspend the affected corpus or permission path while preserving independently authorized work.

A second objection is that withholding an answer can harm operations. That matters, particularly where people rely on the assistant for time-sensitive instructions. The answer is to design an authorized fallback in advance: a separately maintained public corpus, an approved reference channel, or escalation to an accountable owner. A fallback that silently drops the security constraint changes the access policy at the moment its enforcement is least reliable.

This paper is a design synthesis, not a formal proof, product certification or empirical comparison. Its proposed cases do not cover every side channel, compromised administrator, model-training path or vendor retention arrangement. Provider documentation can change, and implementation behavior must be checked against the deployed version. Source-level consistency features only help when the application preserves their assumptions across its own components.

The decision I would put in front of a release owner is concrete: which revocation commitment are you making, which paths implement it, and what evidence shows they do? A signed-off boundary, a traced data path and observed transition results are useful. An answer that happened to omit a secret once is not enough to support that claim.

If you need to establish that boundary for an internal assistant, request a RAG authorization and privacy briefing. I would start with one protected corpus and one grant-to-revocation path, then scope the gaps across retrieval, caches, context and release. Bring a sanitized architecture and permission-flow description; the first discussion does not require confidential source documents.