RAG Security Assessment Checklist

Start With Access

Retrieval-Augmented Generation is not automatically safe because the model only answers from documents.

A RAG system can still leak sensitive data, retrieve the wrong tenant's records, summarize unauthorized material, ingest poisoned documents, follow malicious instructions embedded in retrieved content, or produce outputs that look grounded but are not actually authorized.

The core RAG security question is:

Does the system retrieve and expose only the information this user, tenant, role, workflow, and context are allowed to access?

If the answer depends on the prompt, the system is not secure enough.

OWASP's LLM guidance identifies sensitive information disclosure and vector/embedding weaknesses as major risks for LLM applications. Those categories matter directly for enterprise RAG because vector search, metadata filtering, chunk storage, and generation can become a data-access path.

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.

Transition	Security Risk
User query -> retrieval	Query may retrieve unauthorized documents.
Retrieval -> model context	Sensitive content may enter context before authorization.
Retrieved chunk -> instruction	Malicious document text may act like prompt injection.
Model response -> user	The answer may disclose data from unauthorized sources.
Source logs -> audit trail	Logs may fail to preserve what was retrieved and why.

A RAG system is not just a search feature. It is a data-access path into a probabilistic generation layer.

The Three Big RAG Failure Modes

Most RAG security problems fall into three buckets.

Failure Mode	What Happens	Business Impact
Authorization failure	User retrieves content they should not access.	Customer data leak, contractual breach, privacy issue.
Context poisoning	Retrieved content manipulates model behavior.	Bad decisions, unsafe tool calls, manipulated outputs.
Traceability failure	System cannot reconstruct retrieval and generation path.	Weak response, weak diligence posture, weak auditability.

OWASP's vector and embedding weakness guidance explicitly calls out RAG systems, warning that weaknesses in how vectors and embeddings are generated, stored, or retrieved can enable harmful-content injection, output manipulation, or access to sensitive information.

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.

Control	Review Question
Tenant filtering	Is every retrieval constrained to the user's tenant or organization?
Role filtering	Does retrieval respect the user's role and privileges?
Resource-level ACLs	Are document-level permissions enforced before retrieval?
Metadata integrity	Can metadata be spoofed, omitted, or overwritten?
Server-side enforcement	Are filters enforced by backend logic, not just prompt text?
Cross-tenant testing	Has the system been tested for leakage across tenants or workspaces?

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:

Area	Security Concern
Index design	Are tenants separated physically, logically, or only by metadata?
Embedding metadata	Is authorization metadata preserved with every chunk?
Chunk lineage	Can each chunk be traced back to source document, owner, version, and access policy?
Query filters	Are filters mandatory and server-side enforced?
Similarity thresholds	Can broad queries pull unexpected sensitive context?
Re-indexing	Are permissions re-evaluated when documents or users change?
Deletion	Does removing source access remove retrieval access?

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.

Source Type	Trust Level	Control
Internal approved policy	High	Versioning and access control.
Internal wiki	Medium	Owner validation and freshness check.
Customer-uploaded file	Low	Treat as untrusted content.
Public webpage	Low	Sanitize and label as untrusted.
Email or ticket body	Low	Assume attacker-controlled text is possible.
Third-party document	Medium/Low	Validate source and intended use.

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:

Metadata	Why It Matters
Source document ID	Proves where the content came from.
Tenant ID	Confirms organization boundary.
User/role eligibility	Shows why the requester could access it.
Document classification	Identifies sensitivity.
Version	Prevents stale or superseded guidance.
Timestamp	Supports response and remediation.
Retrieval score	Helps explain why it was selected.
Chunk ID	Links response to exact source material.

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.

Query Pattern	Leakage Risk
"Summarize anything relevant to Company X"	Pulls restricted account notes.
"Compare my account to similar customers"	Reveals other customer data in aggregate.
"What exceptions exist to this policy?"	Surfaces confidential internal process details.
"What does the system know about this person?"	Exposes PII from internal records.
"Give me the exact source language"	Reconstructs restricted document text.

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.

Test	Expected Result
User from Tenant A asks about Tenant B	No retrieval and no summary.
Low-privilege user asks about privileged document	No retrieval and no metadata leak.
User asks for "similar customers"	Aggregation respects authorization.
Retrieved document contains hostile instructions	Instructions ignored or quarantined.
Deleted document is queried	No retrieval after access revocation.
User asks for hidden source text	No unauthorized reconstruction.
Search query omits tenant filter	Backend rejects or constrains request.
Conflicting documents are retrieved	System surfaces uncertainty and source conflict.

The goal is to prove that the system fails closed.

7. RAG Audit Logs Should Preserve Retrieval Decisions

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

Field	Purpose
User ID	Who asked.
Tenant ID	Which boundary applied.
Role/permissions	Why access was allowed.
Query	What was requested.
Retrieval filters	What constraints were applied.
Retrieved chunk IDs	What entered model context.
Source document IDs	Where chunks came from.
Classification labels	Sensitivity of retrieved material.
Model response	What was shown.
Refusal/allow decision	Whether policy intervened.
Trace ID	Links all events together.

The joint CISA/NSA/Five Eyes AI deployment guidance emphasizes secure deployment and operation, including controls that protect AI systems and related data and services.

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.

Deliverable	Description
RAG Architecture & Data-Flow Map	Shows ingestion, chunking, embedding, storage, retrieval, generation, and logging paths.
Tenant-Isolation Review	Validates user, tenant, role, document, and metadata enforcement.
Vector Store Permission Review	Assesses index partitioning, metadata filters, ACL propagation, and deletion behavior.
Prompt-Injection / RAG Poisoning Matrix	Documents hostile retrieved-content scenarios and observed controls.
Remediation Roadmap	Prioritizes pre-launch blockers and post-launch hardening.

RAG Security Checklist

Question	Good Answer
Are retrieval filters enforced server-side?	Yes, always.
Can a user retrieve another tenant's content?	No, verified by negative tests.
Is document authorization checked before model context?	Yes.
Are embeddings and chunks tied to source ACLs?	Yes.
Are external documents labeled untrusted?	Yes.
Are retrieved chunks allowed to instruct the model?	No.
Are logs sufficient to reconstruct retrieval?	Yes.
Are deleted or revoked documents removed from retrieval?	Yes.
Is there a test suite for RAG leakage?	Yes.
Is there an owner for RAG policy and review?	Yes.

Final Thought

RAG security is not about making the model better at answering questions. It is about proving that retrieval, authorization, generation, and logging operate as one secure system.

Before a RAG workflow goes into production, you should be able to answer:

For every generated answer, can we prove the user was authorized to retrieve the underlying source material?

If not, the RAG system is not ready for enterprise use.

What TKOResearch Reviews

TKOResearch performs RAG Security Assessments for teams preparing enterprise review, production launch, customer diligence, or internal AI governance sign-off.

Request RAG Security Review

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