Lab 02 Threat Model an Enterprise RAG Application

Mission Information

In this lab, you will perform a focused threat modeling assessment of an Enterprise RAG Application.

Unlike the previous lab, where you threat modeled a broader AI application, this lab goes deeper into the RAG lifecycle.

You will analyze:

Enterprise knowledge sources
Data classification
Source permissions
RAG ingestion
Document parsing and chunking
Embeddings
Vector database security
Retrieval authorization
Department and tenant isolation
Knowledge poisoning
Indirect prompt injection
Sensitive information disclosure
RAG logging
Detection opportunities
Incident response
Residual risk

The goal is to move from:

“RAG connects an LLM to enterprise data.”

to:

“I can identify where an enterprise RAG architecture can fail, how attackers could abuse it, and what controls are required.”

Lab Difficulty

Intermediate

Estimated Time

90–120 minutes

Lab Type

Architecture Review + Threat Modeling + Security Design

Prerequisites

Before starting this lab, you should understand:

LLM fundamentals
RAG architecture
Embeddings
Vector databases
AI threat modeling
Assets and data classification
Trust boundaries
STRIDE
OWASP GenAI security concepts
MITRE ATLAS concepts
Attack path analysis
Risk assessment
Threat-to-control mapping

What You Will Build

By the end of this lab, you will create:

Enterprise-RAG-Threat-Model/
│
├── 01 Business Context.md
├── 02 RAG Architecture.md
├── 03 Knowledge Source Register.md
├── 04 Asset Register.md
├── 05 RAG Data Flow Register.md
├── 06 Trust Boundary Register.md
├── 07 RAG Attack Surface Register.md
├── 08 RAG Threat Register.md
├── 09 RAG Attack Paths.md
├── 10 RAG Risk Register.md
├── 11 RAG Security Requirements.md
├── 12 Detection and Response.md
└── 13 Executive Summary.md

Scenario

You are working as an AI Security Engineer for an enterprise organization.

The company is deploying an internal application called:

Enterprise Knowledge Copilot

Employees will use the application to search internal company information using natural language.

The system retrieves information from several enterprise data sources and sends relevant content to an LLM to generate answers.

The organization wants you to perform a focused RAG security assessment before production deployment.

Enterprise Knowledge Sources

The RAG system indexes:

General Company Documentation
IT Procedures
Security Documentation
HR Policies
Engineering Documentation
Customer Support Knowledge
Executive Policies

Not every employee is authorized to access every source.

For example:

General Employee
   ↓
General Documentation
IT Procedures

HR employees may additionally access:

HR Policies
Employee Records

Security teams may access:

Security Architecture
Incident Procedures
Security Runbooks

Executive documentation should be restricted to approved users.

Target RAG Architecture

Use the following architecture:

                         Employee
                            │
                            │ SSO + MFA
                            ▼
                     AI Web Application
                            │
                            ▼
                     AI Orchestrator
                            │
                            ▼
                       RAG Service
                            │
              ┌─────────────┼─────────────┐
              │             │             │
              ▼             ▼             ▼
        Query Embedding   Authorization   Retrieval
              │                             │
              └──────────────┬──────────────┘
                             ▼
                       Vector Database
                             │
                             ▼
                      Retrieved Chunks
                             │
                             ▼
                      External / Internal
                            LLM
                             │
                             ▼
                         Response

The knowledge ingestion flow is:

Enterprise Repository
        ↓
Ingestion Service
        ↓
Document Parser
        ↓
Chunking
        ↓
Embedding Model
        ↓
Vector Database

These two flows must be threat modeled separately.

Step 1 — Understand the Business Context

Create:

01 Business Context.md

Use:

# Business Context

## System Name

Enterprise Knowledge Copilot

## Business Purpose

Provide employees with natural-language access to approved enterprise documentation using Retrieval-Augmented Generation.

## Primary Users

- General Employees
- IT Operations
- Security Team
- HR Team
- Engineering
- Executives

