08 RAG Security

Retrieval-Augmented Generation, commonly called RAG, is one of the most important architectures in enterprise AI.

Organizations use RAG to connect Large Language Models with their own information, such as:

• Policies
• Procedures
• Technical documentation
• Security runbooks
• Knowledge bases
• Customer information
• Source code
• Cloud documentation
• Incident records
• Internal reports

Instead of relying only on information learned during model training, the application retrieves relevant enterprise information and provides it to the model.

Conceptually:

User Question
      ↓
Enterprise Knowledge Search
      ↓
Relevant Information
      ↓
LLM
      ↓
Context-Aware Answer

RAG makes AI significantly more useful.

But it also connects the model directly to enterprise information.

This introduces an important security question:

What information can the AI retrieve, who is allowed to retrieve it, and can the retrieved information itself manipulate the AI?

For an AI Security Engineer, securing RAG means protecting the complete pipeline:

Data Source
   ↓
Ingestion
   ↓
Processing
   ↓
Embedding
   ↓
Vector Store
   ↓
Retrieval
   ↓
Authorization
   ↓
LLM Context
   ↓
Response

Learning Objectives

By the end of this lesson, you should be able to:

• Explain Retrieval-Augmented Generation.

• Understand enterprise RAG architecture.

• Understand embeddings and vector databases.

• Identify RAG trust boundaries.

• Secure document ingestion.

• Understand document provenance.

• Recognize RAG poisoning.

• Understand Indirect Prompt Injection through retrieved content.

• Apply authorization-aware retrieval.

• Protect sensitive enterprise information.

• Understand tenant isolation.

• Secure metadata.

• Apply secure indexing practices.

• Understand RAG monitoring.

• Investigate RAG security incidents.

• Perform safe RAG security testing.

• Design secure enterprise RAG architecture.

Why RAG Exists

A general-purpose LLM may not know:

• Your company’s latest policies

• Current internal documentation

• Customer-specific information

• Private cloud architecture

• Internal incident procedures

• Recently updated information

Organizations could attempt to retrain models whenever information changes.

That is often unnecessary.

RAG provides another approach.

Enterprise Knowledge
        ↓
Search Relevant Information
        ↓
Add Information to Prompt
        ↓
LLM Generates Answer

The model receives relevant information at inference time.

Basic RAG Architecture

A simplified RAG architecture looks like:

Enterprise Documents
        ↓
Document Processing
        ↓
Chunking
        ↓
Embedding Model
        ↓
Vector Database

During a user query:

User Question
      ↓
Embedding
      ↓
Vector Search
      ↓
Relevant Chunks
      ↓
LLM Context
      ↓
Response

There are therefore two major workflows:

Ingestion Pipeline

and:

Retrieval Pipeline

Both require security controls.

RAG Ingestion Pipeline

The ingestion pipeline prepares enterprise information for retrieval.

Example:

SharePoint
Git Repository
PDF Documents
Knowledge Base
Security Runbooks
      ↓
Document Loader
      ↓
Parsing
      ↓
Chunking
      ↓
Metadata
      ↓
Embedding
      ↓
Vector Database

Security problems introduced during ingestion may affect every future user of the AI application.

RAG Retrieval Pipeline

During retrieval:

User
 ↓
Question
 ↓
Retriever
 ↓
Vector Database
 ↓
Relevant Documents
 ↓
LLM
 ↓
Response

Security must answer:

Who is the user?

What information can they retrieve?

Which sources can be trusted?

What context should reach the LLM?

Understanding Embeddings

An embedding converts information into a numerical representation.

Conceptually:

"How do I reset my password?"
        ↓
Embedding Model
        ↓
[0.18, -0.42, 0.71, ...]

Documents are converted into similar numerical representations.

This allows the system to find semantically related information.

Vector Search

Suppose the user asks:

How should I respond to a compromised AWS access key?

The system searches for semantically similar content.

It may retrieve:

AWS Credential Incident Runbook

even if the document does not contain the user’s exact wording.

This is extremely useful.

