Prevent cross-tenant document leaks in RAG

Two customers ask the same document assistant a question. The second receives a clause from the first customer's contract. Retrieval may have applied its filters correctly: a shared answer cache keyed only by question could be the source of the leak.

This hypothetical case gives access testing a specific target. Tenant separation must survive every path that can return information, including cached answers and source downloads. Checking access when the chat session begins leaves later operations untested.

Map every copy of a document

Follow the file from ingestion through storage, chunks, indexes and generated answers. Include logs and any external service that receives text, such as a reranker or model provider.

For each step, identify the executing identity and the point where permission is enforced. If a restricted passage reaches an external model before being hidden in the interface, filtering the answer came too late. File names and titles can disclose information even when the document body is removed.

OWASP's vector and embedding guidance identifies cross-context leakage and inadequate access controls. Turn that risk into tests for the particular product, including paths that bypass its main search screen.

Derive access from validated identity

The server must establish the requesting user, their tenant and their document access. Free-text instructions, model-generated tool arguments and browser-supplied fields cannot establish that identity on their own.

A tenant may contain private groups or documents restricted to selected users. Tenant filtering alone therefore cannot express every access policy. Preserve the relevant permissions during ingestion and define how membership changes reach the retrieval path.

Use separate credentials for ingestion and ordinary queries. A background indexing job may need broad document access. Reusing its identity for interactive retrieval can bypass the restrictions that the application expects the database to enforce.

Enforce access before content leaves retrieval

Apply permission constraints where search candidates are selected. When candidates are returned as identifiers and later resolved into text, check that read as well before passing content onward.

For PostgreSQL, inspect both the policy and the actual connection role. Its row security documentation explains that superusers and BYPASSRLS roles bypass policies, while table owners normally do too. Configuration alone does not demonstrate that application queries are restricted.

Test with the production role and restricted synthetic identities. Define how retrieval fails when the permission service is unavailable. An assumption that access probably has not changed is insufficient grounds for returning private material.

Give cached answers an access scope

An answer created with broad permissions must not be reused for a narrower audience. Decide whether cache entries belong to a user or to an explicitly verified equivalent access scope. Track document versions and invalidate affected entries when permissions change.

Citation links need their own checks. Opening the source should trigger current authorisation. For signed URLs, document expiration and what happens after access is revoked. An unguessable URL is still a capability that may remain usable until its expiry or another revocation mechanism takes effect.

Inspect support tools and diagnostic logs too. If they expose retrieved content, they need appropriate access controls. Otherwise, a restricted search feature can coexist with an unrestricted internal copy of the same documents.

Exercise permission changes, not just initial access

Create two synthetic tenants with documents containing distinctive test phrases. Ask the same question from each identity and inspect returned chunks, generated text and citations. Attempt to open one tenant's citation using the other identity.

Next, allow a request and revoke access before repeating it. Reuse the existing session and a previously cached question. The expected result should reflect the revocation even while other components still hold copies.

OpenAI's retrieval guide notes that removal from a vector store is eventually consistent. A product requiring immediate denial needs an authorisation mechanism that can enforce that requirement independently of index deletion.

Add incomplete permission metadata and interrupted ingestion to the test set. Record expected and observed outcomes. A restricted document failing to rank highly in one search is not a successful access-control test; the system needs to reject access when the document is targeted directly as well.

Define a review the team can repeat

A useful technical handover includes a map of document copies, access rules for each operation and reproducible revocation tests. State the remaining limits, especially around exported answers or links already delivered to users. Those copies may require a different lifecycle from the live retrieval system.

RAG consulting can examine these controls alongside search quality. The AI technical audit guide describes how to turn a suspected leak into a reproducible finding and an acceptance test.

Explain how your customers are separated and who may read each document. An access matrix and synthetic data provide a practical starting point for a permission review before the assistant reaches a wider audience.