Retrieval is an access-control problem wearing a search interface
The most common serious failure in enterprise retrieval systems is not a wrong answer. It is a correct answer, assembled from a document the person asking was never entitled to read, and no quality metric will ever detect it.
The assistant is answering questions about internal policy and it is doing it well. Somebody in the pilot asks about a restructuring, and the answer is accurate, well-sourced and drawn from a board paper the person asking has never had access to.
Nothing failed. The index was built from a document store, the store contained that paper, the retrieval step matched it, and the model summarised it faithfully. Every component did its job. The system had simply never been told that the question of what to retrieve and the question of what this person may see are the same question.
The claim: an index is a copy of your document estate with its permissions removed, and unless they are put back explicitly, retrieval quality and information disclosure are the same subsystem.
Where the permissions go missing
Documents in an enterprise carry access controls, and those controls live in the system that holds them — the file store, the intranet, the case management platform. Ingestion reads the content. It does not, by default, read the access control list, and even when it does, it has nowhere obvious to put it.
By the time a document has been extracted, chunked and embedded, it is a vector and some text in a store whose native concept of authorisation is usually a single API key. The permission model that existed upstream has been flattened into a system where everything is visible to whatever holds the key. OWASP added vector and embedding weaknesses as a category in its own right in the 2025 edition of the Top 10 for LLM Applications, and cross-tenant leakage through a shared index is the first example it reaches for.
- 01 Ingestion Read the access control alongside the content, or it is gone.
- 02 Chunking Every chunk inherits the permission of its source document.
- 03 Retrieval Filter by the requester’s entitlement before ranking, not after.
- 04 Answering The model only ever sees material this requester could have opened.
Stage three is where implementations most often go wrong in a way that looks correct. Filtering after retrieval — fetching the top passages and then removing the ones the user may not see — produces answers that are safe and quietly worse, because the ranking was computed over material the user could not access and the best permitted passages may never have been in the candidate set. Worse, it leaks by omission: a user who consistently gets thin answers about one subject has learned something about what exists.
Filtering before ranking is the correct construction, and it is harder, because the store has to support entitlement-aware search and the entitlement has to be resolvable at query time.
The failure modes nobody tests for
The second and third lines are the ones that catch mature systems. Permission changes and deletions at source do not propagate to a derived index unless somebody built the propagation, and most ingestion pipelines are one-directional. A document withdrawn from the intranet in March is still answering questions in September.
The fifth line is the one that appears when a team adds a cache for cost reasons. A cache keyed on question text alone will serve one user’s entitlement-filtered answer to another user, which converts an optimisation into a disclosure. The key has to include the entitlement scope.
The sixth is the hardest and it has no complete solution. Aggregation across individually permitted documents can produce a conclusion that was itself restricted, and no per-document control can prevent it. The practical mitigations are to keep genuinely sensitive material out of general-purpose indexes altogether, and to log what was assembled so that an aggregation incident can at least be investigated.
What to require of an implementation
The design questions are short and they are answerable in a design review.
Where does the entitlement come from at query time — is it the requesting user’s own token, or a service identity? Is the filter applied before ranking or after? What happens when a source document’s permissions change? What is the maximum staleness of the permission data, and who agreed to it? Is the entitlement scope part of any cache key? And does the trace record which permission set was applied, so that a disputed answer can be reconstructed?
An implementation that answers all six is rare. An implementation that has been asked all six before launch is rarer, and the difference in cost between asking them then and discovering them later is the difference between a design decision and a notifiable incident.
What this does not tell you
Entitlement-aware retrieval does not make an index safe to build over everything. Some material should not be in a general index at any permission level, and the decision about what goes in is a data classification decision that precedes the architecture. A system that filters correctly over a corpus that should never have been assembled is still the wrong system.
It also does not address the model layer. Everything above concerns what the model is given. What it does with that material — how faithfully it attributes, whether it reveals the existence of documents it declined to use — is a separate problem with separate controls.
The reader who should act is whoever owns the next retrieval build. Put the entitlement question first, before the embedding model, before the chunking strategy, before the choice of store. It is the only one of those decisions that cannot be revised later without rebuilding everything downstream of it.