But semantic search creates security challenges because retrieval is based on relevance, not automatically on authorization.

Vector Database

Embeddings and associated information are commonly stored in a vector database.

Conceptually:

Vector Database

Document A
Embedding
Metadata

Document B
Embedding
Metadata

Document C
Embedding
Metadata

Metadata may contain:

• Document ID

• Owner

• Department

• Classification

• Tenant

• Access group

• Source

• Timestamp

This metadata can become extremely important for security.

The RAG Trust Boundary

A RAG system connects:

Enterprise Data
      ↓
AI Application
      ↓
User

The AI application should not weaken existing enterprise access controls.

A critical rule is:

If a user cannot access a document through the original enterprise system, the AI assistant should not make that document accessible through RAG.

RAG Security Risk Areas

A practical RAG security model includes:

Ingestion Security
       +
Source Trust
       +
Document Provenance
       +
Data Classification
       +
Retrieval Authorization
       +
Vector Store Security
       +
Tenant Isolation
       +
Prompt Injection Defense
       +
Output Security
       +
Monitoring

Let’s examine these areas.

Risk 1 — Unauthorized Retrieval

Consider:

Employee
   ↓
Enterprise AI Assistant
   ↓
Vector Database

The database contains:

General Policies
HR Records
Finance Reports
Security Incidents
Executive Documents

If every employee searches the same unrestricted collection:

Employee
   ↓
Semantic Search
   ↓
All Enterprise Documents

the AI may become a shortcut around enterprise permissions.

Weak RAG Architecture

User Authenticated
      ↓
Search Entire Vector Database
      ↓
Relevant Documents
      ↓
LLM

Authentication exists.

But document authorization does not.

Stronger RAG Architecture

User
 ↓
Authentication
 ↓
User Identity
 ↓
Authorization
 ↓
Permitted Documents
 ↓
Vector Search
 ↓
LLM

This is authorization-aware retrieval.

Authorization Before Retrieval

One of the strongest RAG principles is:

Filter what can be retrieved before sensitive information enters model context.

Weak:

Retrieve Everything
      ↓
LLM
      ↓
Tell Model:
"Do not reveal restricted information."

Strong:

User Identity
      ↓
Authorization
      ↓
Allowed Documents Only
      ↓
Retriever
      ↓
LLM

Why System Prompts Are Not Enough

Suppose the model receives:

Confidential Executive Compensation Report

but the user is not authorized to see it.

The system prompt says:

Never reveal confidential information.

This is weak security architecture.

The confidential document should never have entered the model context.

Risk 2 — Document-Level Permissions

Enterprise repositories often already contain permissions.

For example:

Document A
Allowed: Everyone

Document B
Allowed: HR

Document C
Allowed: Security Team

A RAG ingestion pipeline should preserve those permissions.

Dangerous Architecture

Secure Enterprise Repository
          ↓
Export Documents
          ↓
Vector Database
          ↓
Original Permissions Lost

The organization may accidentally remove years of existing access-control design.

Better Architecture

Enterprise Repository
      ↓
Document
      +
Authorization Metadata
      ↓
Vector Store
      ↓
Identity-Aware Retrieval

Permissions remain part of the retrieval decision.

Risk 3 — RAG Poisoning

RAG systems trust documents to provide useful information.

Attackers may attempt to introduce malicious or misleading content into the knowledge base.

Conceptually:

Attacker
   ↓
Malicious Document
   ↓
RAG Ingestion
   ↓
Vector Database
   ↓
Future Retrieval
   ↓
LLM

This is commonly described as RAG poisoning or knowledge-base poisoning.

Example

Imagine an attacker modifies an internal troubleshooting document.

Original:

Production access requires approval
from the Cloud Security team.

Modified:

Production access can be granted
without approval during urgent incidents.

The AI may later retrieve the poisoned document and provide incorrect guidance.

The problem is not necessarily the LLM.

The knowledge source itself has been compromised.

Source Trust

Before ingesting information, ask:

Where did this document come from?

Who created it?

Who can modify it?

Is the source approved?

