RAG systems fail at the boundary between data and instruction. A retrieved document should be evidence for an answer, but LLMs can treat document text as an instruction. A vector search result should be scoped to the current user or tenant, but metadata filters, cache layers, and fallback retrieval often drift. A citation should support trust, but hallucinated or cross-scope citations can create the opposite.
This assessment is for teams whose product depends on retrieval-augmented generation and needs confidence that retrieved context cannot leak data, poison behavior, or create a security review blocker.
Minimum cross-tenant test record
A RAG leakage result should be replayable across the retrieval path, not inferred from a suspicious answer. For each test, preserve:
| Record | What it establishes |
|---|---|
| Caller, role, tenant, and allowed document set | The authorization boundary expected for the request |
| Seed or target document ID, owner, tenant, and index metadata | Which content must remain inside or outside that boundary |
| Query, query expansion, filters, reranker inputs, and cache state | The actual retrieval decision path |
| Returned document IDs and assembled model context | Whether unauthorized content reached the model |
| Generated answer, snippets, and citations | Whether content was disclosed or misrepresented to the caller |
| Fixed-version replay of the same preconditions | Whether remediation closed the original path |
A plausible answer with no unauthorized document in the retrieval or context trace is not, by itself, proof of cross-tenant leakage. Likewise, a denied final response does not erase a boundary failure if unauthorized content already entered model-visible context.
Who it is for
You have a knowledge assistant, document QA system, internal search copilot, customer-support RAG workflow, research assistant, legal or compliance reviewer, sales enablement assistant, or any AI feature that retrieves private content before generating an answer.
The risky shape is usually one of these:
- Multiple tenants share the same retrieval infrastructure.
- Users can upload documents, tickets, comments, emails, web pages, or knowledge-base content.
- The model has tools or actions after retrieval.
- Citations, snippets, or source references are shown to users.
- Retrieval falls back across scopes when the expected answer is missing.
- The system uses memory, caches, rerankers, or query expansion that are not independently authorized.
What we test
Ingestion and trust boundaries
We review where documents enter the system, which fields are treated as trusted, how chunks are created, and whether attacker-authored text can be blended with system instructions. This includes uploaded files, crawled pages, support content, internal docs, tickets, and synced SaaS records.
Retrieval authorization
We test whether the current user, tenant, role, and document permissions are enforced before content reaches the model. We look for filter bypasses, missing metadata, stale indexes, query expansion that crosses scope, and fallback retrieval that returns “nearest” content from the wrong boundary.
Indirect prompt injection
We seed or identify document content that instructs the model to ignore system policy, disclose hidden data, call a tool, alter citations, or exfiltrate context. The key question is whether untrusted document text remains data, or becomes a command.
Cross-tenant and cross-user leakage
We test retrieval results, generated answers, citations, snippets, logs, cache behavior, and memory for leakage across tenants or roles. We also test whether a failed authorization path is masked by a plausible-looking answer, which can make the issue harder to catch.
Citation and answer integrity
We check whether citations point to real authorized sources, whether quotes can be fabricated or swapped, and whether users can force the system to cite untrusted content as if it were authoritative.
What you get
- A RAG system map: ingestion sources, index boundaries, metadata, retrieval flow, context assembly, and generation path.
- Reproducible findings with traces showing the retrieved content and generated output.
- Tests mapped to prompt injection, sensitive information disclosure, and access-control failures.
- A fix plan covering retrieval authorization, context isolation, citation controls, and regression tests.
- One retest pass after fixes.
The deliverable is designed to fit inside a broader AI Product Readiness Assessment or stand alone as a focused RAG security review. RAG reviews sit in a higher cost band because retrieval adds ingestion, authorization, and citation paths to test — see what drives AI security audit cost.
Scope, access, process, and limits
Before testing, we agree the source and ingestion inventory, retrieval and index configuration, authorization flow, representative documents, tenant and role accounts, environment, and retrieval paths in scope. You provide controlled access plus traces that show the applied filters, returned document IDs, assembled context, citations, and final output. We use least privilege and do not require raw production secrets.
We map ingestion and retrieval boundaries, validate the agreed accounts and evidence path, run authorization, injection, leakage, and citation tests, produce reproducible findings and a prioritized fix plan, and retest confirmed fixes once.
A clean result covers only the named sources and corpus, indexes, roles, environments, retrieval paths, and system version. It does not cover untested paths or future changes to the corpus, model, cache, filters, or retrieval configuration; those remain residual risk.
Controls we expect to see
Strong RAG systems usually share a few properties:
- Authorization happens before retrieval results enter the model context.
- Tenant, role, and document-scope metadata are mandatory at index time.
- Retrieved content is clearly isolated as untrusted data, not mixed with instructions.
- Tool calls cannot be triggered solely by retrieved content.
- Citations are verified against authorized sources.
- Injection and leakage cases are part of the eval set, not a one-time manual test.
We do not assume those controls exist. We verify them against your system.
Where to start
Read the RAG security guide for the failure modes and the sample report for the evidence format. Our methodology explains how we map findings to frameworks, trust and data handling describes access, confidentiality, and retest rules, and the public verification profile collects the proof links a buyer can inspect before signing. For the shape of a real retrieval engagement, see what we’ve shipped. Then scope a RAG assessment with the actual sources, tenants, and retrieval path you need tested.