Every enterprise retrieval project reaches the same meeting. Someone from security asks what happens when a user searches for something they are not allowed to see, and the answer determines whether the system is deployable.
There are three common answers. Two of them are wrong.
The two wrong answers
The first is filtering after generation: retrieve from everything, generate an answer, then check whether the user can see the sources and suppress the answer if not. This leaks. The suppression itself is a signal, and worse, an answer synthesised from restricted material has already been produced: the model saw content the user cannot access, and the system's own logs now contain it.
The second is filtering after ranking: retrieve the top fifty, drop the ones the user cannot open, return what remains. This leaks more subtly. The user's result count and ordering vary with the existence of documents they cannot see, and a determined user can enumerate what exists by watching how results shift. It also degrades quality, because a user with restricted access gets a thin result set assembled from what happened to survive the filter rather than the best fifty they were entitled to.
The answer that works
Filter before ranking, using access data stored in the index itself. Each chunk carries the ACL of its source document. At query time the user's group membership is resolved against the directory, and the candidate set is constrained before any ranking occurs.
The user then gets the best results from the corpus they are entitled to, which is both correct and better. Ranking operates on a set that is already legitimate.
- Store source ACLs alongside each chunk at index time, not as a lookup at query time
- Re-resolve group membership per query, cached memberships are how a revoked permission stays live for six hours
- Re-index on permission change, and treat permission changes as a first-class event in the ingestion pipeline
- Test with synthetic users on every release, including indirect questions that name a subject rather than a document
The part everyone under-scopes
Permission changes are events, and most ingestion pipelines are built to notice content changes only. A document that is re-permissioned but not edited will keep its old ACL in the index until something forces a re-crawl, and 'something' is usually a person discovering the problem.
Budget for it. It is not difficult; it is simply never in the original estimate, and it is the failure mode most likely to end a deployment.
