An internal assistant built on retrieval-augmented generation (RAG) answers from passages it pulls out of an index of company documents, mail and chat. RAG access control decides which of those passages it may pull for the person asking. Three cloud vendors that sell such assistants state the rule in their documentation: answers draw only on content the asking user may already access [4, 5, 6]. The work lies in keeping each document's permissions correct in the index, proving who is asking, and recording what the assistant read.
This explainer covers the retrieval index, where an internal assistant's knowledge comes from. Tool calls, their scopes and their audit logs are the subject of our explainer on MCP access control. The difference between one retrieval pass and an agent that searches again is set out in Agentic RAG and how it differs from standard RAG.
How assistants leak through retrieval
Shared indexes. OWASP's Top 10 for LLM Applications warns that where several classes of users share one vector database, "there's a risk of context leakage between users or queries", and asks for a permission-aware vector database [1]. OWASP's Top 10 for Agentic Applications describes cross-tenant vector bleed: near-duplicate content seeded by an attacker exploits loose namespace filters and pulls another tenant's chunk into retrieval [13].
Oversharing. An assistant that respects permissions inherits their mistakes. One enterprise copilot service "only surfaces organizational data to which individual users have at least view permissions" [4], so a file shared too widely can surface for everyone it is shared with. The same vendor's governance reports exist to find sites with thousands of users, external guests or organization-wide access [7].
Instructions inside retrieved content. Two disclosed cases show the path. CVE-2025-32711, published on 11 June 2025, covers command injection in an enterprise copilot service [28]. The reporting organization scored it 9.3 and the National Vulnerability Database 7.5 [28]. The EchoLeak paper describes a single crafted email, pulled in by normal retrieval, whose hidden instructions made the assistant put sensitive details into an outbound link. The vendor deployed a server-side fix in May 2025 and stated there was no evidence of in-the-wild exploitation [8]. In August 2024, researchers showed a workplace chat platform's assistant retrieving an attacker's public message alongside a victim's private one, then rendering a link that carried the victim's API key [9]. The vendor deployed a patch on 20 August 2024 [10].
In both cases the attacker's text was retrieved inside the victim's own permissions. Permission-aware retrieval bounds what an injected instruction can reach, and it does not stop the injection. Our explainer on prompt injection testing covers how to test an agent for that.
RAG access control: where the check sits
The common pattern stores each document's access list in the index and filters every query on the caller's identity. One cloud search service documents it step by step: load documents with their access control lists (ACLs), get the identity of the caller at query time, and pass it in as a filter, so that results are trimmed to documents that list the user or one of the user's groups [3].
The value in that filter has to come from the server. The service's own page warns that the principal "is just a string, used in a filter expression", with no authentication behind it [11]. A token-checked variant, marked preview, has the service check the caller's token against each result's permissions [3]. In one cloud's worked example, a backend function looks up which patients a doctor may see before it queries the knowledge base [25].
Other approaches carry their own caveats:
| Approach | Caveat in the source | Sources |
|---|---|---|
| Document-level security in a search engine | Roles combine permissively, and aggregates can reveal terms in documents a user cannot open and count how many contain a term | [12] |
| Row security in a relational database | Superusers, and table owners by default, bypass it | [23] |
| A namespace per tenant | Separates tenants, not users inside one (reasoning from [24]). In the vendor's example, a search costs 1 read unit (RU) against 100 RUs with filters on one shared namespace | [24] |
| Search a local index built from the authorization service's change feed, then check each result | The local index can lag revoked rights, so each result is checked before it is shown | [26] |
For role-based access control in a vector database, separate indexes trade memory for speed. The authors of HONEYBEE found that even per-role partitions had memory overheads 7 times larger than one unified index, while post-filtering a shared index lost recall when users could see only a small part of the data [33]. Their dynamic partitioning reported up to 13.5 times lower latency than row-level security with a 1.24 times increase in memory use, on their workloads [33].
Shared conversations add a rule of their own. A September 2025 position paper argues that content used by an assistant must be authorized for every user involved in the interaction [34]. On that view, an assistant answering in a channel or a meeting is limited to what all participants may read.
Acting for the user: delegated tokens
An assistant that reads the index with its own broad service credential holds every user's access at once (reasoning from [2, 27]). RFC 8693, the OAuth 2.0 token exchange standard, separates impersonation, where the acting party "is indistinguishable from" the user, from delegation, where it "still has its own identity" and acts for the user [2]. Its actor claim records in the token "that delegation has occurred" and names the acting party [2]. One identity platform's on-behalf-of flow passes "a user's identity and permissions through the request chain" with delegated scopes only, and roles stay with the user, never with the application [27].
OWASP's agentic list names what goes wrong without this: privileges inherited in full by a narrower agent, a workflow that keeps an old token after the user's rights shrink, and an agent that lets other users act through its maker's identity [13]. An assistant built on one employee's account and shared with colleagues is that last case.
Embeddings, caches and stale permissions
Embeddings, the vectors an index stores for each passage, can give the text back. Morris and colleagues recovered 92% of 32-token inputs exactly from one embedding model's vectors, and 61% from a second model's [15], and OWASP asks for permission-aware vector and embedding stores with strict partitioning [1].
Permissions also change after indexing. In one search service, source changes show in results only after the next sync, and inherited changes on the vendor's document sites need an explicit refresh [3]. Another vendor's connectors pick up ACL changes on each crawl, and the vendor advises a regular re-sync [5]. ConfusedPilot showed an assistant presenting a deleted document from its cache until the next indexing [14]. The Zanzibar paper calls the ordering version of this the "new enemy" problem: old ACLs applied to new content [29]. A check at query time catches rights revoked since indexing [26].
Fixing oversharing before rollout
The source system decides what an assistant shows, so permission fixes land there [4, 5]. While owners review, one vendor's restricted content discovery hides chosen sites from organization-wide search and assistant answers. It "doesn't change existing permissions", and on sites with more than 500,000 items an update can take more than a week to process [16]. The same vendor's restricted search allow-list holds up to 100 sites, "isn't a security boundary" and is meant as a short-term step during a permissions review [20].
Logging what was retrieved
OWASP asks for "detailed immutable logs of retrieval activities" [1]. One vendor's audit records list every resource the assistant accessed for a response, with its sensitivity label, any policy that blocked access and a flag for a detected cross-prompt injection [21]. A log of cited passages alone would have missed the chat case, because the answer's citation did not point to the attacker's message [9]. Our note on how to check LLM citations against their sources sets out how to match each claim to the passage it cites.
Rillor builds internal assistants that work inside a client's systems with each user's own permissions and keep a log of every action they take.
Read the full report
The full report sets the two disclosed cases side by side, compares where the check can sit, quotes the token exchange rules, and adds the sync, cache and logging findings, with all 35 sources.