RAG Security Assessment: Tenant Isolation, Data Leakage, and Prompt Injection Risks

For a RAG assessment, I would ask the team to show the documents selected for a user before looking at the generated answer. A plausible answer can conceal an unauthorized retrieval, and an empty answer does not undo content already sent to a model provider.

The boundary includes source permissions, index metadata, retrieval filters, context assembly, citations, caches and logs. A user should receive only material they are currently authorized to access. That policy needs to work when the search is broad, the index is stale, or an uploaded document contains hostile instructions.

OWASP's 2025 vector and embedding guidance describes access-control and poisoning concerns. The practical review below turns those concerns into document-level checks and a runnable synthetic walkthrough.

Why RAG Security Is Different

A common RAG flow looks simple:

User query
  -> embedding / search
  -> vector database or document index
  -> retrieved chunks
  -> LLM context window
  -> generated answer

That flow hides several security-critical transitions.

The retrieval service therefore needs the same care as any other data-access API, with additional review of what generation, caching and citation rendering expose.

Group findings by the failed boundary

For this review, group findings by the boundary that failed. A finding can belong to more than one group.

1. Tenant Isolation Must Happen Before Model Context

The most important RAG control is authorization before model context.

Bad pattern:

Retrieve broadly -> put chunks in prompt -> tell model not to reveal unauthorized data

Better pattern:

Authenticate user -> resolve tenant/role/resource permissions -> retrieve only authorized chunks -> preserve source metadata -> generate answer

The model should never be responsible for deciding whether the user is allowed to see retrieved content. That decision belongs in deterministic authorization logic.

2. Vector Stores Need Security Boundaries

Vector search is optimized for relevance, not security. The most semantically relevant chunk may not be the chunk the user is authorized to see.

A RAG assessment should review:

A vector database should be treated as a security-sensitive data store. It may not store raw documents, but embeddings, metadata, source identifiers, and chunk text can still reveal sensitive information.

3. RAG Poisoning Is Prompt Injection With Storage

Prompt injection becomes more durable when malicious content is stored in a knowledge base.

A hostile document can tell the model to ignore prior instructions, change the task, leak context, or call tools. That text may be hidden in a PDF, support ticket, webpage, resume, email, internal note, documentation page, or customer-uploaded file.

A RAG security review should classify source material by trust level.

Retrieved content should be treated as data, not instruction.

4. Source Attribution Is A Security Control

Source attribution is often presented as a user-experience feature. It is also a security control.

A RAG system should preserve:

Without source attribution, you cannot confidently answer whether the model used authorized, current, trustworthy material.

5. RAG Output Can Leak Even When Raw Documents Are Hidden

A user may not see the raw retrieved document, but the generated answer can still leak the contents.

Sensitive-information disclosure is not limited to direct document display. Summaries, comparisons, generated tables, citations, and paraphrases can all disclose protected information.

6. RAG Systems Need Negative Tests

Do not only test whether RAG returns good answers. Test whether it refuses bad retrieval paths.

For every case, record the exact context and metadata returned, the policy result, and the tested configuration. A refusal sentence alone is insufficient if unauthorized chunks already entered context.

A synthetic two-tenant walkthrough

The RAG boundary reference program, version 1.0 dated September 9, 2026, uses three embedded documents. All names, identifiers, domains and marker strings are synthetic. The program uses Python's standard library; it makes no API calls and does not load a model or create embeddings.

Maya and Ben are authenticated fixture subjects. A query is literal search text. It cannot select a tenant. The retriever returns only permitted candidate IDs and versions, and the context builder reloads current ACLs before releasing document text. The citation renderer uses the same authorization path for titles and source URLs.

Download the program and run:

python3 rag_boundaries.py

The September 9 local run passed 8 tests. The sequence is useful even if the real application uses a completely different search backend:

1. Establish positive controls. Maya can retrieve Amber's marker and Ben can retrieve Birch's. A test that returns nothing for everyone would conceal a broken search implementation.
2. Try cross-tenant retrieval in both directions. Searching for the other tenant's exact marker returns no candidate. Broader shared-word searches still stay inside the subject's permissions.
3. Bypass the first filter in the test harness. Hand a Birch candidate ID to Maya's context builder. The independent ACL check returns no text. This represents a stale cache or defective upstream retriever.
4. Retrieve the hostile note. Its instruction remains literal text labelled untrusted_source. A synthetic send_documents proposal receives tool_not_available; this read-only workflow exposes no sending capability. The test does not ask a model to resist the instruction.
5. Revoke access after search. Clear Maya's ACL on A-1, then reuse the earlier candidate. Both context and citations are empty. Repeating only the initial search would miss this stale-result path.
6. Check citation leakage independently. Submit mixed Amber and Birch candidates. Maya receives Amber's citation only; Birch's title and URL are absent. A hidden document body with a visible confidential title would still be a disclosure.
7. Change and delete source records. Reject a stale version and a deleted document even when the candidate still exists in memory.

The marker strings make accidental cross-tenant content easier to spot. They do not measure all forms of disclosure. A production evaluation must also inspect paraphrases, summaries, answer caches, error messages, reranker inputs and user-visible source metadata.

The reference verifies its own deterministic policy and output construction. It cannot establish vector-store isolation, live ACL synchronization, provider retention, model resistance to injection, or safe behavior under concurrency. Labelling hostile text is demonstrated; a model obeying that label is not. These distinctions matter when reporting a passing run.

Every fixture is recreated in memory on each run. The scripts write no data files and contact no reserved example address. There is no test data to delete from a provider. You can remove the downloaded script when finished; see the reference README for the complete local setup and limits.

MSP document search needs a client boundary at every hop

For an MSP, substitute “client organization” for tenant. An operator who legitimately supports Amber and Birch should still choose an explicit client workspace for a customer-facing answer. A broad operator entitlement must not become permission to send Birch's notes to an Amber recipient.

Check intake routing, connector identity, chunk metadata, search filters, answer caches and citations using the same client identifier. An intentionally cross-client administrative search needs its own authorized audience and workflow. Do not silently reuse that broader path for a client portal. The local example covers isolated retrieval; it does not model multi-client operator delegation.

7. RAG Audit Logs Should Preserve Retrieval Decisions

If there is a RAG failure, the organization must reconstruct what happened.

Apply access controls to the audit store too. A cross-tenant document ID or sensitive query in a broadly accessible trace viewer can create a second disclosure path.

What The Review Should Leave Behind

The review should make retrieval behavior visible: where content enters the system, what policy decides access, and what logs prove the answer came from authorized material.

RAG Security Checklist

Carry the checks into the real retrieval path

The local walkthrough is a starting point for test design. Run equivalent cases against the application's actual source connectors, index, reranker, context builder, model and citation renderer in an authorized test environment. Record versions and distinguish unauthorized retrieval, generated disclosure and blocked tool attempts.

Keep those cases when changing chunking, models, metadata or caches. A review of one retrieval endpoint does not cover another endpoint that uses different filters. The RAG boundary worksheet can hold the deployment-specific questions and owners.

Sources

• OWASP 2025 LLM Top 10
• OWASP AI Agent Security Cheat Sheet