## Business Criticality

High

## Sensitive Functions

- Enterprise knowledge retrieval
- Confidential document access
- Cross-department information search

## Key Security Objective

Users must only retrieve information they are already authorized to access.

Student Task

Answer:

Why is RAG being used?
Which business groups use the application?
Which knowledge sources contain confidential information?
What would happen if a general employee retrieved HR information?
What would happen if security documentation were poisoned?
What would happen if executive data were exposed?

Step 2 — Define Scope

In Scope

AI Web Application
AI Orchestrator
RAG Service
Knowledge Sources
Ingestion Service
Document Parser
Chunking
Embedding Model
Vector Database
Retrieval Authorization
LLM Context
RAG Logging
Relevant Service Identities

Out of Scope

Endpoint Security
Physical Security
Identity Provider Internal Architecture
LLM Provider Internal Infrastructure

Create:

## Scope

### In Scope

### Out of Scope

### Assumptions

### Unknowns

Step 3 — Document Assumptions

Use these initial assumptions:

Employees authenticate through SSO.

MFA is enabled.

Vector database is not publicly accessible.

RAG service uses a dedicated workload identity.

Enterprise document repositories already contain access-control permissions.

All RAG queries pass through the application layer.

Do not assume:

Source ACLs are preserved during ingestion.
Vector metadata is trustworthy.
Retrieved content is safe.
Only trusted users can modify every source.
The external embedding provider retains no data.
Document deletion automatically removes vector entries.

These require validation.

Step 4 — Map the Knowledge Sources

Create:

03 Knowledge Source Register.md

Use:

ID	Knowledge Source	Owner	Classification	Authorized Users	Modification Rights
KS-01	General Policies	Corporate IT	Internal	All Employees	Content Team
KS-02	IT Procedures	IT	Internal	IT + Employees	IT
KS-03	Security Documentation	Security	Confidential	Security Team	Security
KS-04	HR Policies	HR	Confidential	HR + Employees where approved	HR
KS-05	Employee Records	HR	Restricted	HR Only	HR
KS-06	Engineering Docs	Engineering	Confidential	Engineering	Engineering
KS-07	Executive Policies	Executive Office	Restricted	Executives	Executive Office

Student Task

Add:

Source type
Business owner
Technical owner
Sensitivity
Ingestion method
Review frequency

Step 5 — Identify High-Risk Knowledge Sources

Identify your crown-jewel sources.

Example:

CJ-RAG-01 Employee Records

CJ-RAG-02 Security Architecture

CJ-RAG-03 Executive Policies

For each one answer:

What happens if it is disclosed?

What happens if it is modified?

What happens if it becomes unavailable?

Step 6 — Map the Ingestion Flow

Create:

02 RAG Architecture.md

Document:

Source Repository
      ↓
Ingestion Service
      ↓
Parser
      ↓
Chunking
      ↓
Embedding
      ↓
Vector Database

Now annotate:

Identity
Data Classification
Authorization
Logging
Trust Boundary

for each step.

Step 7 — Map the Retrieval Flow

Document:

Employee
   ↓
Query
   ↓
Application
   ↓
RAG Service
   ↓
Authorization
   ↓
Vector Search
   ↓
Retrieved Chunks
   ↓
LLM Context
   ↓
Response

The most important question is:

Where and how is the initiating user’s authorization enforced?

Step 8 — Build the RAG Data Flow Register

Create:

05 RAG Data Flow Register.md

Use:

ID	Source	Destination	Data	Identity	Classification
DF-R01	Repository	Ingestion	Document	Ingestion ID	Mixed
DF-R02	Parser	Embedding	Document Chunk	Ingestion ID	Mixed
DF-R03	Embedding	Vector DB	Embedding + Metadata	Service ID	Confidential
DF-R04	User	RAG	Query	Employee	Internal
DF-R05	RAG	Vector DB	Vector Query	RAG ID	Confidential
DF-R06	Vector DB	RAG	Retrieved Chunks	RAG ID	Mixed
DF-R07	RAG	LLM	Query + Context	AI ID	Confidential
DF-R08	LLM	User	Generated Response	Application	Mixed

