RAG Authorization: Keep One Customer’s Data Out of Another’s Answer

01 / Field notes

Executive Summary

A retrieval-augmented generation system can answer accurately from the wrong documents. That is a serious failure when the documents belong to another customer or a restricted internal team. Fluency, relevant citations and a high answer-quality score do not make unauthorized retrieval acceptable.

The boundary belongs before model context is assembled. The application must establish who the user is, determine which documents that identity may access and enforce that decision through retrieval and subsequent document access. Telling a model not to reveal private material after giving it that material is not equivalent protection.

OWASP's RAG security guidance treats ingestion, storage, retrieval and generation as connected security stages. [1] This guide develops an original tenant-isolation test plan for that pipeline; it does not report tests of a commercial product.

02 / Field notes

Prerequisites / Lab Setup

Create two fictional tenants, North and South, with separate test accounts. Give each tenant public team notes and one restricted document. Add a harmless unique marker to each document so that unexpected retrieval is easy to identify. Do not use actual secrets as canaries.

Record the source document ID, tenant, access policy, chunk IDs, index location and version. Identify where authentication is checked, where permissions are resolved and which service account queries the vector store. A shared backend identity may be necessary operationally, but it makes application-side scope enforcement especially important.

03 / Field notes

Technical Analysis

Follow identity into retrieval

A secure request must carry an authenticated principal into the policy decision. Do not accept a tenant identifier supplied by the browser as authoritative merely because it looks valid. Resolve the permitted tenant and resource scope from the authenticated session or another trusted authorization context.

Apply the effective access policy before unauthorized text becomes model context. Some architectures use separate indexes; others use server-controlled metadata filters and additional document checks. Evaluate the complete path rather than declaring one storage layout universally sufficient. If a search backend cannot reliably enforce the required boundary, change the design instead of asking the model to compensate.

Check the caches that sit outside the model

Answer caching can undo careful retrieval isolation. A cache key based only on the question may return an answer generated for another tenant. Include the relevant security context and policy version in the caching design, or avoid caching protected answers where correct invalidation cannot be guaranteed.

Conversation memory needs the same scrutiny. If a user loses access to a project, previous authorized text may still exist in stored chat history. Decide what the application may display and reuse after that change. Do not assume a fresh retrieval filter automatically removes information already present in the conversation context.

In the fictional test, North and South both ask, “What is the renewal deadline?” Their documents contain different dates. A shared answer cache could return North's date to South even though the vector queries themselves are correctly filtered. The failure is in the application boundary, not semantic search quality.

Treat citations as protected routes

A citation is not merely decoration. If it links to a document-download endpoint, that endpoint must authorize the current user independently. An opaque document identifier is not a permission check. Test the same citation after access is revoked and from the other tenant's account.

Log enough to diagnose these decisions without collecting sensitive document bodies unnecessarily. Useful evidence includes request ID, policy version, document IDs and denial reason. Restrict access to traces because identifiers and query text can still expose information about a customer.

Plan for permissions that change

The next challenge in enterprise RAG is not only adding more data sources; it is keeping authorization current as source permissions change. Define a maximum acceptable delay between a source permission update and effective retrieval enforcement. If that delay cannot be bounded, use an authoritative check at access time or restrict the use case.

Search relevance and authorization should have separate acceptance criteria. A less relevant allowed answer is a quality defect. A relevant unauthorized answer is a boundary failure and should block release regardless of the average benchmark score.

04 / Field notes

Mitigation / Defense

For deletion across the pipeline, continue to AI data deletion. For indirect instructions inside retrieved text, use prompt-injection defenses. Authorization and instruction handling address different risks and need separate tests.

05 / Field notes

References

Checked 28 October 2026. OWASP supplies the pipeline-security foundation. The tenants, markers and acceptance matrix are illustrative. Passing this finite test suite does not prove that every possible query is safe; it gives a repeatable way to catch specific boundary regressions.

1. RAG Security Cheat Sheet ↗OWASP · accessed 2026-10-28

Questions readers ask