Topic starter
16/08/2026 1:13 pm
TL;DR: A RAG application can combine Supabase, pgvector, and role-based access to keep retrieval and response generation aligned with user permissions, according to Descope. The identity lesson is that embedding search alone does not govern access; authorization must be enforced at the data layer and again at query time.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Build a RAG App With Descope, Supabase & pgvector: Part 1”.
Key questions
Q: How should security teams govern access in RAG systems?
A: Security teams should govern RAG access at the retrieval layer, not only at authentication.
Q: Why is embedding search not enough to secure retrieval in AI applications?
A: Embedding search only measures semantic similarity, not permission.
Q: What breaks when role checks are enforced only in the user interface and not in the backend?
A: UI-only checks fail as soon as a user bypasses the app, replays a request, or calls the API directly.
Practitioner guidance
- Define role-scoped retrieval rules Map each retrievable corpus to a user role or tenant boundary before any similarity search runs, and ensure the retrieval query cannot cross that boundary.
- Enforce row-level security at the data layer Use database-level policies so that documents are filtered before the application can package them into prompt context or return them to the user.
- Separate relevance from entitlement checks Treat vector similarity as a ranking signal only, then apply authorization logic independently so that the most relevant document is still rejected if the caller lacks access.
Bottom line: RAG security depends on more than similarity scoring because retrieval can surface information that user roles should not see.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
16/08/2026 1:14 pm
Role-aware retrieval is the control boundary, not the embedding model. This article is useful because it makes a distinction many RAG builds miss: semantic relevance does not equal entitlement. The underlying governance problem is that developers often assume the retrieval layer can safely decide what to return because it is technically closest to the data. It cannot. Practitioners should treat retrieval as a governed access path, not a search convenience.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between retrieval relevance and authorization in RAG?
A: Retrieval relevance decides which content best matches the query, while authorization decides whether the caller is allowed to see that content at all. They are different controls and should be enforced separately. A good RAG design may rank a document highly but still block it from entering the prompt if permissions do not allow it.
👉 Read our full editorial: RAG app identity controls need role-aware retrieval, not just embeddings