Student Task

For each data flow record:

Protocol
Authentication
Authorization
Encryption
Logging
External boundary
Retention

Step 9 — Identify RAG Assets

Create:

04 Asset Register.md

Include:

ID	Asset	Classification	Criticality
A-R01	Source Documents	Mixed	High
A-R02	Source ACLs	Restricted	Critical
A-R03	Ingestion Identity	Restricted	High
A-R04	Embeddings	Confidential	High
A-R05	Vector Database	Confidential	Critical
A-R06	Vector Metadata	Confidential	Critical
A-R07	RAG Service Identity	Restricted	Critical
A-R08	Retrieval Logs	Confidential	High
A-R09	User Queries	Confidential	Medium/High
A-R10	Retrieved Context	Confidential	High

Add security objectives for:

Confidentiality
Integrity
Availability

Step 10 — Identify Trust Boundaries

Create:

06 Trust Boundary Register.md

Start with:

ID	Boundary	Primary Concern
TB-R01	Contributor → Repository	Malicious content
TB-R02	Repository → Ingestion	Source trust
TB-R03	Ingestion → Vector DB	Unauthorized writes
TB-R04	User → RAG	Query abuse
TB-R05	RAG → Vector DB	Data authorization
TB-R06	Retrieved Content → LLM	Untrusted context
TB-R07	Enterprise → External LLM	Data disclosure

Student Task

For every boundary document:

Source
Destination
Identity
Data
Trust Change
Existing Control
Failure Impact

Step 11 — Identify RAG Threat Actors

Consider:

TA-R01 Compromised Employee

TA-R02 Malicious Insider

TA-R03 Malicious Document Contributor

TA-R04 Compromised Repository Administrator

TA-R05 Compromised RAG Service

TA-R06 Supply-Chain Attacker

TA-R07 External Content Author

For each one document:

Existing access
Capabilities
Motivation
Reachable surfaces
Target assets

Step 12 — Map the RAG Attack Surface

Create:

07 RAG Attack Surface Register.md

Include:

ID	Attack Surface	Exposure	Primary Threat
AS-R01	Document Upload	Internal	Poisoning
AS-R02	Source Repository	Internal	Unauthorized modification
AS-R03	Ingestion Service	Privileged	Pipeline compromise
AS-R04	Parser	Internal	Malformed content
AS-R05	Embedding API	External/Internal	Sensitive data exposure
AS-R06	Vector DB Query	Private	Unauthorized retrieval
AS-R07	Vector DB Write	Privileged	Poisoning
AS-R08	RAG Search	Internal	Data disclosure
AS-R09	LLM Context	Internal/External	Indirect prompt injection

Step 13 — Threat Model Source Permissions

The source repository may contain ACLs such as:

HR Document

Allowed:
HR-Team

During ingestion, ask:

Is the ACL preserved with every chunk?

A dangerous workflow is:

HR Document
     ↓
Chunking
     ↓
Embedding
     ↓
Vector Record
     ↓
No Access Metadata

Now the RAG system may no longer know that the content was HR-only.

Threat Scenario

Normal Employee
      ↓
RAG Search
      ↓
Matching HR Vector
      ↓
Retrieved HR Content

This is a major enterprise RAG risk.

Step 14 — Validate ACL Preservation

Define the desired architecture:

Source Document
      ↓
Original ACL
      ↓
Chunk
      ↓
Embedding
      ↓
Vector Metadata
      ↓
Authorization Filter

Example metadata:

document_id = HR-001

classification = confidential

department = HR

allowed_group = HR-Team

Security Requirement

RAG-SEC-001

Source-document authorization attributes must be preserved during ingestion and applied during retrieval.

Step 15 — Threat Model Unauthorized Retrieval

Create:

08 RAG Threat Register.md

