RAG app identity controls need role-aware retrieval, not just embeddings

At a glance

What this is: This tutorial shows how to build a RAG backend with Supabase and pgvector, and its key security point is that role-aware retrieval is required to keep responses scoped to authorised data.

Why it matters: It matters because IAM teams must treat retrieval pipelines as access paths, not just AI plumbing, or users will see content that the application should not expose.

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.

👉 Read Descope's build guide for a RAG app with Supabase, pgvector, and authentication

Context

RAG applications are often described as a search and generation problem, but the governance issue is access control. Once an application can retrieve external content and feed it into an LLM, the retrieval layer becomes an identity boundary, because the model will only be as constrained as the data the application allows it to see.

This tutorial uses role-based access to separate marketer and developer content, which is the right instinct for enterprise RAG design. The broader identity lesson is that embeddings improve relevance, but they do not enforce authorisation on their own, so RLS, claims, and scoped retrieval must carry the control burden.

For teams building AI-enabled applications, this is a human IAM and NHI-adjacent pattern at the same time. The user identity drives the request, but the application and its service credentials are the entities actually querying storage and passing context to the model.

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: 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. That happens when policies are stale, sources are unauthorised, chunking breaks policy meaning, or query filters are weak. In those cases, RAG increases the speed of incorrect decisions.

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. In RAG systems, that can mean the model is fed content from the wrong access class and generates answers outside entitlement.

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

Why vector similarity search does not equal authorisation

pgvector lets an application compare query embeddings to stored document embeddings and return the nearest matches by distance. That is useful for relevance, but distance scores have no awareness of tenant, role, or business purpose. If the retrieval query is not constrained before the similarity search runs, the application can surface content that the user is not entitled to see. In a RAG stack, semantic proximity is not a substitute for access policy, because the database will happily return the best match whether or not the caller should receive it.

Practical implication: constrain retrieval with role and tenant checks before similarity ranking, not after the model has already seen the data.

How row-level security changes the trust boundary in RAG

Row-level security moves part of the decision logic into the database, where the data actually lives. Instead of trusting the application layer to remember every rule, the database enforces which rows can be selected based on session context, claims, or policy expressions. That matters in RAG because the application often blends user input, service access, and model orchestration in one request path. When RLS is missing, any bug in the app can become a data exposure path, even if the embedding pipeline itself is technically correct.

Practical implication: treat RLS as a mandatory backstop for retrieval pipelines that handle content with different access classes.

Why custom claims and SAML attributes matter in AI app design

Identity assertions become part of the retrieval contract when an application uses role-based access to separate content sets. A claim such as developer or marketer is not just a UI label; it is an input to downstream query logic and therefore an access control signal. If those claims are stale, overbroad, or easy to forge, the AI app may retrieve the wrong corpus and generate answers outside the user’s entitlement. In practice, federated identity, session mapping, and backend policy enforcement need to be aligned or the RAG layer becomes an amplification point for bad entitlement data.

Practical implication: validate claims at session start and re-check them at retrieval time whenever the data set changes in sensitivity or scope.

NHI Mgmt Group analysis

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.

Role-aware retrieval is the named control gap this pattern exposes. The documents retrieved for a prompt are effectively a dynamic entitlement set, and that set must be bounded by identity context. Without that boundary, the AI system can return content that was never meant for the requesting user, even when the embedding model and database are working as designed. Practitioners should view this as an entitlement design problem, not an LLM quality problem.

Custom claims become policy inputs once AI applications federate identity into data retrieval. The tutorial’s marketer and developer split is simple, but the governance implication is broader: any claim used to steer retrieval becomes part of the access model and must be lifecycle managed like any other entitlement attribute. That creates direct overlap between IAM, IGA, and application security teams, because stale claims now shape what the model can disclose.

AI application security and NHI governance converge at the service layer. The application’s backend credentials, database permissions, and model calls are non-human identities in motion, even when the end user is human. That means the control surface spans human authentication, service account privilege, and retrieval policy in one workflow. Teams that separate those disciplines will miss the actual trust boundary.

Embedding quality improves relevance, but governance decides exposure. A better vector model can make retrieval more accurate, but it cannot make an unauthorised document safe to query. The decisive question is not whether the model finds the right answer, but whether the caller was entitled to put that answer into the prompt in the first place. Identity teams should prioritise authorisation design before tuning retrieval precision.

From our research:

• 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.
• For a broader control model, see OWASP NHI Top 10 and map retrieval paths to bounded identity and privilege.

What this signals

Role-aware retrieval: RAG systems are starting to behave like entitlement brokers, which means the security programme has to treat embedding search as governed access rather than advisory context. If the retrieval layer is not scoped by identity, every downstream model response inherits that overreach. Teams should align IAM policy, database policy, and application logic before scaling the pattern.

The next control question is not whether the model is accurate, but whether the requesting identity was entitled to the data used to generate the answer. That shifts priority toward claim validation, row-level policy enforcement, and auditability of what the retrieval layer exposed. In practice, this is where human IAM and NHI governance meet in the same request path.

As AI-enabled applications multiply, the retrieval boundary will become a common place to detect privilege creep and accidental disclosure. IAM teams should expect more pressure to prove who could see what, when, and through which service identity, especially as applications blend users, backend credentials, and AI orchestration in one workflow.

For practitioners

• 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.
• Review claim freshness and mapping rules Revalidate the identity attributes that steer retrieval whenever roles change, because stale claims can expand the content set the model can see.

Key takeaways

• RAG applications can turn semantic retrieval into an access path, so identity controls must be enforced before data reaches the model.
• Role-based retrieval and row-level security are the difference between useful context and unintended disclosure in AI apps.
• IAM, IGA, and NHI governance need a shared view of retrieval because service credentials and user claims now jointly shape exposure.

Key terms

• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.
• 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.
• Role Claim: An identity attribute that tells downstream systems what a user is allowed to do or see. In retrieval-driven applications, role claims become policy inputs, so they must be validated, current, and mapped carefully or they can steer the model toward the wrong content set.
• Embedding: An embedding is a machine-readable representation of text or other content used to support similarity search and retrieval. In security terms, embeddings can become a persistence layer for sensitive information if they are created from data that should not be broadly retained or rediscovered.

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.

👉 The full Descope tutorial covers the backend setup, embedding ingestion, and query flow in code.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.