Notifications
Clear all
Topic starter
06/07/2026 9:46 am
TL;DR: Traditional pre-filtering breaks down in enterprise RAG because permission sync lag, metadata explosion, and query overhead make vector databases a poor place to enforce authorization, according to Descope. Post-retrieval filtering with ReBAC separates semantic search from access control, which is the cleaner security model for enterprise retrieval.
NHIMG editorial — based on content published by Descope: Adding Performant ReBAC to RAG Pipelines at Scale
Questions worth separating out
Q: How should security teams secure RAG pipelines without breaking retrieval performance?
A: Use post-retrieval filtering.
Q: Why do pre-filtering approaches fail for enterprise RAG authorization?
A: Pre-filtering fails because enterprise permissions change faster than most vector indexes can stay synchronized, and because complex relationships do not fit cleanly into simple metadata fields.
Q: What breaks when relationship-based access is flattened into vector metadata?
A: Flattening ReBAC into metadata usually destroys inheritance, ownership, and sharing semantics.
Practitioner guidance
- Separate retrieval from authorization enforcement Keep semantic search in the vector layer and enforce access decisions in a dedicated authorization service before context is passed to the LLM.
- Model access as relationships, not metadata tags Represent owners, viewers, group membership, and folder inheritance in a relationship graph so current permissions can be evaluated at query time without flattening policy into brittle ACL-style fields.
- Design for re-query handling when results are sparse If the authorized candidate set is smaller than the number of context items needed, re-query the vector store in batches rather than lowering authorization thresholds or exposing unauthorized content.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- A step-by-step example of post-retrieval filtering across candidate document sets
- The pagination and re-query loop pattern used when the authorized result set is too small
- How Zanzibar-style ReBAC handles relationship traversal at runtime
- Implementation guidance for applying fine-grained authorization in developer-built RAG pipelines
👉 Read Descope's analysis of performant ReBAC for RAG pipelines →
RAG authorization filtering: what IAM teams are missing?
Explore further
06/07/2026 10:03 am
RAG authorization fails when teams confuse retrieval relevance with permission authority. A vector database can rank content by meaning, but it cannot decide who is entitled to see that content. Once enterprises use RAG over sensitive sources, the governance problem becomes access mediation at query time, not document discovery. Practitioners should treat the retrieval layer and the authorization layer as separate control domains.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 44% have implemented any policies to govern AI agents, which leaves most deployments without a formal control baseline for behaviour, access, or accountability.
A question worth separating out:
Q: How do security teams know if a RAG authorization design is working?
A: A working design returns only authorized documents, keeps the authorization decision current, and avoids exposing stale permissions through the retrieval layer. If teams see frequent mismatches between source-of-truth access and vector-index results, the control is not working as intended and the exposure window is too large.
👉 Read our full editorial: Performant ReBAC for RAG pipelines exposes the authorization gap
