RAG Security
Secure the retrieval path where customer data and model instructions meet.
30 minutes. Bring the evidence, trace, or deadline.
This page is for
- AI platform teams operating multi-tenant retrieval or search assistants
- Security reviewers assessing vector stores, embeddings, and knowledge ingestion
- Founders whose enterprise buyers ask how RAG data is isolated and deleted
Start here
The short answer
Direct answer
A RAG security assessment follows one piece of customer data through ingestion, chunking, embedding, indexing, retrieval, prompt assembly, answer generation, and observability. It tests whether poisoned content, weak filters, cache collisions, or citation gaps can cross a tenant or trust boundary.
Search intent this page serves: Your RAG system produces plausible answers, but you need to prove that retrieval is authorized, sources are trustworthy, and a customer cannot influence another customer’s context.
System boundary
What the assessment follows
The assessment starts with the real trust boundaries. Every included surface has a corresponding scenario, evidence expectation, or retest condition.
Representative flow
- Source system → ingestion queue → normalized document and ownership metadata
- Document → chunks and embeddings → tenant/index namespace → deletion marker
- Authenticated query → permission filter → retrieval/reranking → context assembler
- Context → model → citation and answer validation → response, trace, and feedback
Risk and controls
The control matrix is specific to this system
A finding is useful only when the team can locate the control, observe the failure, name the evidence, and decide what happens next.
| Surface | Failure or risk | Control to inspect | Evidence | Priority |
|---|---|---|---|---|
| Ingestion trust | A document carries hidden instructions, malicious links, or false ownership into the knowledge base. | Authenticate source ownership, sanitize content, label trust, and keep instructions separate from reference data. | Connector permissions, poisoning fixture, quarantine path, and ingestion audit events. | High |
| Index tenancy | Shared indexes or metadata filters permit cross-tenant retrieval or residual data after deletion. | Enforce tenant and resource filters server-side; verify isolation and deletion across replicas and caches. | Cross-tenant negative tests, index policy, deletion replay, and cache-key review. | Critical |
| Query authorization | The user can influence filters, namespaces, or document IDs through query text or tool arguments. | Derive access scope from trusted identity and authorize before retrieval, not after generation. | Policy code, query mutation tests, denied requests, and authorization trace. | Critical |
| Context assembly | Retrieved text overrides system policy or consumes the context budget needed for safe instructions. | Use trust labels, bounded context, instruction separation, and deterministic assembly rules. | Context snapshots, token budgets, adversarial documents, and prompt version. | High |
| Answer and citation | The assistant makes a claim unsupported by retrieved evidence or cites a document the user cannot access. | Check citation support and access, refuse or escalate when evidence is insufficient, and preserve source provenance. | Groundedness cases, citation validator output, refusal examples, and source IDs. | High |
| Lifecycle and feedback | Old or user-submitted content persists in embeddings, traces, evaluation data, or backups after a permission change. | Propagate deletion, version indexes, expire traces, and scrub feedback before reuse. | Deletion SLA, reindex job, backup policy, trace retention, and audit report. | Medium |
Reproducible testing
Scenarios that exercise the boundary
These cases are intentionally concrete. They can be run in a production-adjacent environment with synthetic data and become regression fixtures after remediation.
Cross-tenant query filter bypass
- Precondition
- A shared vector index uses metadata or namespace filters for tenant isolation.
- Exercise
- Mutate query text, document IDs, filters, pagination, and cache keys while alternating two tenant identities.
- Expected control
- The trusted request context reconstructs the filter; no document, citation, or cache entry crosses the tenant boundary.
- Evidence captured
- Returned IDs, authorization trace, cache behavior, and test report.
Poisoned knowledge document
- Precondition
- A user-controlled source can be ingested and later retrieved for a high-value task.
- Exercise
- Insert instructions that request secrets, override policy, or cite a fake source into otherwise relevant content.
- Expected control
- The document is treated as untrusted reference data and cannot change tool scope, system policy, or response destination.
- Evidence captured
- Ingestion label, assembled context, blocked action, and quarantined-source log.
Deletion and stale embedding
- Precondition
- A document is removed or access is revoked after it has been chunked and embedded.
- Exercise
- Delete the source, query immediately and after the index job, then inspect caches, traces, and evaluation fixtures.
- Expected control
- The defined deletion window is honored and stale copies are not returned or exposed to support users.
- Evidence captured
- Deletion timestamps, index version, query results, cache invalidation, and owner sign-off.
Unsupported answer with misleading citation
- Precondition
- A query has partial or conflicting evidence and the assistant normally answers with citations.
- Exercise
- Ask a question that requires an absent fact or combines evidence from inaccessible and stale documents.
- Expected control
- The answer expresses uncertainty or escalates; every citation is accessible, relevant, and supports the claim made.
- Evidence captured
- Retrieved set, claim/citation check, final answer, and human-review decision.
Scope and handoff
What the team receives, and what access is needed
The fixed scope is designed to leave behind implementation artifacts, not a report nobody can rerun.
Deliverables
- RAG data-flow and trust-boundary map from source to answer
- Tenant, resource, index, cache, and deletion control matrix
- Poisoning, filter-bypass, stale-data, and unsupported-citation scenarios
- Retrieval and citation evidence checklist with owners and refresh triggers
- Priority remediation plan for ingestion, authorization, context, and lifecycle
- Retest dataset that can be reused by the RAG evaluation harness
Access requirements
- Representative source connector and ingestion configuration
- Read-only access to index schema, metadata filters, cache policy, and deletion jobs
- Synthetic documents for at least two tenants and one low-trust contributor
- Trace samples showing query, retrieved IDs, prompt version, and citations
- A RAG owner who can approve retention and authorization behavior
Day 1
Trace one document
Follow ownership, classification, chunking, embedding, index placement, retrieval, answer, trace, and deletion.
Days 2–3
Review isolation
Test identity binding, filters, namespaces, caches, source trust, context assembly, and citation access.
Days 4–5
Run RAG abuse cases
Exercise poisoning, cross-tenant access, stale embeddings, context override, and unsupported answers.
Day 6
Package the harness
Deliver findings, fixes, fixtures, source evidence, and a rerun plan tied to future index and model changes.
Retest and limitations
How the result stays current
Rerun Critical isolation cases after any change to tenant filters, namespaces, cache keys, permissions, or deletion jobs. Rerun poisoning and citation cases after ingestion, chunking, reranker, context-template, model, or source-trust changes. Reconfirm deletion after index rebuilds and provider migrations.
Scope limit
RAG security is not proved by retrieval accuracy or a high faithfulness score alone.
Scope limit
The assessment does not certify data privacy or replace a full cloud, database, or connector review.
Scope limit
Deletion timing is reported against the agreed system boundary and retention policy; backup eradication may be a separate control.
Sources and limits
References used for the operating model
These sources provide the framework or vocabulary. The page adds product-boundary tests, evidence requirements, and implementation decisions so the result can be inspected in a live system.
Use it as a risk vocabulary, then test the actual product boundary rather than claiming a checklist is a control.
Metrics such as faithfulness and context precision are useful ingredients; they do not replace product-specific failure slices or acceptance rules.
FAQ
Questions buyers and engineers ask
Is a RAG security assessment the same as a RAG quality audit?
No. It concentrates on trust boundaries, authorization, poisoning, data lifecycle, and citation integrity. Quality metrics are used as supporting evidence, not as proof that access controls hold.
Can you assess a shared vector database?
Yes. Shared indexes are assessed through server-side filters, namespace behavior, cache keys, deletion propagation, and negative tests that attempt cross-tenant reads.
What does the retest dataset contain?
It contains synthetic documents, authorized and unauthorized queries, poisoned-content fixtures, deletion checks, and citation cases mapped to the finding and expected control.
Next step
Turn this page into an owned engineering decision.
Bring the questionnaire, trace, failed workflow, or provider deadline. We will help decide whether a focused implementation is the right scope.
30 minutes. No deck. Leave with a clear next step.