How does RAG security scope retrieval to user permissions?

01Why permission scoping comes before relevance

Most RAG tutorials begin with chunking, embeddings and ranking. In a product with many customers, those are the second set of decisions. The first is scope.

A retrieval system that ranks well but searches too widely is worse than one that ranks poorly. It will find the most relevant passage in the whole index, and in a multi-tenant product that passage may belong to another customer. The model then writes a fluent answer from it, and nobody notices until a customer does.

The OWASP Top 10 for LLM applications lists vector and embedding weaknesses as a risk of its own, including unauthorized access and leakage between groups that share one vector store. Its recommended mitigations are permission-aware stores, datasets partitioned by access level and logs of retrieval activity. In other words, retrieval needs the same access rules your product already applies everywhere else.

02Decide the partitions

Scope usually has three levels. Map each one before you index anything.

The middle level is often missed. Users rarely think in tenants. They think in the property, project or course they are working on. Scoping retrieval to that object keeps answers inside it, and it also improves relevance, because the search space is smaller and more specific.

Vector databases support this directly. Qdrant's multitenancy guide, for example, recommends one collection with a tenant field in each point's payload, a tenant index on that field and a filter on every query, with separate collections only when a few tenants need strict isolation.

03RAG security: filter before ranking, and fail closed

Where the filter sits matters as much as whether it exists. These are the rules we follow.

1. 01

   Resolve identity first.

   Look up the user, tenant, role and current object from your existing authentication, not from anything the user typed.

2. 02

   Build the filter from that identity.

   Tenant, object and permission conditions, every time.

3. 03

   Filter inside the vector search.

   Apply the filter in the query itself, before similarity ranking and reranking, so out-of-scope chunks never enter the candidate set.

4. 04

   Apply the same scope to everything derived.

   Citations, source lists, document counts and catalog answers such as how many documents mention a topic must respect the same filter.

5. 05

   Fail closed.

   Unknown users, deactivated users and failed permission lookups return no results, not unfiltered results.

6. 06

   Decline when the scope has no answer.

   If the permitted documents do not cover the question, the assistant says so instead of reaching wider or guessing.

7. 07

   Log what was retrieved.

   Store which chunks were returned for which user, so access questions can be answered with facts.

Filtering after ranking is the common shortcut, and it fails in two ways. It can leak, if a bug skips the filter. And it hurts quality, because the top results may all be filtered out, leaving the model with nothing useful.

04Keep permissions in sync with the product

Permissions change. A user leaves a team, a document is restricted, a customer offboards. If the index holds a copy of permissions taken at indexing time, it drifts from the product.

Keep the source of truth in the product. Store stable fields on chunks, such as tenant, object and clearance level, and resolve the user's rights at query time from the live system. When a document is withdrawn or restricted, remove or update its chunks through the same pipeline that indexed them. Where possible, leave originals in the system of record and index only authorized extracted text and metadata.

Test the scope like any other security control. Before launch, build a small set of test users in different tenants and roles, plant documents each one must not see, and ask questions designed to reach them. Run the same set after every change to indexing, filters or prompts. A single failure is a release blocker, not a quality issue to fix later.

05Retrieval is not the only path

In products with agents, retrieval is one of several ways data reaches the model. Tools are another. The same scoping applies: the agent should act under the user's own identity and only through tools allowed for that user's role. A permission-aware index paired with an agent that can call any endpoint is not a secure system. We cover the wider pattern in adding AI agents to an existing SaaS product without rebuilding it and the student data case in AI for K-12 software without touching student data.

06What we see in production

For a short-term rental operations platform, we added an AI operations assistant inside the client's live product, used by owners, cleaner managers and cleaners. Knowledge is partitioned per property, so retrieval over property documents stays inside the property being asked about. The assistant acts only through the client's own APIs under the user's existing identity, with tools allowlisted per role and per channel: cleaners can act only on their own jobs.

In shared property channels, a decision step decides whether the AI should answer at all. Guards stop tool names, IDs and internal fields from appearing in replies, voice calls re-check the user's role on a fresh profile, and production runs with its own vector store and identity setup, separate from development.

For a document-management software company serving government archives, we built a self-hosted, cited knowledge workspace and an AI gateway the client's own system calls. Retrieval is filtered by tenant, collection and clearance before reranking and generation, and the same scope applies to sources, citations, counts and catalog answers. Unknown or deactivated users and failed lookups fail closed.

Conversations stay separate per tenant and per user, answers must cite the passage they came from, and the assistant declines when the documents do not cover a question. Originals stay in the systems of record; the index holds authorized extracted text and metadata. The client's own tests confirmed the system stopped inventing names when documents lack the answer. Per-user identity for the gateway's AI mode is the next step on the backlog, which is a reminder that permission work is never one release.

Roles carry into the writing tools of that workspace too. It has four roles and an admin for each organization, approval is split so a reviewer reads the source before deciding, and only terms an organization has approved, never pending or rejected ones, enter the registry that retrieval shares.

Frequently asked questions