RAG Security

Review scope and evidence labels

This page defines RAG Security as the security concept for retrieval-augmented generation systems and applications.

Evidence labels used on this page:

Vendor documentation — based on public vendor architecture documentation.
Community security guidance — based on OWASP or similar public security community material.
Community security knowledge base — based on MITRE ATLAS or similar public adversary-knowledge material.
Official guidance — based on public official guidance such as NIST material.
Author analysis — interpretation for AI security, architecture, governance and operational risk on this site.
Implementation evidence required — local records that must exist before a mitigation can be treated as operating.

This entry is a public Research profile. It does not claim that any specific RAG implementation is secure.

Concept snapshot

Field	Value
Category	LLM application and data security
Research type	Concept
Core question	Can the retrieval layer safely provide context without leaking, poisoning or bypassing controls?
Main scope	Documents, indexes, embeddings, retrieval pipelines, access controls, prompts, logs and generated answers
Main risks	Data leakage, unauthorized retrieval, document prompt injection, retrieval poisoning, stale context, weak provenance and missing audit evidence
Companion methods	AI Threat Modeling, OWASP LLM Top 10, MITRE ATLAS, Zero Trust, Audit Evidence
Review status	Public guidance reviewed; implementation depends on local data, identity and architecture design

What RAG Security means

RAG Security is the practice of securing the retrieval layer used by large language model applications. Evidence: Vendor documentation; Community security guidance; Author analysis.

RAG changes the risk profile because the model is not answering only from its base training. It receives context from documents, databases, search results, embeddings or internal knowledge stores. Those sources become part of the attack surface. Evidence: Author analysis.

For this site, RAG Security connects AI Security Architecture, AI Threat Modeling, Zero Trust and Audit Evidence. The central question is whether the system can prove that retrieved context was authorized, trustworthy, relevant and safe to use. Evidence: Author analysis.

What it is not

RAG Security is not:

only vector database security,
only prompt filtering,
only document classification,
a guarantee that retrieved answers are correct,
a replacement for access control,
a replacement for governance or audit evidence,
proof that internal data can safely be exposed to all users.

A RAG system can leak information even when the underlying model is not malicious. The architecture must control what is indexed, who can retrieve it, how retrieved context is used and what evidence is retained. Evidence: Author analysis; Implementation evidence required.

RAG-specific trust boundaries

A simple RAG architecture introduces several boundaries:

User question
     ↓
Application policy and identity checks
     ↓
Retriever / search / vector index
     ↓
Documents, chunks, metadata and permissions
     ↓
Prompt context sent to the model
     ↓
Generated answer, citations, logs and evidence

Security review should ask which identities, permissions, metadata and validation steps exist at each boundary. Evidence: Author analysis.

Common RAG security risks

Risk	Practical question	Evidence to retain
Unauthorized retrieval	Can a user retrieve context they should not see?	Access-control design, tests, permission mapping
Document prompt injection	Can a document instruct the model to ignore policy or leak data?	Abuse tests, source review, output validation
Retrieval poisoning	Can malicious or low-quality content enter the index?	Source governance, ingestion controls, review history
Context overexposure	Is too much sensitive context sent to the model?	Data minimization, chunking rules, prompt/context review
Weak provenance	Can the system prove where the answer came from?	Source metadata, citations, version records
Stale or conflicting knowledge	Can old documents produce wrong operational advice?	Review cadence, freshness metadata, deprecation process
Logging exposure	Do prompts, retrieved chunks or answers create new data leaks?	Logging policy, retention, access controls
Missing audit evidence	Can the organisation prove what was retrieved and why?	Query trace, retrieval trace, decision logs, risk acceptance

Evidence: Community security guidance; Author analysis.

Relationship to existing Research entries

RAG Security connects to:

AI Security Architecture — RAG introduces data and trust boundaries that architecture must show.
AI Threat Modeling — RAG systems need abuse cases for retrieval, poisoning, access control and prompt injection.
OWASP Top 10 for LLM Applications — RAG risks overlap with LLM application risk classes.
MITRE ATLAS — adversary patterns can inform abuse-case design.
AI Governance — ownership, purpose and access decisions must be explicit.
Audit Evidence — retrieval and answer generation claims require records.
Zero Trust — identity, least privilege and telemetry matter for retrieved context.
SBOM — RAG applications still depend on software components, models, libraries and data pipelines.

Practical review checklist

Before a RAG system is treated as production-ready, review at least:

What sources are indexed?
Who owns each source and its classification?
Which users can retrieve which chunks?
Is document-level or chunk-level access enforced?
Can untrusted documents inject instructions into the prompt?
Are retrieved chunks minimized before model use?
Are citations and source metadata preserved?
Are prompts, retrieved chunks and outputs logged safely?
Can the organisation audit what was retrieved and why?
Who accepts residual risk when answers are wrong or incomplete?

Evidence: Vendor documentation; Community security guidance; Author analysis.

Governance relevance

RAG Security is a governance issue because it controls how internal knowledge becomes model context. A RAG system may look like a search feature, but it can influence decisions, expose data and create records that must be governed. Evidence: Author analysis.

Useful governance outputs include a source inventory, access-control model, data-flow map, retrieval-risk register, logging policy, review cadence and audit-evidence checklist. Evidence: Author analysis; Implementation evidence required.

Current limitations and follow-up research

This entry is a concept profile. Real RAG security assessment requires local details: identity provider, document sources, vector database or search engine, chunking strategy, metadata model, access-control enforcement, prompt design, model provider, logs and business process.

Follow-up Research nodes should cover:

Prompt Injection,
IAM for AI systems,
Model Supply Chain Security,
AI Red Teaming,
Data governance for AI systems.