Notifications
Clear all
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.
NHIMG editorial — based on content published by Descope: Build a RAG app with Descope, Supabase, and pgvector, part 1
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
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: When does RAG create more risk than it reduces in IAM?
A: RAG creates more risk than it reduces when the retrieval corpus is poorly governed, because the agent can confidently amplify bad context.
Q: What breaks when row-level security is missing in an AI app?
A: Any mistake in the application layer can turn into a data exposure event, because the database has no built-in awareness of tenant, role, or purpose.
Practitioner guidance
- Bind retrieval to identity claims Pass verified role or tenant claims into the retrieval query so the similarity search only runs against entitled records, not the full corpus.
- Enforce row-level security in the data store Apply database-side policy controls so unauthorized rows cannot be returned even if application logic is bypassed or misconfigured.
- Separate user entitlements from service credentials Use tightly scoped backend access for embedding generation and document lookup, and keep those credentials distinct from end-user authentication.
What's in the full article
Descope's full blog post covers the build details this analysis intentionally leaves for the source:
- Step-by-step Supabase table creation and pgvector setup for storing embeddings.
- The exact Node.js scraping and ingestion workflow used to populate the documents table.
- Client-side query code that calls the similarity function and formats the model prompt.
- The second-part preview showing how SAML and row-level security are used for permission enforcement.
👉 Read Descope's build guide for a RAG app with Supabase, pgvector, and authentication →
RAG app security: are role-based controls keeping retrieval scoped?
Explore further
16/08/2026 1:14 pm
RAG retrieval is becoming an access decision, not a search convenience. The article shows the right architectural instinct by separating content by role before response generation, but the deeper point is that semantic search now sits inside the authorisation path. If the retrieval layer is loose, the model inherits the exposure. That means identity teams must stop treating vector search as a purely AI concern and start governing it as a privileged data access path.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: How can teams tell whether retrieval controls are actually working?
A: Teams should test with users who have no roles, partial roles, and the correct roles, then verify that each case produces only the expected retrieval outcome. They should also confirm that access decisions are enforced in the database, not only in the UI or application code, because front-end filtering can be bypassed.
👉 Read our full editorial: RAG app identity controls need role-aware retrieval, not just embeddings
