Notifications
Clear all
Topic starter
16/08/2026 1:13 pm
TL;DR: A tutorial shows how SAML SSO, role mapping, JWT claim shaping, and row-level security can be combined to restrict retrieval access in a RAG application, using Supabase and pgvector as the backend, according to Descope. The governance lesson is that identity data must be moved out of user-editable claims and into enforceable access context.
NHIMG editorial — based on content published by Descope: Build a RAG App with Descope, Supabase, and pgvector: Part 2
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: Why are user-editable JWT claims risky for authorisation?
A: User-editable claims are risky because they let the subject influence the policy signal used to grant access.
Q: What is the difference between SSO and row-level security in an AI app?
A: SSO establishes who the user is, while row-level security decides which records that user can access.
Practitioner guidance
- Separate authentication from retrieval authorisation Treat SAML or OIDC login as the first control only, then enforce document and embedding access with database policies that reflect user roles.
- Move authorisation claims into issuer-controlled metadata Store roles in server-issued token claims such as app_metadata, and avoid relying on user-editable metadata for access decisions.
- Enforce row-level security on retrieval tables Apply RLS to documents and embedding tables so the database blocks unauthorised rows before the application can build prompts.
What's in the full article
Descope's full blog post covers the implementation detail this post intentionally leaves for the source:
- The exact SAML configuration steps for connecting Descope to Supabase through metadata exchange.
- The full SQL function used to reshape JWT claims before issuance in Supabase.
- The row-level security policy syntax for mapping roles to document access.
- The frontend setup and testing flow for validating role-based retrieval end to end.
👉 Read Descope’s tutorial on building role-based access into a RAG app →
RAG app access control: are your SSO and RLS layers enough?
Explore further
16/08/2026 1:14 pm
Identity controls for RAG are really retrieval governance controls. Once embeddings and source documents become application inputs, the access model extends beyond authentication into data selection. That means IAM, IGA, and application security teams have to treat retrieval paths as governed access surfaces, not just backend plumbing. The practical conclusion is that RAG security fails when access to source data is assumed to be a UI problem.
Retrieval governance is becoming a core IAM requirement for AI applications. As organisations expose embeddings and knowledge bases to conversational interfaces, the control question shifts from login success to query entitlement. Teams that already struggle with role sprawl in standard applications will find that RAG introduces a second authorisation surface that must be governed with the same discipline as the first.
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: Descope’s RAG auth pattern shows why RBAC still matters
