Permission-aware RAG: access control has to happen before ranking

The answer was relevant. The user wasn't allowed to see its source.

A financial-services firm runs an AI support assistant. Support specialists may see a customer's profile, billing, ordinary correspondence and refund procedures. Fraud-investigation notes and legal material attached to the same customer are restricted to Risk and Legal.

The ingestion pipeline chunks every document into one shared hybrid index. Each chunk keeps the tenant ID and customer ID. It doesn't keep the document class, field-level restrictions, purpose limits or the permission revision in force at indexing. One fraud note is later reclassified; its chunks aren't updated.

A specialist asks, "Why has this refund been delayed?" Keyword and vector search both rank the fraud note highly: it mentions the customer, the refund amount and a "manual delay." A final filter confirms the specialist is in the right tenant and may access this customer. The chunk goes through.

The model paraphrases the internal suspicion of chargeback abuse and recommends denying the refund. The answer is relevant. It's also built from information the specialist was never authorized to use.

Every component behaved. The user was authenticated, IDs matched, search returned the closest candidates and the model answered from what it was given. The access boundary was still crossed, inside a single tenant and a single customer record. Tenant isolation alone wouldn't have stopped it.

What is permission-aware RAG?

Permission-aware RAG applies the requester's access rights at every retrieval stage, so only items they may use can compete for ranking, enter the context and reach the model. Relevance is measured inside that boundary, never across the whole index.

Relevance and authorization answer different questions. Both must be true before a candidate influences anything.

A relevant item can be unauthorized. An authorized item can be irrelevant. An item can be both and still be stale, manipulated or outside the declared purpose.

Why isn't filtering after search enough?

Because restricted items have already competed by then: they've taken top-k slots, reranker budget, diversity slots and cache entries, and pushed out items the user was entitled to. The answer can contain no restricted text and still be shaped by restricted data.

Many implementations retrieve a global top-k and remove what the user can't see. That stops direct disclosure. It doesn't stop influence. If nine of the top ten candidates are restricted, the user gets one result, not the ten best items they were allowed to see. Worse, a cache built from the unfiltered set can serve that influence to the next person.

The fix is to define the set of items a requester may use first, then rank inside it. Keep post-filtering as a last line of defense, not the first.

Define the boundary every retrieval path must respect

"Always add tenant_id to the query" is a convention, not a boundary. Write down what every retrieval path has to preserve, per use case:

You can enforce this with separate indexes, metadata filters, a policy service or a mix. The requirement isn't one topology. It's one explicit meaning of "allowed," applied the same way everywhere.

Which enforcement pattern should you use?

Usually a combination: narrow scope during candidate generation, check exact object and field access before assembling context, and recheck right before content reaches the model. No single pattern fits every corpus, policy and latency target.

When a candidate is denied, give a typed reason (denied, out of scope, field restricted, purpose not allowed, reclassified, pending deletion, unclassified) rather than an empty result. And never pass a denied item to the model with an instruction not to reveal it. By then it's already crossed the boundary.

Hybrid search multiplies the surface

Enterprise retrieval rarely means one vector query. It mixes keyword search, vectors, graph traversal, SQL, feature lookups, memory and external tools. Each needs the same boundary:

• Keyword search applies the same tenant, object, field and purpose limits as vector search.
• Query expansion, synonyms and generated sub-queries broaden meaning, never authority.
• Graph traversal checks access on every hop, not only the starting node.
• SQL and feature queries keep row, column and purpose limits instead of exporting broad results to a later filter.
• External search and tool results go through the same eligibility checks as internal sources.

Fusing globally generated candidate sets and filtering afterwards reintroduces exactly the problem you were solving.

Chunks, embeddings and caches inherit restrictions

The boundary is easiest to lose when a protected document becomes something derived from it. The source may have perfect access controls while its chunks, embeddings, summaries and cache entries carry only a tenant ID.

Chunking has to respect field and section boundaries too. A chunk that mixes ordinary correspondence with a restricted note can no longer be authorized by the document or customer ID. Split by restriction, index redacted views, or both.

Object access isn't field access, and neither is purpose

The opening failure happened inside one tenant and one customer. A person can be allowed to open an account and still be barred from its fraud notes, legal analysis, medical details or compensation fields. OWASP's API Security Top 10 separates these as object-level and property-level authorization for good reason.

Purpose matters as well. Data you may use for payroll or incident response isn't automatically usable for hiring, sales or customer service. Retrieval has to carry the purpose of the request, not just the identity behind it. For isolation between customers on shared infrastructure, see tenant isolation for agents and RAG.

Permissions change after you index

People change roles. A matter becomes privileged. A document is deleted, reclassified or moved to another legal entity. A long-running case resumes after all of that. A check made at ingestion records who could see something then, not now.

1. Bind every derived artifact to the source revision and permission revision that produced it.
2. Re-evaluate access at query time, and again before content reaches the model when the stakes warrant it.
3. Push deletion, revocation, expiry and reclassification to every chunk, embedding, summary, cache and index.
4. Quarantine items with missing or stale scope metadata instead of defaulting them to broad access.
5. Keep the historical permission state for audit, but re-establish current authority before any new action.

IBM's 2025 breach research found that 97% of organizations reporting an AI-related breach lacked proper AI access controls. Stale derived artifacts are one of the quieter ways that happens.

Authorized doesn't mean trustworthy

An item can be fully authorized and still be malicious, misleading, stale or written to redirect the model. Permission-aware retrieval decides whether content may enter. It doesn't decide whether instruction-like text inside it should be obeyed. Retrieved content enters as evidence, never as instructions, and prompt-injection defenses, validation and tool controls stay separate layers. How retrieved items combine with records and policy is covered in context assembly beyond RAG.

Measure relevance and leakage together

Standard retrieval metrics ask whether relevant items rank near the top. Enterprise evaluation has to ask that inside each access boundary, and check that restricted data neither appears nor distorts results. Useful checks:

• Authorized recall: how many relevant, permitted items reach the top-k for this scope?
• Exposure rate: how often does restricted content reach the model or the user?
• Influence rate: how often do restricted items change ranking or the outcome without being shown?
• Permission lag: how long until a revocation reaches chunks, embeddings and caches?
• Cache contamination: can a result built under one scope be served under another?

Test the same query as users with different tenants, roles, purposes and field permissions, with warm and cold caches, after revocation, and with missing scope metadata.

Common anti-patterns

Ten rules for permission-aware retrieval

1. Treat relevance and authorization as separate tests; both must pass.
2. Write down the access boundary for every consequential retrieval path.
3. Apply access before ranking, not after.
4. Carry object, field, purpose and classification limits into every chunk, embedding, summary and cache.
5. Recheck permissions at query time and before the model.
6. Propagate deletion, revocation and reclassification to everything derived.
7. Quarantine items with missing scope; never default to broad access.
8. Treat authorized content as evidence, never as instructions.
9. Measure leakage and influence alongside relevance.
10. Record what was eligible, excluded and selected for each decision.

The result: relevance you can defend

Permission-aware retrieval isn't a tenant filter bolted onto one vector query, and it doesn't require one index per user. Shared infrastructure can stay efficient. What can't stay implicit is the link between relevance, authority, purpose, scope and lifecycle.

Make that link explicit and retrieval quality starts to mean something. You can explain not only why an item ranked highly, but why it was allowed to rank at all, and show that nothing outside the requester's authority shaped the answer.