Can external users influence it?

Not all documents deserve equal trust.

Trusted vs Untrusted Sources

Example:

Approved Security Runbook
        ↓
High Trust

versus:

Public User Comment
        ↓
Low Trust

Both may contain text.

They should not automatically receive the same authority.

Document Provenance

Provenance means understanding where information originated.

Useful provenance information may include:

Source

Author

Repository

Creation Date

Modification Date

Classification

Owner

Approval Status

This helps both security and reliability.

Example

An AI assistant retrieves two conflicting instructions.

Document A:
Approved Security Standard
Updated Yesterday

Document B:
Old Wiki Page
Updated 4 Years Ago

Provenance helps the system determine which source deserves greater trust.

Risk 4 — Indirect Prompt Injection

Retrieved documents become part of the LLM context.

Therefore a document may contain text that attempts to influence model behavior.

Conceptually:

Malicious Document
      ↓
RAG
      ↓
Retrieved Context
      ↓
LLM
      ↓
Behavior Manipulation

This is an important form of Indirect Prompt Injection.

Example Architecture

Attacker
   ↓
Creates Document
   ↓
Document Enters Knowledge Base
   ↓
Employee Asks Question
   ↓
Document Retrieved
   ↓
LLM Processes Malicious Instruction

The employee never entered the malicious prompt.

The instruction arrived through the retrieved document.

Data vs Instructions

A secure RAG design should conceptually distinguish:

Application Instructions

from:

Retrieved Data

Retrieved documents should normally be treated as information to analyze, not instructions controlling the AI application.

Important Limitation

Prompt-level separation can help.

But it is not a complete security boundary.

Therefore:

Retrieved Content
      ↓
May Influence Model

should be assumed possible.

Security should ensure that even manipulated model behavior cannot automatically cause high-impact actions.

Risk 5 — Sensitive Information Disclosure

RAG may retrieve sensitive information such as:

• Customer records

• Employee information

• Source code

• Security architecture

• Incident information

• Business plans

If authorization is weak:

Unauthorized User
      ↓
Semantic Query
      ↓
Sensitive Document
      ↓
LLM
      ↓
Disclosure

This connects directly to the previous lesson on Sensitive Information Disclosure.

Risk 6 — Cross-Tenant Leakage

Multi-tenant RAG systems require particularly strong isolation.

Example:

AI SaaS Platform
      │
      ├── Tenant A
      ├── Tenant B
      └── Tenant C

A retrieval error must never produce:

Tenant A User
      ↓
Tenant B Document

Tenant-Aware Retrieval

A stronger design:

User
 ↓
Tenant Identity
 ↓
Authorization
 ↓
Tenant-Specific Search Scope
 ↓
Retriever

The tenant boundary should exist before retrieval.

Separate Collections

Depending on architecture, organizations may use:

Tenant A Collection

Tenant B Collection

Tenant C Collection

or securely filtered shared infrastructure.

The exact design may differ.

The security requirement does not:

One tenant must not retrieve another tenant’s information.

Risk 7 — Metadata Leakage

Metadata can itself contain sensitive information.

Examples:

File Name:
Executive-Layoff-Plan-2027.pdf

Department:
Mergers-and-Acquisitions

Project:
Secret-Project-X

Even if the document content is protected, metadata may reveal sensitive business information.

Protect Metadata

Treat metadata according to its sensitivity.

Apply:

• Authorization

• Minimal exposure

• Secure logging

• Tenant isolation

Metadata is still data.

Risk 8 — Stale Information

RAG may retrieve outdated information.

Example:

Old Security Runbook
        ↓
AI
        ↓
Outdated Incident Procedure

This may not be a traditional attacker-driven vulnerability.

But it can create security and operational risk.

Freshness Metadata

Useful fields may include:

Created

Updated

Version

Approved

Expired

The system may prioritize current approved information.

Risk 9 — Deleted Documents Remaining Indexed

Suppose a confidential document is removed from the source repository.

But:

Original Document
      ↓
Deleted

while:

Vector Database
      ↓
