Notifications
Clear all
Topic starter
10/06/2026 11:40 pm
TL;DR: Externalized authorization pushes access checks into the retrieval layer so semantic search and RAG pipelines only surface documents a user is permitted to see, according to Cerbos. That shift matters because similarity is not authorization, and post-retrieval filtering can still leak snippets, waste search budget, and expose confidential data before the final gate.
NHIMG editorial — based on content published by Cerbos: externalized authorization for ChromaDB retrieval and RAG
Questions worth separating out
Q: How should security teams enforce authorization in RAG retrieval pipelines?
A: Security teams should enforce authorization at the retrieval layer, before documents are returned to the application or LLM.
Q: Why do vector databases complicate access control for AI applications?
A: Vector databases complicate access control because they optimize for similarity, not entitlement.
Q: What breaks when post-retrieval filtering is used for confidential content?
A: Post-retrieval filtering breaks because the system has already spent search budget and may already have exposed snippets, rankings, or partial context.
Practitioner guidance
- Map RAG retrieval paths to explicit authorization policies Identify every point where embeddings, metadata, or similarity search can surface internal content, then bind those paths to policy-as-code rather than application-side post-filtering.
- Enforce filters before documents enter the LLM context Configure vector stores and adapters so the search layer applies access conditions during retrieval, not after ranking or summarisation.
- Validate policy syntax against datastore filter support Test which operators your retrieval layer can actually enforce, including negation, membership, and string matching.
What's in the full article
Cerbos's full documentation covers the operational detail this post intentionally leaves for the source:
- The complete PlanResources and queryPlanToChromaDB implementation pattern for LangChain.js and ChromaDB.
- A full code example showing how metadata fields map to policy attributes in a live retrieval workflow.
- Operator support and limitation details for logical inversion, comparison mapping, and unsupported expressions.
- Installation and package usage guidance for teams integrating policy enforcement into application code.
👉 Read Cerbos's guide to externalized authorization for ChromaDB retrieval →
RAG retrieval filters and authorization gaps: what IAM teams miss?
Explore further
12/06/2026 5:57 am
Externalized authorization is the right control pattern when retrieval is the exposure point. Once AI systems search internal content by semantic similarity, the authorization decision has to happen before retrieval, not after it. Post-filtering is too late because the system may already have exposed snippets, rankings, or prompt context. The practitioner conclusion is that retrieval-layer policy enforcement belongs in the identity control plane, not in application cleanup.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do policy plans help control access in AI retrieval systems?
A: Policy plans let the authorization engine express the exact conditions under which access is allowed, then translate those conditions into datastore-native filters. That gives teams a consistent way to enforce policy across applications without duplicating access logic in every retrieval workflow.
👉 Read our full editorial: Externalized authorization for RAG closes retrieval-layer data leaks
