Access-scoped retrieval: when your AI shows a user data they should not see

Retrieval that searches the whole index ignores who is asking. So it can hand one tenant another tenant's document, or a junior a record only executives should read.

Access-scoped retrieval: when your AI shows a user data they should not see

Retrieval searches the index. The index does not know who is asking. So unless you scope the search to the caller’s access, your RAG system can retrieve, quote, and summarize documents the person in front of it was never allowed to open.

An agent runs on someone’s identity

An engineering leader who runs ad-serving infrastructure at a large platform, the kind that answers tens of millions of requests a second, kept coming back to one idea. An agent runs on the credentials of whoever started it. Its access, its tokens, its permissions are that person’s. Nothing an automated process touches escapes the identity behind it, so the identity has to be right, and it has to be enforced at the point where data is actually reached.

RAG breaks that principle by default. The retrieval step usually runs as one system identity with read access to the entire index, because that is the simplest way to build it. The user’s own permissions never enter the search. So the model, acting on behalf of a specific person, quietly gets to reach across the whole corpus regardless of what that person was allowed to see. The access check that would have stopped a direct query never runs, because retrieval went around it.

The leak that looks like a feature

Here is how it surfaces. A multi-tenant product embeds every customer’s documents into one shared index for convenience. A user at company A asks a question. Retrieval finds the best semantic match, which happens to be a document belonging to company B, because meaning does not respect tenant boundaries. The model reads it and answers, helpfully, using company B’s data. To the user it looks like the AI just knew something. To company B it is a breach. Nobody wrote code that decided to leak. The leak was the absence of a filter.

The same thing happens inside one company across roles. Salaries, unreleased plans, legal matters, records scoped to a team. All of it embedded into a general assistant’s index so the assistant can be useful. Then someone without clearance asks a question whose best match is a restricted document, and the model summarizes it back to them in plain language. The AI became a way to read, through a friendly paraphrase, exactly the files the permission system was built to keep separate.

Convenience is what creates the hole

The reason this is so common is that scoping retrieval is more work than not scoping it. One shared index with one service identity is easy to build and demos beautifully, because in the demo everyone is allowed to see everything. Per-user access control means retrieval has to know who the caller is, carry their permissions into the search, and filter candidates to what they may see before ranking. That is real engineering, and it is invisible right up until the wrong document comes back to the wrong person.

There is a cleaner way to think about it. Retrieval is a data-access path, the same as a database query, and it deserves the same access control. You would never let any user run an unfiltered query against every row in the company. Retrieval that searches the whole index is exactly that unfiltered query, wearing the costume of a helpful assistant. The permissions the rest of your system enforces have to follow the data into the retrieval layer, or that layer becomes the way around all of them.

Scope the search to the caller

The fix is to make the caller’s identity part of every retrieval. Tag each chunk with who may see it, tenant, role, group, whatever your model of access is, and filter on that tag before similarity ever runs. The search then considers only documents the caller was allowed to reach, and the closest match is chosen from a permitted set. Done right, the leak becomes impossible rather than unlikely, because the forbidden document was never a candidate.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two week, $2,500 engagement, we check whether retrieval runs as one blanket identity or scopes to the caller. We look at how chunks are tagged for access, whether tenant and role boundaries survive into the search, and where a user could pull a document their own permissions would have denied. We would rather find the cross-tenant match in a diagnosis than in a customer’s incident report.

An assistant that retrieves without checking access is a very polite way to read files you were locked out of.