Old Chunk Still Exists

The information may remain retrievable.

This creates an important lifecycle requirement.

Deletion Propagation

RAG pipelines should support:

Source Document Deleted
        ↓
Associated Chunks Identified
        ↓
Embeddings Removed
        ↓
Cache Removed
        ↓
Retrieval No Longer Possible

Deletion must propagate through the entire pipeline.

Risk 10 — Permission Changes

Suppose:

Yesterday:
Document Allowed to Everyone

but today:

Document Restricted to Finance

If the vector store still contains old authorization metadata:

Employee
   ↓
RAG
   ↓
Document Still Accessible

Permissions must remain synchronized.

Risk 11 — Chunking Security

Documents are often divided into smaller pieces called chunks.

Example:

Document
 ↓
Chunk 1
Chunk 2
Chunk 3
Chunk 4

Permissions should remain associated with each chunk.

Otherwise:

Protected Document
      ↓
Chunk
      ↓
Permission Metadata Lost

may create unintended exposure.

Secure Chunk Metadata

Each chunk may need information such as:

Document ID

Owner

Classification

Tenant

Allowed Group

Source

This allows authorization decisions to remain connected to the original document.

Risk 12 — Vector Database Security

The vector database itself is a sensitive enterprise datastore.

Security controls should include:

• Authentication

• Authorization

• Encryption

• Network restrictions

• Backup protection

• Logging

• Tenant isolation

Do not treat the vector database as harmless because it stores embeddings.

Embeddings Are Not a Security Boundary

A dangerous assumption is:

Text Converted to Embedding
      ↓
Therefore Sensitive Data Is Safe

This is incorrect.

Embeddings and their associated stores should be protected according to the sensitivity of the underlying information.

Risk 13 — Over-Retrieval

Some RAG systems retrieve too much information.

Example:

User asks:
What is our password rotation policy?

Retriever returns:

Password Policy
+
IAM Architecture
+
Incident Runbook
+
Internal Admin Notes

Only one document may have been necessary.

Context Minimization

Prefer:

Relevant Authorized Information
          ↓
LLM

rather than:

Everything Possibly Related
          ↓
LLM

Less context can mean less exposure.

Risk 14 — External Knowledge Sources

Some RAG applications retrieve information from:

• Websites

• Public documentation

• External APIs

• Search engines

These sources should be treated as untrusted.

Architecture:

Internet
 ↓
Retriever
 ↓
LLM

External information may contain:

• Incorrect information

• Malicious instructions

• Manipulated content

• Prompt Injection attempts

Risk 15 — RAG + Agent Combination

RAG becomes especially important when connected to an agent.

Consider:

Enterprise Documents
       ↓
RAG
       ↓
LLM Agent
       ↓
Cloud Tool

Now a malicious retrieved document might influence an agent with enterprise capabilities.

Attack chain:

Malicious Document
      ↓
RAG
      ↓
Indirect Prompt Injection
      ↓
Agent Tool Request
      ↓
Enterprise System

This is why RAG and Agent Security must be designed together.

Breaking the Attack Chain

Even if malicious content influences the model:

Malicious Document
      ↓
LLM
      ↓
Unauthorized Tool Request

the architecture should still enforce:

Tool Request
      ↓
Authorization
      ↓
DENY

This is defense in depth.

Secure Enterprise RAG Architecture

A stronger architecture might look like:

Approved Data Sources
        ↓
Source Validation
        ↓
Document Classification
        ↓
Malware / Content Processing
        ↓
Chunking
        ↓
Permission Metadata
        ↓
Embedding
        ↓
Protected Vector Store

During retrieval:

Authenticated User
        ↓
Identity
        ↓
Tenant / Role / Group
        ↓
Authorization Filter
        ↓
Vector Search
        ↓
Authorized Relevant Chunks
        ↓
Context Minimization
        ↓
LLM
        ↓
Output Controls

Secure Ingestion

The first defense is controlling what enters the knowledge base.

Ask:

Who can add documents?

Which sources are approved?

Who can modify documents?