RAG-T01 — Unauthorized Cross-Department Retrieval

Threat Actor

Compromised or curious employee

Target

Restricted knowledge

Attack Path

Authenticated Employee
       ↓
RAG Query
       ↓
Vector Search
       ↓
Weak Authorization Filter
       ↓
Restricted HR Chunk
       ↓
LLM Response

Impact

Confidential information disclosure.

STRIDE

Information Disclosure / Elevation of Privilege

Risk

Critical

Step 16 — Threat Model Cross-Tenant Retrieval

Imagine the same RAG infrastructure serves two business units.

Business Unit A
      ↓
Shared Vector Database
      ↑
Business Unit B

Threat:

User A
 ↓
Vector Query
 ↓
Filtering Error
 ↓
Business Unit B Data

Security Requirements

Tenant identifier on every vector record
Server-side tenant filtering
No user-controlled tenant bypass
Isolation tests

Step 17 — Threat Model Knowledge Poisoning

RAG-T02 — Malicious Knowledge Modification

Attack path:

Malicious Contributor
       ↓
Modify Document
       ↓
RAG Ingestion
       ↓
Vector Database
       ↓
Employee Query
       ↓
Manipulated Answer

Possible targets:

Security procedures
HR guidance
Engineering runbooks

Potential impact:

Incorrect business decisions
Unsafe security actions
User deception

Step 18 — Poisoning Persistence

RAG poisoning may persist.

One Malicious Modification
        ↓
Vector Database
        ↓
Hundreds of Future Queries

This is different from a one-session prompt attack.

Consider persistence when rating risk.

Step 19 — Poisoning Controls

Map:

Prevent

Restricted content contributors
Approval workflows
Source ownership
Version control

Detect

Sensitive document change alerts
Unusual contributor activity
Ingestion change monitoring

Respond

Remove document
Rebuild affected vectors
Review previous retrievals

Step 20 — Threat Model Indirect Prompt Injection

RAG-T03 — Malicious Instructions in Retrieved Content

Architecture:

Malicious Document
       ↓
RAG
       ↓
LLM Context

The document might contain natural language intended to manipulate the model.

Threat modeling must treat retrieved content as:

Potentially untrusted context

even when the document exists in an enterprise system.

Step 21 — Compare Data and Instructions

The application expects:

Document = Data

But the LLM may see:

Document = Natural Language

and natural language may contain:

Instructions

This creates a fundamental trust problem.

Step 22 — Indirect Prompt Injection Impact

In this lab, the application only generates responses.

Potential impacts may include:

Incorrect response
Sensitive information disclosure
Policy bypass

If the architecture later adds an agent:

RAG
 ↓
LLM
 ↓
AI Agent
 ↓
Tool

the same threat may become much more severe.

This is an important risk-assessment lesson.

Step 23 — Threat Model Embedding Provider

Suppose the company uses an external embedding service.

Architecture:

Confidential Document Chunk
        ↓
External Embedding API

Ask:

Is confidential data leaving the organization?
Is data stored?
Is data used for training?
Where is it processed?
Is encryption used?
Is the provider approved?

Threat

Enterprise Data
      ↓
External Service
      ↓
Unauthorized Disclosure / Retention

Step 24 — Threat Model Vector Database Access

Review:

Who Can Query?

Who Can Write?

Who Can Delete?

Who Can Administer?

A dangerous permission model:

RAG Service
  ├── READ
  ├── WRITE
  ├── DELETE
  └── ADMIN

if retrieval only requires:

READ

Apply least privilege.

Step 25 — Threat Model Vector Database Compromise

RAG-T04 — Compromised Vector Database Identity

Attack path:

Attacker
   ↓
Compromised RAG Credential
   ↓
Vector Database
   ↓
Read / Modify Records

Possible outcomes:

Sensitive data extraction
Metadata modification
Poisoning
Service disruption

Step 26 — Threat Model Metadata Tampering

Authorization may depend on metadata.

Example:

classification = restricted
department = HR

