What is permission-aware retrieval?

Retrieval that applies the requesting user's own access rights at query time, so the system can only surface documents that user was already entitled to read. Without it, a retrieval system inherits the permissions of whatever account built the index, which is usually a service account with broad access.

Why do RAG systems leak documents?

Because indexing and querying are separate operations with separate identities. The index is typically built once by a service account that can read everything, and the query runs later as an application rather than as the person asking. Unless access control is deliberately reapplied at query time, the model answers from the union of everything indexed.

Would normal testing catch this?

Usually not. The system returns correct, relevant, well-grounded answers, which is what functional tests check. The defect only appears when a low-privilege user asks about something they should not be able to see, and that is rarely in the test set because the people writing the tests can usually read everything.

How do we test for it?

Create a deliberately low-privilege account, identify documents that account cannot open directly, then ask the assistant questions whose answers exist only in those documents. If any answer draws on them, retrieval is not permission-aware. Run this before launch and again after any change to indexing or access control.

What is the right architecture?

Carry the end user's identity through to the retrieval query and filter at search time against the source system's current permissions, rather than at index time. Post-filtering results after retrieval is better than nothing but degrades quality, because the model may be left with too little context. Filtering at query time is the approach that holds up.

Permission-Aware Retrieval: The Defect Hiding in Most Enterprise RAG

This is the most common serious defect found in enterprise retrieval systems at review, and it is almost never caught by testing.

Build an index over a document store. Query it from an assistant. Ask a question. Get a correct, well-grounded, genuinely useful answer, drawn from a document the person asking was never entitled to open.

Everything about that interaction looks like success.

Why it happens

Indexing and querying are separate operations, performed at different times, by different identities. That separation is where the failure lives.

At index time, something has to read every document in scope in order to embed it. That something is almost always a service account with broad read access, because anything narrower would produce an incomplete index. This is correct and unavoidable.

At query time, the application searches that index. Unless it has been deliberately built to do otherwise, it searches as itself, not as the person who asked. The vector store has no concept of who is asking. It returns the nearest neighbours.

So the effective permission of the assistant is the union of everything indexed, for every user. The service account's access has silently become everyone's access.

Why testing misses it

Functional tests check whether answers are correct, relevant and grounded. This system produces answers that are all three. There is no error, no exception, no degraded output. The only thing wrong is who is receiving the answer.

Two things compound it:

The people who build and test these systems are usually senior enough to read most of what got indexed. When they spot-check answers, nothing looks out of place, because nothing is out of place for them.

And the failure is silent by nature. Nobody receives a warning that they were shown something restricted. Frequently the recipient does not know the material was restricted at all.

Testing for it properly

The test takes about twenty minutes and belongs in your pre-launch gate.

Create an account with deliberately narrow access, matching a real low-privilege role rather than an artificial one.
Identify several documents that account cannot open directly. Pick material with distinctive facts, a specific figure, a named project, an unusual term, so an answer drawing on it is unmistakable.
Ask the assistant questions whose answers exist only in those documents.
Check whether the answer, the citations, or the retrieved context contain any of it.

If anything comes back, retrieval is not permission-aware. Rerun this after any change to indexing, to the source system's permission model, or to the retrieval layer, because all three can reintroduce it.

Designing it out

Filter at query time, against live permissions. Carry the end user's identity through to the retrieval call and apply the source system's current access rules as part of the search. This is the approach that holds up, because permissions change after documents are indexed and only a live check reflects that.

Do not rely on index-time partitioning alone. Building separate indexes per group works until someone's access changes, or a document is reclassified, or a person moves team. The index is a snapshot; permissions are not.

Treat post-filtering as a fallback. Retrieving broadly and discarding unauthorised results afterwards is better than nothing, but it degrades answer quality: the model may be left with too little context, and it will still sometimes produce a confident answer from a thin remainder. It also means restricted content passed through your application layer, which may itself be reportable.

Log the retrieval, not just the response. When someone asks what the system had access to during a given interaction, "we log the prompt and the answer" is not an adequate response. Log which documents were retrieved, for which user.

The adjacent failures

Once you are looking at this properly, three related issues usually surface at the same time:

Stale permissions. Someone leaves a team, loses access in the source system, and the index still carries their old scope until the next rebuild.
Inherited link sharing. Documents shared broadly inside a collaboration suite are frequently far more open than their owners believe, and indexing makes that scope newly discoverable in a way browsing never did.
Derived content. Summaries, embeddings and cached answers generated from restricted documents inherit the restriction, and are commonly stored somewhere with weaker controls than the original.

Retrieval does not create these problems. It makes existing over-sharing searchable, which converts a latent misconfiguration into an active one.

Where to go next

This is item one on the data and integration section of the production checklist in the readiness playbook. For the surrounding architecture see RAG at scale, and for the governance framing see AI governance and compliance.