Skip to content
Home/Blog/Article
Blog

Relevance is not permission: the assumption that makes RAG leak

A vector database ranks chunks by how relevant they are to a question. It has no idea whether the person asking is allowed to see them. That single gap is where most RAG leaks begin.

Governed RAGBy Produktiv Engineering, Engineering, ProduktivJune 30, 2026

Ask a search engine for the most relevant result and it will give you exactly that. Ask it whether you are allowed to read the result and you will get a blank stare. This is not a flaw in vector search. It is simply the boundary of what vector search was built to do. The problem starts when we forget that boundary and wire a retriever straight into an answer.

In a standard RAG pipeline, a query becomes an embedding, the embedding is compared against every chunk in the store, and the closest matches come back ranked by similarity. Similarity is a measure of meaning, not of authorization. The retriever cannot tell the difference between a chunk that everyone may read and a chunk that three people in the company may read. To the math, they are just points in space, and the only question being asked is which points are nearest.

So when someone asks a question whose best answer happens to live in a restricted document, the restricted chunk is the most relevant chunk, and the most relevant chunk is exactly what the retriever hands over. The system did its job perfectly and produced a leak in the process.

Why this is not solved by document permissions

The common reaction is to say the vector store should respect the same permissions as the source system. That helps, and it is necessary, but it is not sufficient, for two reasons.

First, permissions are usually set at the document or repository level, while RAG operates at the chunk level. A single document might hold a public summary in its first paragraph and confidential figures in a table halfway down. Whole-document permissions force a crude choice. Either you index the document and risk exposing the table, or you exclude it and lose the useful summary. Chunk-level governance is the way out of that trap, which is the subject of chunk-level sensitivity classification.

Second, permission in the RAG world is not only about identity. It is about purpose. The same employee might be allowed to see a customer record while resolving a support ticket and not allowed to use that same record to build a marketing list. Static access control lists cannot express that difference, because the difference lives in the intent behind the request, not in the identity of the requester. This is the gap that purpose-based access control is designed to fill.

What policy-aware retrieval changes

The fix is to stop treating "most relevant" as the final answer and start treating it as a list of candidates. Between the candidate list and the model, you place a policy decision. Each candidate chunk is evaluated against three things: who is asking, why they are asking, and how sensitive the chunk is. The chunk only survives if policy allows it for that person and that purpose.

In practice the decision has more than two outcomes. A chunk can be allowed in full. It can be redacted, so the model receives only the permitted portion. It can be annotated, so the model is told how the content may be used. It can be denied entirely. The point is that relevance gets a second opinion before it becomes context, and that second opinion is the one that understands permission.

This is also where leakage by combination gets caught. Even if every individual chunk passes, the act of assembling several of them can produce a conclusion that no single chunk contained. Governing retrieval means watching what is being assembled, not only scoring each piece, which is why this sits alongside inference and leakage control.

The mental model worth keeping

Relevance answers the question "what is this about." Permission answers the question "who may use this, and for what." A retriever is an expert at the first question and silent on the second. The entire discipline of governed RAG exists to make sure the second question gets asked at the moment it can still change the outcome, which is before the model reasons, not after it has already spoken.

Once you internalize that relevance is not permission, the whole architecture of governed RAG stops looking like extra machinery and starts looking like the obvious missing step. The full picture lives in the complete guide to governed RAG.

Get started

See Kynexa govern your AI — in 30 minutes.

Bring a real use case. We'll show governed retrieval, reasoning and audit on your stack.