Attacker changes:

classification = internal
department = general

Now authorization may fail.

This is:

Integrity failure leading to confidentiality failure.

Step 27 — Threat Model Document Deletion

Suppose HR deletes an employee document from the source repository.

Ask:

Does the RAG system remove the vector record?

Weak lifecycle:

Source Deleted
      ↓
Vector Record Remains
      ↓
Still Searchable

Required lifecycle:

Source Deleted
      ↓
Deletion Event
      ↓
RAG Index Update
      ↓
Vector Record Removed

Step 28 — Threat Model Stale Data

Threats do not always require an attacker.

Example:

Old Security Procedure
      ↓
RAG
      ↓
AI Recommendation
      ↓
Incorrect Action

Threat modeling should include data freshness where business impact is meaningful.

Step 29 — Threat Model Query Privacy

Employee queries may contain:

Customer names
Incident data
Internal vulnerabilities
Employee information

Map:

User Query
   ↓
Application Logs
   ↓
RAG
   ↓
LLM

Ask where the query is:

Stored
Logged
Retained
Transmitted

Step 30 — Threat Model Raw Retrieval Exposure

Some applications expose citations or retrieved chunks.

Consider:

LLM Response

Source Document Name

Raw Retrieved Text

Source URL

Could any of these reveal information the user should not see?

Authorization must apply to supporting context as well as the final answer.

Step 31 — Threat Model Resource Abuse

Attack path:

User
 ↓
Large Number of Queries
 ↓
Embedding
 ↓
Vector Search
 ↓
Large Retrieval
 ↓
LLM

Possible impact:

High cost
High latency
Resource exhaustion
Service degradation

Controls:

Rate limits
Retrieval limits
Token limits
Quotas
Cost monitoring

Step 32 — Apply STRIDE to RAG

Document at least one scenario for each category.

Spoofing

Compromised employee accesses RAG.

Tampering

Vector metadata or knowledge source modified.

Repudiation

Retrieval cannot be attributed to user.

Information Disclosure

Restricted knowledge retrieved.

Denial of Service

RAG requests exhaust resources.

Elevation of Privilege

General employee gains access to privileged knowledge.

Step 33 — Apply OWASP GenAI Guidance

Review relevant current OWASP guidance for areas such as:

Prompt injection
Sensitive information disclosure
Data poisoning
Vector and embedding weaknesses
Resource consumption

For each threat, explain:

Why does this guidance apply to this specific architecture?

Do not just copy a risk name.

Step 34 — Apply MITRE ATLAS

For high-priority RAG scenarios, consider adversary behaviors involving:

AI system discovery
Data manipulation
Collection
Defense evasion
Impact

Validate current ATLAS mappings when performing a real assessment.

Step 35 — Build Attack Path AP-R01

Unauthorized HR Retrieval

Compromised Employee
       ↓
Enterprise AI Application
       ↓
RAG Query
       ↓
Vector Search
       ↓
Missing HR Authorization
       ↓
HR Document
       ↓
LLM
       ↓
Sensitive Response

Control Breakpoints

Identity Validation
      ↓
Document-Level Authorization
      ↓
Data Segmentation
      ↓
Retrieval Monitoring

Step 36 — Build Attack Path AP-R02

Knowledge Poisoning

Malicious Contributor
       ↓
Security Procedure
       ↓
RAG Ingestion
       ↓
Vector Database
       ↓
Employee Query
       ↓
Poisoned Context
       ↓
Incorrect Security Guidance

Breakpoints

Contributor Restrictions
      ↓
Document Approval
      ↓
Change Monitoring
      ↓
Provenance

Step 37 — Build Attack Path AP-R03

Indirect Prompt Injection

External / Internal Attacker
        ↓
Malicious Content
        ↓
Enterprise Repository
        ↓
RAG
        ↓
LLM Context
        ↓
Manipulated Response

If an agent exists:

Manipulated Response
        ↓
AI Agent
        ↓
Enterprise Tool

