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.
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.
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. Then scope a RAG assessment with the actual sources, tenants, and retrieval path you need tested.