Is approval required?

Are documents classified?

Ingestion Allowlisting

Instead of:

Any Available Source
      ↓
RAG

prefer:

Approved Source A

Approved Source B

Approved Source C
      ↓
RAG

This reduces the opportunity for knowledge poisoning.

File Security

Documents entering RAG may also be ordinary files.

Existing security controls remain relevant:

• Malware scanning

• File-type restrictions

• Size limits

• Content validation

AI security does not replace traditional file-upload security.

Document Classification

Before indexing:

Document
   ↓
Classification
   ↓
Public / Internal / Confidential / Restricted

The classification can influence:

• Storage

• Retrieval

• Logging

• Access

• Retention

Authorization Metadata

Example:

Document:
Cloud Incident Runbook

Classification:
Confidential

Tenant:
GoHackersCloud

Allowed Groups:
Cloud-Security
SOC

When chunked:

Chunk 1
Tenant: GoHackersCloud
Allowed: Cloud-Security, SOC

Chunk 2
Tenant: GoHackersCloud
Allowed: Cloud-Security, SOC

Permissions remain attached.

Retrieval Authorization

When the user searches:

User
 ↓
Identity:
Student

the retrieval system should determine:

Which documents can Student access?

before returning results.

Retrieval Filtering

Conceptually:

Query
+
User Identity
+
Tenant
+
Role
+
Group
      ↓
Authorized Vector Search

This is stronger than:

Search Everything
      ↓
Filter After Retrieval

especially where sensitive information is involved.

Retrieval Result Validation

Before sending content to the model, applications may validate:

Is this document authorized?

Is it from an approved source?

Is it current?

What is its classification?

How much context is required?

This provides another defensive layer.

Data Minimization

Suppose a 100-page document contains the answer in one paragraph.

Prefer:

Relevant Paragraph
      ↓
LLM

instead of:

Entire 100-Page Document
      ↓
LLM

This reduces unnecessary information exposure.

Citation and Source Visibility

Enterprise RAG systems may provide sources with responses.

Example:

Answer

Source:
Cloud Incident Response Runbook
Version 4.2

This can improve:

• Verification

• Trust

• Investigation

• Governance

Users should be able to understand where important information originated.

Provenance-Aware Responses

For sensitive decisions, the application may surface:

Source

Document Owner

Version

Last Updated

Classification

where appropriate.

This helps users validate the recommendation.

RAG Monitoring

Security teams should monitor important RAG activity.

Potential telemetry includes:

User Identity

Tenant

Query Metadata

Retrieved Document IDs

Document Classification

Authorization Decisions

Source

Model Response Metadata

Logging complete sensitive content may not always be appropriate.

Useful Detection Scenarios

Potential signals include:

Repeated Requests for Restricted Documents

High Retrieval Volume

Cross-Tenant Access Attempts

Unusual Sensitive Data Access

Unexpected Knowledge Sources

Repeated Authorization Denials

These may indicate misuse or compromise.

RAG Audit Trail

Investigators should ideally reconstruct:

Who asked?

What source was searched?

Which documents were retrieved?

What authorization decision occurred?

What information reached the model?

What response was returned?

This significantly improves incident investigation.

RAG Incident Response

Suppose a poisoned document is discovered.

A response workflow may look like:

Detect
 ↓
Identify Source Document
 ↓
Disable / Remove Document
 ↓
Remove Indexed Chunks
 ↓
Invalidate Cache
 ↓
Identify Prior Retrievals
 ↓
Determine Affected Users
 ↓
Investigate Source Compromise
 ↓
Restore Trusted Version
 ↓
Reindex

Data Exposure Incident

If unauthorized information is retrieved:

Detect Exposure
      ↓
Identify User
      ↓
Identify Document
      ↓
Identify Authorization Failure
      ↓
Stop Further Retrieval
      ↓
Determine Scope
      ↓
Remediate Permissions
      ↓
Reindex if Required

Privacy or compliance teams may need involvement depending on the data.

RAG Security Testing

Testing should use authorized environments and synthetic sensitive information whenever possible.