This should increase risk considerably.

Step 38 — Build Attack Path AP-R04

Vector Database Credential Compromise

Attacker
   ↓
RAG Service Credential
   ↓
Vector Database
   ↓
Sensitive Records

Possible actions:

READ
MODIFY
DELETE

Determine the blast radius.

Step 39 — Build the RAG Risk Register

Create:

10 RAG Risk Register.md

Example:

ID	Threat	Likelihood	Impact	Inherent Risk
RAG-R01	Unauthorized Retrieval	High	Critical	Critical
RAG-R02	Knowledge Poisoning	Medium	High	High
RAG-R03	Indirect Prompt Injection	Medium	High	High
RAG-R04	Vector DB Compromise	Medium	Critical	Critical
RAG-R05	External Embedding Exposure	Medium	High	High
RAG-R06	Resource Abuse	High	Medium	High
RAG-R07	Stale Data	Medium	Medium	Medium

Step 40 — Prioritize the Risks

For this architecture, likely priority areas include:

1. Unauthorized Retrieval
2. Vector Database Access
3. Knowledge Poisoning
4. Indirect Prompt Injection
5. External Provider Data Handling
6. Logging and Monitoring
7. Resource Abuse

Your ranking should be based on the actual controls and business context.

Step 41 — Define RAG Security Requirements

Create:

11 RAG Security Requirements.md

RAG-SEC-001

RAG retrieval must enforce source-document authorization using the initiating user's identity.

RAG-SEC-002

Source ACL and classification metadata must be preserved through ingestion and retrieval.

RAG-SEC-003

Only approved identities may modify production RAG knowledge sources.

RAG-SEC-004

The vector database must use dedicated least-privilege workload identities.

RAG-SEC-005

Retrieved content must be treated as potentially untrusted AI context.

RAG-SEC-006

Sensitive document modifications and RAG ingestion events must be auditable.

RAG-SEC-007

Deleted source documents must be removed from the retrieval index within the defined lifecycle requirement.

RAG-SEC-008

External embedding and LLM providers must be approved for the data classification being transmitted.

RAG-SEC-009

RAG retrieval activity involving sensitive knowledge must be centrally logged.

RAG-SEC-010

Rate limits and retrieval limits must be implemented to reduce resource and cost abuse.

Step 42 — Build Authorization Validation Tests

Use at least three user profiles:

User A — General Employee

User B — HR Employee

User C — Security Engineer

Create test cases.

Document	User A	User B	User C
General Policy	Allow	Allow	Allow
HR Record	Deny	Allow	Deny
Security Architecture	Deny	Deny	Allow
Executive Policy	Deny	Deny	Deny unless approved

Your RAG system should produce the same authorization result as the source system.

Step 43 — Validate Poisoning Controls

Test scenario:

Create an authorized test document.
Modify its content.
Observe whether the modification is:
- logged
- approved
- re-ingested
- attributable
Verify whether prior versions are recoverable.

Do not test malicious payloads in production systems.

Use controlled test content and authorized environments.

Step 44 — Validate Deletion

Test:

Create Document
      ↓
Ingest
      ↓
Confirm Retrieval
      ↓
Delete Source
      ↓
Trigger Index Update
      ↓
Attempt Retrieval

Expected:

NOT RETRIEVABLE

Document any delay between source deletion and index removal.

Step 45 — Define RAG Detection Use Cases

Create:

12 Detection and Response.md

DET-R01 — High-Volume Retrieval

Detect users retrieving an unusually large amount of knowledge.

DET-R02 — Cross-Domain Access

Detect unusual attempts to access multiple sensitive departments.

DET-R03 — Sensitive Source Modification

Detect changes to HR, Security or Executive knowledge.

DET-R04 — Vector Database Administrative Changes

Detect unexpected writes, deletes or permission changes.

DET-R05 — RAG Service Identity Anomaly

Detect use of the service identity from unusual workloads or locations.

DET-R06 — Ingestion Spike

