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

At a glance

What this is: This is a tutorial on building a RAG application with Supabase and pgvector, and its central finding is that embedding search alone does not enforce access control.

Why it matters: IAM and application security teams need to treat retrieval permissions as part of the authorization layer, because relevance scoring can surface data that user roles should not see.

Context

RAG applications combine retrieval and generation, which means the security model has to govern both what the system can find and who can see it. In this tutorial, Descope uses Supabase, pgvector, and role-based access to show that similarity search is not the same thing as authorization.

The first part of the build focuses on embeddings, document storage, and query-time retrieval. The identity gap appears when access decisions are deferred until after retrieval, because a search layer can be accurate and still expose content outside the caller's role.

The article frames a common application-security pattern: make retrieval useful, then make it permission-aware. That is the right sequencing for RAG, but it is only secure if the permission model is enforced at the data layer as well as in the application flow.

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 is embedding search not enough to secure retrieval in AI applications?

A: Embedding search only measures semantic similarity, not permission. A document can be highly relevant and still be out of scope for the current user, which means the application must apply authorization separately from ranking. Without that second control, the system can surface data that should remain invisible.

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. The backend must decide what data can be returned and what actions are allowed. Without server-side enforcement, viewers may see restricted content, and lower-privileged users may invoke privileged actions even if the interface hides the controls.

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.

Technical breakdown

Why embeddings do not govern access in RAG apps

Embeddings encode semantic similarity, not entitlement. A vector database can tell you which documents are closest to a query, but it has no native understanding of user role, tenant scope, or data classification unless those controls are added separately. In a RAG stack, that means the model can retrieve relevant text that is still off-limits to the caller. The security boundary therefore cannot sit inside the similarity search itself. It has to sit in the data model, the query path, or both, so retrieval is filtered before content reaches the prompt.

Practical implication: treat vector search as a relevance mechanism, not an authorization control.

How role-aware retrieval works with Supabase RLS

Row-Level Security pushes permission enforcement into the database so that queries return only rows the caller is allowed to see. In the architecture described here, role metadata is stored with each document, and retrieval should be constrained to the caller's role before the application passes content to the LLM. That design matters because it keeps access logic close to the data rather than scattered across client code or prompt handling. It also reduces the chance that a future code change bypasses an application-layer filter and leaks documents across roles.

Practical implication: enforce role checks in the database query path, not only in the frontend or API layer.

Why retrieval and generation must be aligned at query time

RAG introduces two decision points: what gets retrieved and what gets generated from that retrieval. If the first step is overbroad, the second step can faithfully summarise data the user should never have received. Query-time alignment means the application should filter documents by role before similarity scoring or at least before any document is inserted into the prompt context. That preserves the value of embeddings while ensuring the generation step only reasons over authorised content. In identity terms, the app needs the same permission boundary at retrieval time that it expects at response time.

Practical implication: validate that the prompt context contains only documents already authorised for the active role.

NHI Mgmt Group analysis

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.

RAG introduces a new form of permission drift at query time. The data may be correctly classified at rest, but the moment a query assembles context for an LLM, the access decision is effectively re-made. That creates a new control requirement for IAM and application teams: the user role, document scope, and prompt context must stay aligned on every request. The implication is that access control for AI applications has to be enforced where context is assembled, not only where users authenticate.

Descope's example shows why database-enforced authorization matters more than application-layer filtering. Application code can be patched, but retrieval pipelines tend to accumulate shortcuts as teams add sources, roles, and prompt logic. Row-level controls move the trust decision into the system that actually returns the data, which is where RAG risk becomes real. Practitioners should view this as an authorization architecture problem, not a vector search problem.

RAG app security now depends on context scoping as a distinct control domain. The specific concept here is role-aware retrieval: documents are not merely ranked by similarity, they are pre-scoped by the caller's permissions before they ever influence generation. That concept belongs alongside access control, tenancy boundaries, and data minimisation in AI application design. Teams that do not govern context scope will keep building models that answer accurately from the wrong data.

From our research library:

• 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.
• Read next: AI Agent Authorisation Guide

What this signals

Role-aware retrieval changes the security conversation for RAG teams. The key issue is no longer whether the model can find relevant text, but whether the application can prove that every retrieved row belongs within the caller's scope. In practice, that pushes identity and authorization controls closer to the data path and makes database-enforced filtering a design requirement rather than an optimisation.

Context scoping becomes the security control that separates accurate answers from unsafe answers. A RAG system that retrieves correctly but ignores role boundaries will still fail governance review, because the prompt can contain content the caller should not access. Teams should therefore measure retrieval policy coverage as part of application security, not as a prompt-engineering detail.

For practitioners

• 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.
• Verify prompt context before generation Inspect the final document set sent to the LLM and confirm that every item matches the active user role, tenant, or business domain before output is generated.

Key takeaways

• RAG security depends on more than similarity scoring because retrieval can surface information that user roles should not see.
• The main control gap is authorization at query time, where embeddings may be accurate but still unsafe without row-level scoping.
• Teams should enforce role-aware retrieval in the data layer so that only authorised documents can enter the LLM context.

Key terms

• Role-aware Retrieval: Role-aware retrieval is the practice of filtering retrieved content by the caller's permissions before it can influence generation. In RAG systems, it keeps semantic search useful while ensuring the prompt context remains aligned to the active identity's scope.
• 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.
• 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.
• Embedding Similarity: Embedding similarity is a mathematical measure of how closely two text vectors match in semantic space. It is useful for ranking documents, but it does not express user entitlement, tenant isolation, or any other access rule on its own.

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 building or maturing an IAM programme, it is worth exploring.