Step 1 — Map the Architecture

Document:

Data Sources

Ingestion Pipeline

Embedding Model

Vector Database

Retriever

Authorization

LLM

Agent Tools

Step 2 — Inventory Data Sources

Example:

Source	Data	Trust	Classification
Public Docs	Product Docs	High	Public
Security Wiki	Runbooks	High	Confidential
User Uploads	Documents	Low	Variable
Internet	External Content	Low	Public/Untrusted

This helps identify trust boundaries.

Step 3 — Identify Roles

Example:

Employee

HR

SOC Analyst

Administrator

Define what each should retrieve.

Step 4 — Create Synthetic Documents

Example:

Document:
TEST-HR-RESTRICTED

Content:
TEST-CONFIDENTIAL-DATA

Allowed Group:
HR

Use test information rather than real confidential data.

Step 5 — Test Authorization

Authenticate as:

Standard Employee

attempt to retrieve:

TEST-HR-RESTRICTED

Expected:

DENY

The document should not enter model context.

Step 6 — Test Tenant Isolation

Create:

Tenant A:
TEST-DATA-A

Tenant B:
TEST-DATA-B

Verify:

Tenant A User

cannot retrieve:

TEST-DATA-B

Step 7 — Test Source Trust

Create an approved test document and an untrusted test document.

Determine:

Can untrusted content enter the index?

How is it identified?

Does it receive the same authority as approved content?

Step 8 — Test Indirect Prompt Injection

Within an isolated test environment, create a synthetic document containing harmless instructions designed to influence model behavior.

For example, the test may attempt to make the model output a harmless marker:

TEST-INJECTION-DETECTED

Then determine:

Was the document retrieved?

Did the model follow document instructions?

Could the behavior affect tools or data?

Keep the test non-destructive.

Step 9 — Test Deletion

Create:

TEST-DOCUMENT-DELETE

Index it.

Verify it is retrievable.

Delete it from the source.

Then verify:

Source Deleted
      ↓
Vector Data Removed
      ↓
No Longer Retrievable

Step 10 — Test Permission Changes

Create:

TEST-DOCUMENT
Allowed:
Everyone

Then change:

Allowed:
Security Team

Verify the RAG system updates accordingly.

Step 11 — Test Metadata Exposure

Check whether unauthorized users can discover:

• Restricted filenames

• Department names

• Document titles

• Classification labels

even when document content is protected.

Step 12 — Test Over-Retrieval

Determine whether simple questions cause excessive amounts of information to enter model context.

Reduce retrieval to the minimum required information.

Step 13 — Test Monitoring

Verify that security teams can identify:

User

Document

Authorization Decision

Retrieval

Time

Result

without unnecessarily logging sensitive content.

Example — Enterprise Security Assistant

Architecture:

SOC Analyst
   ↓
AI Security Assistant
   ↓
RAG
   ↓
Security Knowledge Base

Sources include:

Incident Runbooks

Threat Intelligence

Architecture Documentation

Post-Incident Reports

The application should preserve access controls.

For example:

SOC Tier 1
 ↓
General Runbooks

while:

Security Leadership
 ↓
Sensitive Post-Incident Reports

Example — Cloud Security Assistant

A Cloud Security Engineer asks:

How should we remediate this IAM finding?

RAG retrieves:

Enterprise IAM Standard

AWS Security Runbook

Cloud Architecture Guide

This is valuable because the AI can answer according to company standards rather than only generic knowledge.

But those documents should still be:

• Approved

• Current

• Authorized

• Traceable

Example — AI Security Training

RAG can also support learning platforms.

Architecture:

Student
 ↓
AI Learning Assistant
 ↓
RAG
 ↓
Course Lessons
Labs
Runbooks
Study Guides

The assistant can answer based on approved curriculum content.

Security still matters because:

Student A

should not automatically access:

Instructor-Only Content
Paid Restricted Content
Another Student's Information

RAG authorization should preserve application access rules.

Example — RAG Poisoning Finding