Detect unusual increases in ingestion volume.

Step 46 — Required RAG Telemetry

Useful telemetry includes:

User Identity

Query ID

Document IDs Retrieved

Source Repository

Source Classification

Authorization Decision

RAG Service Identity

Ingestion Event

Document Version

Vector DB Administrative Action

Response / Request Correlation ID

Avoid logging sensitive content unnecessarily.

Step 47 — RAG Incident Response

Imagine:

Employees report that the AI assistant is giving malicious or incorrect security guidance.

Your investigation should be able to trace:

Suspicious Response
      ↓
User Query
      ↓
Retrieved Chunks
      ↓
Vector Entries
      ↓
Source Document
      ↓
Document Version
      ↓
Contributor
      ↓
Modification Event

If your logging cannot support this investigation, you have identified an operational security gap.

Step 48 — Poisoning Response Procedure

Recommended sequence:

Identify Suspicious Document
        ↓
Disable / Remove Source
        ↓
Prevent Further Ingestion
        ↓
Identify Affected Vector Records
        ↓
Rebuild Index
        ↓
Identify Previous Retrievals
        ↓
Assess User / Business Impact

Step 49 — Unauthorized Retrieval Response

If a user retrieves data outside authorization:

Disable / Restrict Session
      ↓
Identify Retrieved Documents
      ↓
Determine Data Classification
      ↓
Review Other Retrieval Activity
      ↓
Correct Authorization
      ↓
Revalidate Access

Escalate according to the organization’s incident process where sensitive information was exposed.

Step 50 — Vector Database Compromise Response

Possible actions:

Disable compromised service identity
Revoke credentials
Restrict network access
Preserve logs
Validate vector integrity
Rebuild index from trusted sources if needed
Investigate data access

Step 51 — Determine Residual Risk

Example:

Unauthorized Retrieval

Inherent Risk:

Critical

Controls:

Source ACL preservation
User-level authorization
Segmentation
Retrieval monitoring

Residual Risk:

Medium

Knowledge Poisoning

Inherent Risk:

High

Controls:

Restricted contributors
Approval workflow
Provenance
Change monitoring

Residual Risk:

Medium

Document your reasoning.

Step 52 — Create the Executive Summary

Create:

13 Executive Summary.md

Use:

# Executive Summary

## System

Enterprise Knowledge Copilot

## Assessment Focus

Enterprise RAG Architecture

## Overall Risk

High

## Critical Findings

1. Retrieval authorization must preserve source-document access controls.
2. Vector database access must be restricted using least privilege.
3. RAG knowledge sources require integrity and change governance.
4. Retrieved content must be treated as potentially untrusted AI context.
5. External AI and embedding services require data-governance validation.

## Priority Recommendations

1. Implement identity-aware document-level retrieval authorization.
2. Preserve source ACL and classification metadata during ingestion.
3. Restrict RAG service and vector database permissions.
4. Implement source provenance and ingestion auditing.
5. Monitor sensitive retrieval and source modifications.
6. Define RAG poisoning and vector compromise response procedures.

## Residual Risk

Medium after priority controls are implemented and validated.

Expected Deliverables

Your final lab should include:

Business context
Scope and assumptions
RAG architecture diagram
Knowledge source register
Asset register
Data flow register
Trust boundary register
Threat actor profiles
Attack surface register
STRIDE analysis
OWASP GenAI mapping
MITRE ATLAS considerations
Unauthorized retrieval scenario
Cross-tenant or cross-department scenario
Knowledge poisoning scenario
Indirect prompt injection scenario
Vector database compromise scenario
External embedding/provider scenario
At least 4 attack paths
RAG risk register
At least 10 RAG security requirements
Authorization validation cases
Detection requirements
Response procedures
Executive summary

Lab Success Criteria

You have successfully completed this lab when you can demonstrate:

Source Document
      ↓
Classification
      ↓
Authorization
      ↓
Ingestion
      ↓
Vector Metadata
      ↓
