A user's access to a document set is revoked. What has to happen across your RAG stack?

Revoke in one place, then follow the copies

The first move is unambiguous: the change lands in the authorisation store, which is the only thing entitled to hold the truth about who may see what. Everything else in the stack is a copy or a derivative, and the design question is how many of them you know about.

Start by classifying the revocation, because the fan-out differs sharply. A single document unshared touches a handful of rows. A person offboarded touches their sessions, tokens and API keys as well as their permissions, and if their session is long-lived, an already-authenticated request may keep working until it expires. A group membership removed is the expensive one, because a group is an indirection over a potentially enormous document set, and if you denormalised ACLs into the index at ingestion you now have to rewrite the metadata of every chunk the group could reach. A tenant terminating is closer to deletion than to revocation. Naming which case you are handling before enumerating steps is itself a signal, because the mitigation for one is wasted effort on another.

flowchart TD
  A[Revocation recorded] --> B[Authorisation store]
  B --> C[Index ACL metadata]
  B --> D[Retrieval and answer caches]
  B --> E[Derived summaries and digests]
  B --> F[Logs traces and eval sets]
  B --> G[Live conversation transcripts]
  B --> H[Answers already delivered]
  H --> I[Out of reach]

The only edge that matters in that diagram is the last one, and it does not loop back.

The index is the part with an owner

Rewriting ACL metadata on affected chunks is mechanical and, if your permissions are denormalised, slow in proportion to the group's reach. Two things make it survivable. Process revocations on a queue that pre-empts routine reindexing, because otherwise a bulk ingest sitting in front of them defines your revocation lag. And prefer the indirection: store an access-control-entry identifier on the chunk and resolve at query time which identifiers the caller satisfies, so a group change is one row in the authorisation store and no writes at all in the index. The cost moves to the query path, where the resolved set is cached per user — which is fine, provided you treat that cache as part of the revocation problem rather than as an implementation detail.

While that propagates, retrieval should be checking authorisation for the shortlisted passages against the live source of truth immediately before they enter a prompt. That check is what makes revocation effective in seconds rather than in however long the reindex takes, and it is the reason to build it even when your filters are correct. It also forces a decision you should state: when the authorisation service is unavailable, retrieval fails closed. A degraded mode that serves stale permissions to keep the assistant answering is a policy choice someone must sign, not a default.

Every cache that holds text or results

This is where the enumeration earns marks, because these layers are added for latency and rarely revisited for authorisation.

A retrieval cache keyed on the query holds chunk text and will serve it to whoever asks the same question. An answer cache holds the whole response, including the quoted passage. A per-conversation context block, kept byte-stable to preserve prompt-cache hits, holds passages for as long as the block is reused, and its refresh interval is a freshness bound most teams have never written down. Summarisation and extraction caches keyed on document content hold derived text. A search-suggestion or autocomplete index built from the corpus can surface a title on its own.

Enumerating keys to invalidate across all of that is hopeless. The mechanism that works is a permission epoch: store a monotonically increasing version per principal, include it in every cache key that is user-scoped, and bump it on any change to that principal's access. Every cached entry for that user becomes unreachable in one write, and the stale entries age out on their own. For caches that are content-scoped rather than user-scoped, carry the document identifier in the key so a per-document invalidation is possible, and accept that anything keyed only on a query string has to be given a short lifetime, because it cannot be invalidated precisely. That lifetime is your revocation lag for that layer, and it should be a documented number with an owner rather than whatever value someone chose while tuning cost.

Derived artefacts, which usually have no owner at all

Retrieval systems generate second-order data constantly, and this is where an auditor's question becomes uncomfortable. A cached per-document summary. A weekly digest assembled from documents across a workspace. An extracted entity or relation in a knowledge graph. A cluster label. A gold evaluation set built from real questions and real passages. A few-shot exemplar chosen because it was a good answer. A fine-tuning corpus. Each of those may contain content from the revoked documents, and none of them are in the retrieval path where you were looking.

The only tractable approach is provenance recorded at creation: every derived artefact stores the source document identifiers it was built from, so "what derives from this document" is a query rather than a search of the estate. Without that lineage you cannot answer the question truthfully, and saying so in an interview is stronger than pretending a sweep would find everything. Model weights are the boundary case and the reason to be conservative: content that has been trained into a model cannot be revoked by any means you control, which is the practical argument for keeping permissioned material in retrieval and out of training.

Conversation history, which belongs to the user

If a passage was retrieved into a transcript before the revocation, it is still in the transcript. Continuing to send it to the model means the assistant keeps answering from material the user is no longer entitled to, which is exactly the thing you are trying to stop. Redacting it means editing a record the user is looking at, which is confusing and, in some regulated contexts, its own problem.

The defensible design is to re-authorise retrieved passages on each turn rather than trusting a transcript, and to drop those that no longer pass, with a visible note that some earlier evidence is no longer available. Whether the historical turns are also purged from storage depends on what the transcript is for — a support-audit record and a working conversation have different obligations — but the decision should be explicit and the same in every product surface. Note too that a transcript exported, shared to a channel, or attached to a ticket has already left your control, which brings you to the honest part.

The answer already delivered

Nothing you build recalls it. A response containing the substance of a revoked document, rendered on a screen, copied into a message, emailed by an agent or read aloud, is disclosed permanently. Revocation in a RAG stack is therefore prospective by nature, and the guarantee you can offer is a bounded window between the revocation being recorded and the last possible use of the material — not erasure.

Two design consequences follow, and stating them is the mark of someone who has argued this with a security team. Because the window is the guarantee, it is worth engineering the window down at retrieval time — the late authorisation check, the epoch-keyed caches, the pre-empting queue — rather than investing in elaborate after-the-fact cleanup that cannot reach the disclosed copies anyway. And because bulk egress converts a bounded window into unbounded disclosure, flows that mass-export derived content are the ones to constrain hardest: an agent that emails weekly summaries of a hundred documents to a distribution list has created a hundred copies you will never revoke, and no amount of correct filtering upstream changes that.