Finding:
Untrusted Documents Can Enter Enterprise RAG Index

Affected Component:
Enterprise AI Knowledge Assistant

Expected Behavior:
Only approved enterprise knowledge sources should be
available to the production RAG system.

Observed Behavior:
Documents from an uncontrolled source can be automatically
ingested and made available for retrieval.

Potential Impact:
An attacker or compromised user may introduce misleading
content or Indirect Prompt Injection instructions that
influence future AI responses.

Recommendation:
Allowlist approved ingestion sources, implement source
ownership and provenance, require appropriate approval,
monitor ingestion changes and isolate untrusted content.

Example — Authorization Finding

Finding:
RAG Retrieval Does Not Enforce Document-Level Authorization

Affected Component:
Enterprise Knowledge Assistant

Expected Behavior:
Users should retrieve only documents available through
their existing enterprise permissions.

Observed Behavior:
A standard test user successfully retrieved synthetic
restricted HR content.

Root Cause:
Vector search is performed across the complete knowledge
base without identity-aware authorization filtering.

Impact:
Users may obtain sensitive enterprise information outside
their approved permissions.

Recommendation:
Preserve source permissions during ingestion and enforce
identity-aware document authorization before retrieval.

Example — Stale Index Finding

Finding:
Deleted Documents Remain Retrievable Through RAG

Affected Component:
RAG Index Synchronization

Observed Behavior:
A synthetic document remained retrievable after deletion
from the source repository.

Potential Impact:
Sensitive information may remain accessible after its
source access has been removed.

Recommendation:
Implement deletion propagation across document chunks,
embeddings, vector indexes and application caches.

RAG Security Checklist

Data Sources

• Approved sources identified.

• Source ownership defined.

• Untrusted sources identified.

• Source provenance maintained.

Ingestion

• Ingestion access restricted.

• File security controls applied.

• Document classification preserved.

• Permission metadata preserved.

• Untrusted content isolated where appropriate.

Chunking

• Document identity preserved.

• Authorization metadata attached.

• Tenant information preserved.

• Classification preserved.

Vector Store

• Authentication enabled.

• Authorization enabled.

• Network access restricted.

• Encryption applied.

• Backups protected.

• Tenant isolation implemented.

Retrieval

• User identity known.

• Authorization enforced before retrieval.

• Tenant filtering applied.

• Document permissions preserved.

• Context minimized.

Sensitive Information

• Restricted data identified.

• Unauthorized data excluded from context.

• Metadata protected.

• Secrets excluded where possible.

Prompt Injection

• Retrieved content treated as untrusted.

• External content separated from application authority.

• Agent tools independently authorized.

Lifecycle

• Document updates synchronized.

• Permission changes synchronized.

• Deleted content removed from indexes.

• Caches invalidated where required.

Monitoring

• Retrieval activity observable.

• Authorization failures logged.

• Sensitive retrieval monitored.

• Ingestion changes monitored.

Incident Response

• Documents can be rapidly removed.

• Embeddings can be deleted.

• RAG indexes can be rebuilt.

• Historical retrieval can be investigated.

Common Beginner Mistakes

Mistake 1 — Treating RAG as Just a Search Feature

RAG creates a new enterprise data-access layer.

Mistake 2 — Authenticating Users but Not Authorizing Documents

Authentication answers:

Who are you?

Authorization answers:

Which documents can you retrieve?

Both are required.

Mistake 3 — Losing Permissions During Ingestion

Source-system permissions should not disappear when documents become embeddings.

Mistake 4 — Trusting Every Document

Documents can be outdated, compromised or attacker-controlled.

Mistake 5 — Ignoring Indirect Prompt Injection

Retrieved content becomes model context and may influence behavior.

Mistake 6 — Assuming Embeddings Are Safe

Embeddings and vector stores still represent sensitive enterprise information.

Mistake 7 — Ignoring Metadata

Sensitive information may exist in document titles and attributes.

Mistake 8 — Forgetting Deletion

Deleting the original document does not automatically guarantee its embeddings disappeared.

Mistake 9 — Retrieving Too Much Context