Retrieval
      ↓
User Authorization
      ↓
LLM Context
      ↓
Response

and explain what security control protects each stage.

You should also be able to trace a risk such as:

Asset
Restricted HR Data
      ↓
Threat
Unauthorized Retrieval
      ↓
Attack Path
Employee → RAG → HR Data
      ↓
Risk
Critical
      ↓
Control
Document-Level Authorization
      ↓
Requirement
RAG-SEC-001
      ↓
Validation
General Employee Must Be Denied

Security Engineer Challenge

The organization decides to enhance the application.

The new architecture becomes:

RAG
 ↓
LLM
 ↓
AI Agent
 ↓
Enterprise Tools

The AI agent can now:

Create tickets
Send email
Query customer systems

Revisit your RAG threat model.

Determine:

How does indirect prompt injection risk change?
Which RAG sources can influence agent actions?
Could a malicious document cause external data transfer?
Which new trust boundaries appear?
Which tool permissions become critical?
Which actions require approval?
Which new detection requirements are needed?
Does the risk rating of RAG poisoning change?

You should recognize that:

RAG Poisoning

may no longer cause only:

Incorrect Response

It may now cause:

Enterprise Action

That can dramatically change risk.

Real-World Takeaway

When reviewing an enterprise RAG system, do not ask only:

Is the vector database secure?

Ask:

Where Does the Knowledge Come From?

Who Can Modify It?

What Permissions Came With It?

Are Those Permissions Preserved?

Who Can Retrieve It?

Can Retrieved Content Be Malicious?

Where Is the Context Sent?

What Happens to the Generated Output?

Can We Reconstruct What Happened?

Those questions reveal the real enterprise security model.

Lab Review Questions

Question 1

Why should ingestion and retrieval be threat modeled separately?

Question 2

Why must source ACLs be preserved during RAG ingestion?

Question 3

How can metadata tampering cause information disclosure?

Question 4

Why should retrieved enterprise documents still be treated as potentially untrusted AI context?

Question 5

What is knowledge poisoning?

Question 6

Why can RAG poisoning be persistent?

Question 7

What makes indirect prompt injection different from direct prompt injection?

Question 8

Why can embeddings require confidentiality protection?

Question 9

Why should vector database access follow least privilege?

Question 10

Why must deleted source data also be removed from the RAG index?

Question 11

How can an external embedding provider introduce data risk?

Question 12

What logs are most useful during a RAG poisoning investigation?

Question 13

Why does adding an AI agent increase RAG-related risk?

Question 14

What is the most important control preventing unauthorized enterprise RAG retrieval?

Key Takeaways

Enterprise RAG security depends on maintaining trust and authorization throughout the complete knowledge lifecycle:

Source
  ↓
Ownership
  ↓
Classification
  ↓
Authorization
  ↓
Ingestion
  ↓
Embedding
  ↓
Vector Storage
  ↓
Retrieval
  ↓
LLM Context
  ↓
Response

The most important threats include:

Unauthorized Retrieval
        +
Knowledge Poisoning
        +
Indirect Prompt Injection
        +
Vector Database Compromise
        +
Metadata Tampering
        +
Sensitive Data Exposure

The central principle is:

RAG should not create a new path around the enterprise’s existing authorization model.

If a user cannot access a document through the original enterprise system, they should not gain access to it merely because the document was indexed by an AI application.

What’s Next?

➡️ Lab 03 — Threat Model an AI Agent

In the next lab, you will move from AI systems that retrieve information to AI systems that can take actions.

You will threat model an enterprise AI agent across:

Agent identity
Tool inventory
Agent permissions
User-context authorization
Tool parameters
External content
Agent memory
Human approval
Production access
Multi-agent delegation
Logging
Kill switches
Blast radius

The goal is to move from:

“I can secure how AI accesses enterprise knowledge.”

to:

“I can threat model how AI interacts with and changes real enterprise systems.”

➡️ Next: Lab 03 — Threat Model an AI Agent