Descope’s RAG auth pattern shows why RBAC still matters

At a glance

What this is: This is a practical walkthrough of securing a RAG app with SAML SSO, role mapping, JWT claim control, and row-level security.

Why it matters: It matters because AI applications increasingly depend on identity-scoped retrieval, so IAM teams need to govern who can see which embeddings, not just who can sign in.

👉 Read Descope’s tutorial on building role-based access into a RAG app

Context

A retrieval-augmented generation app is only as secure as the identity controls around the data it can retrieve. In this pattern, authentication alone is not enough, because the application also needs role-aware access control for embeddings and source documents.

The identity problem is familiar to IAM teams: a user can be authenticated and still be over-authorised if claims are writable, roles are not mapped consistently, or row-level controls are missing. The article is a typical example of how application teams try to close that gap in an AI workflow.

For practitioners, the key issue is not whether the stack uses Descope, Supabase, or pgvector. The issue is whether the retrieval layer enforces least privilege across human users and the data they are allowed to query.

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. That means mapping each workflow to the smallest possible set of collections, binding retrieval to user and service account entitlements, and separating sensitive corpora so one model path cannot reach unrelated business data. The goal is to limit blast radius before the model sees anything.

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. Authorisation data should be issued by a trusted service and remain immutable from the user’s perspective. If roles are stored in writable metadata, the application may appear federated while still relying on data the user can alter.

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. In a RAG application, both are necessary because authentication alone does not prevent over-retrieval. The retrieval layer must still check role context before documents or embeddings are exposed to the application.

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.

Technical breakdown

SAML SSO as the authentication front door

The tutorial uses SAML 2.0 so the application delegates authentication to an identity provider rather than managing local passwords. That matters because SSO establishes who the user is, but it does not by itself decide what data the user may retrieve. In RAG systems, that separation is critical: authentication confirms identity, while authorisation must still be enforced at the document and embedding layer. Without that boundary, a logged-in user can still query data outside their role.

Practical implication: Use SAML or OIDC for authentication, but treat retrieval authorisation as a separate control plane.

Role mapping and JWT claim shaping

The article maps roles from the identity provider into application tokens so the database can make access decisions. The important detail is that the roles are moved into app_metadata rather than left in user_metadata, because user-editable claims cannot be trusted for authorisation. This is a common pattern in federated identity designs: token content must be controlled at issuance time, not modified by the user after login. Otherwise the application is only as strong as the least protected claim field.

Practical implication: Keep authorisation attributes in server-controlled token claims, not in user-editable identity data.

Row-level security for retrieval boundaries

Row-level security enforces access at the query layer, which is the right place to protect embeddings and source documents in a multi-role RAG app. The policy described in the article checks whether the document role matches any role in the user’s token, so retrieval is constrained by policy rather than interface logic. This is stronger than filtering in the UI, because the database itself becomes the enforcement point. For AI applications, that matters because the model can only answer from what the application can actually retrieve.

Practical implication: Enforce retrieval limits in the database, not only in the application or chat interface.

NHI Mgmt Group analysis

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.

Writable identity claims are a weak authorisation boundary. If a user can influence the token fields that drive access decisions, the application has delegated policy to the subject it is trying to constrain. That is a classic governance failure, not just a coding flaw. The implication is that identity attributes used for authorisation must be issuer-controlled and auditable from end to end.

RLS is the right enforcement pattern for embedding stores because it moves policy to the data plane. When access checks happen after retrieval or only in the front end, the sensitive rows have already become available to the application. That creates unnecessary exposure in AI workflows where the retrieval layer is effectively the security boundary. Practitioners should therefore align database policy design with the roles that govern application use.

Named concept: retrieval-layer least privilege. In RAG systems, least privilege is not only about account entitlement. It is about constraining which records, embeddings, and context fragments can enter the model prompt in the first place. That framing helps teams govern AI applications as identity-dependent systems rather than generic software, which is where many current reviews stop too early.

From our research:

• 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, leaving most deployments without formal access guardrails.
• For broader control design, see OWASP NHI Top 10 for agentic access and tool-use risk framing.

What this signals

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.

Claim hygiene now matters as much as policy logic. If token content can be altered by the user, the best database policy still depends on an untrusted input path. Identity teams should therefore review how claims are issued, transformed, and consumed across the full chain, then align that flow with their existing access review and recertification processes.

Governance teams should expect more applications to adopt retrieval-layer least privilege as a design pattern. That shift will pull IAM, data security, and application engineering into the same control conversation, especially where AI systems sit on top of sensitive internal content. The teams that can prove policy enforcement at the data plane will have a much cleaner audit story than those relying on application-only controls.

For practitioners

• 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.
• Review role mapping end to end Validate that identity-provider roles, SSO group mapping, token claims, and database policies all resolve to the same access outcome.

Key takeaways

• RAG security depends on enforcing identity-aware retrieval limits, not just authenticating users at login.
• The article’s main control lesson is that authorisation data must live in issuer-controlled claims and database policy, not writable user metadata.
• For AI applications, row-level security turns least privilege into a data-plane control that can actually constrain what the model sees.

Key terms

• Retrieval-layer least privilege: Retrieval-layer least privilege is the practice of limiting which records, embeddings, or context fragments an AI application can pull into a response. It extends least privilege from account access to data selection, which is essential when model outputs depend on what the application can retrieve.
• Row-Level Security: Row-level security is a database control that restricts which rows a session can read or modify based on policy. For multi-tenant apps, it is valuable because it pushes tenant enforcement below application code, reducing the chance that a forgotten filter exposes another organisation's data.
• Issuer-controlled claims: Issuer-controlled claims are token attributes created and signed by a trusted identity system rather than edited by the user. They are used when applications need reliable identity context for authorisation, because writable metadata cannot safely serve as the basis for access decisions.

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.

👉 Descope’s full post covers the SAML setup, JWT claim hook, and RLS policy in implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.