More context is not automatically better.

Mistake 10 — Securing RAG but Ignoring Agent Tools

A poisoned RAG source becomes more dangerous when the model can take actions.

AI Security Engineer Perspective

When reviewing a RAG application, ask:

Where does the knowledge come from?

Who can add or modify it?

How do we know which source to trust?

What is the data classification?

Are existing permissions preserved?

How is user identity passed to retrieval?

Can users retrieve another tenant's data?

Can documents contain instructions for the model?

Can deleted data remain indexed?

Can permission changes become stale?

What information reaches model context?

What happens if retrieved content manipulates the agent?

Can we investigate who retrieved what?

These questions move the assessment beyond:

Does the chatbot answer correctly?

toward:

Is enterprise knowledge being accessed
and trusted securely?

Interview Perspective

You may be asked:

What is RAG?

A strong answer is:

Retrieval-Augmented Generation allows an AI application to retrieve relevant information from external knowledge sources and provide that information to an LLM as context during inference. It allows enterprises to use current and private information without relying only on the model’s training data.

Another question may be:

What are the main security risks in RAG?

A strong answer is:

Major RAG risks include unauthorized retrieval, sensitive information disclosure, loss of source permissions, cross-tenant leakage, knowledge-base poisoning, Indirect Prompt Injection, insecure vector stores, metadata exposure and stale or deleted information remaining retrievable.

Another question may be:

How would you secure enterprise RAG?

A strong answer is:

I would control ingestion sources, preserve document provenance, classification and permissions, protect the vector store, enforce identity-aware authorization before retrieval, isolate tenants, minimize retrieved context, treat retrieved content as untrusted and independently authorize any agent actions influenced by that content.

Another question may be:

Why isn’t a system prompt enough to protect confidential RAG data?

A strong answer is:

Because once confidential information reaches model context, the application is relying on probabilistic model behavior to protect it. Authorization should occur before retrieval so that unauthorized information never reaches the model.

Another question may be:

What is RAG poisoning?

A strong answer is:

RAG poisoning occurs when malicious, manipulated or misleading information enters the knowledge base and influences future retrieval and model responses. Controls include trusted ingestion sources, provenance, ownership, approval workflows, integrity monitoring and isolation of untrusted content.

Key Takeaways

RAG connects:

Enterprise Knowledge
        ↓
LLM

which makes it both extremely useful and security-sensitive.

The complete RAG security boundary includes:

Source
 ↓
Ingestion
 ↓
Chunking
 ↓
Embedding
 ↓
Vector Store
 ↓
Authorization
 ↓
Retrieval
 ↓
Context
 ↓
LLM
 ↓
Response

The strongest principles are:

• Control what enters the knowledge base.

• Know where information came from.

• Preserve enterprise permissions.

• Enforce authorization before retrieval.

• Maintain tenant isolation.

• Treat retrieved content as untrusted.

• Protect vector databases.

• Minimize retrieved context.

• Protect metadata.

• Synchronize updates and permission changes.

• Propagate deletions.

• Monitor sensitive retrieval.

• Independently authorize agent actions.

Most importantly:

RAG should extend enterprise knowledge access — not bypass enterprise knowledge security.

What’s Next?

➡️ 09 — Vector Database and Embedding Security

You now understand how RAG connects enterprise information with LLM applications.

The next step is to examine one of the most important infrastructure components behind RAG:

Vector databases and embeddings.

In the next lesson, you will learn:

• How vector databases work

• How embeddings are created and stored

• Why embeddings should still be treated as sensitive data

• Vector database authentication and authorization

• Network isolation

• Tenant isolation

• Namespace and collection security

• Metadata protection

• Embedding leakage risks

• Index poisoning

• Backup security

• Encryption

• Access logging

• Lifecycle management

• Secure deletion

• Enterprise vector database architecture

You will move from:

How Do We Secure the RAG Pipeline?

to:

How Do We Protect the Knowledge
Infrastructure Behind RAG?

➡️ Next: 09 — Vector Database and Embedding Security