14 Building an Enterprise AI Threat Model

You now have all the individual skills required to build a complete AI threat model.

You know how to:

• Understand the business use case
• Map architecture and data flows
• Identify assets
• Classify sensitive information
• Identify trust boundaries
• Identify threat actors
• Map attack surfaces
• Apply STRIDE
• Apply OWASP GenAI guidance
• Use MITRE ATLAS
• Threat model RAG
• Threat model AI agents
• Build attack paths
• Prioritize risk
• Map threats to security controls

The next step is to combine these activities into one repeatable enterprise process.

The objective of an enterprise AI threat model is to answer:

How can this AI system be attacked, what business impact could occur, what controls protect it, what gaps remain, and what should the organization do next?

A professional threat model should not be only a long list of AI risks.

It should connect:

Business Context
      ↓
Architecture
      ↓
Assets
      ↓
Data Flows
      ↓
Trust Boundaries
      ↓
Threat Actors
      ↓
Attack Surfaces
      ↓
Threat Scenarios
      ↓
Attack Paths
      ↓
Risk
      ↓
Security Controls
      ↓
Residual Risk

Learning Objectives

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

• Plan an enterprise AI threat modeling engagement.

• Define scope and assumptions.

• Understand business objectives and criticality.

• Build the architecture model.

• Create asset and data-flow registers.

• Identify trust boundaries.

• Build threat actor profiles.

• Create an attack surface register.

• Apply STRIDE systematically.

• Apply OWASP GenAI guidance.

• Map MITRE ATLAS adversary behaviors.

• Build AI abuse cases and attack paths.

• Prioritize risks.

• Map controls to threats.

• Define security requirements.

• Define detection and response requirements.

• Document residual risk.

• Build an executive summary.

• Produce a complete enterprise AI threat model package.

1. What Is an Enterprise AI Threat Model?

An enterprise AI threat model is a structured security analysis of an AI-enabled system.

It should explain:

What Are We Building?

What Are We Protecting?

Who Might Attack It?

Where Can They Interact?

How Could an Attack Progress?

What Would the Impact Be?

What Controls Exist?

What Controls Are Missing?

What Risk Remains?

The final result should support both:

• Engineering decisions

• Business risk decisions

2. Threat Modeling Is a Process, Not a Diagram

An architecture diagram is important.

But a diagram by itself is not a threat model.

Likewise:

OWASP Checklist

is not a threat model.

MITRE Mapping

is not a threat model.

Risk Register

is not a threat model.

A complete threat model combines all of them into one connected analysis.

3. Enterprise Threat Modeling Workflow

Use the following sequence:

Define Scope
      ↓
Understand Business Context
      ↓
Understand Architecture
      ↓
Map Data Flows
      ↓
Identify Assets
      ↓
Classify Data
      ↓
Identify Trust Boundaries
      ↓
Identify Threat Actors
      ↓
Map Attack Surfaces
      ↓
Apply STRIDE
      ↓
Apply OWASP GenAI
      ↓
Map MITRE ATLAS
      ↓
Build Abuse Cases
      ↓
Build Attack Paths
      ↓
Assess Risk
      ↓
Map Security Controls
      ↓
Define Requirements
      ↓
Review Residual Risk
      ↓
Produce Final Threat Model

This gives you a repeatable methodology.

4. Phase 1 — Define Scope

Before analyzing threats, define what is included.

Example:

## Scope

The assessment covers the Enterprise AI Knowledge Assistant including:

- Web application
- AI orchestration service
- External LLM provider
- RAG pipeline
- Vector database
- Enterprise document sources
- AI support agent
- Supporting cloud infrastructure

Also define what is not included.

Example:

## Out of Scope

- Corporate identity provider implementation
- Endpoint security controls
- Physical security

Clear scope prevents confusion later.

5. Define Business Objective

Document why the system exists.

Example:

The organization is building an internal AI assistant that allows employees to retrieve approved enterprise knowledge and create IT support tickets.

This immediately reveals important areas:

• Internal identity

• RAG

• Enterprise data

• AI agent

• Ticketing tool

6. Identify Business Owner

Every system should have an owner.

Record:

• Business owner

• Technical owner

• AI owner

• Security contact

• Data owner

Example:

Role	Owner
Business Owner	Employee Experience
AI Platform Owner	AI Engineering
Cloud Owner	Platform Engineering
Security Owner	AI Security
Data Owner	Enterprise Knowledge Team

7. Determine Business Criticality

Classify the system.

Example:

• Low

• Medium

• High

• Mission Critical

Ask:

What happens if the AI system is unavailable?

What happens if it provides incorrect information?

What happens if it exposes confidential information?

What happens if an agent performs the wrong action?

8. Document Assumptions

Threat models frequently rely on assumptions.

Example:

## Assumptions

- Employees authenticate using enterprise SSO.
- MFA is enabled.
- The vector database is private.
- The AI agent uses a dedicated workload identity.
- Only approved repositories are indexed.

These assumptions should later be validated.

9. Document Unknowns

Also record missing information.

Example:

## Unknowns

- Whether external LLM prompts are retained.
- Whether RAG retrieval preserves document ACLs.
- Whether tool calls are centrally logged.

Unknowns become investigation items.

10. Phase 2 — Build the Architecture

Start with a high-level architecture.

Example:

                         Employee
                            │
                            ▼
                     Web Application
                            │
                            ▼
                     AI Orchestrator
                            │
            ┌───────────────┼───────────────┐
            │               │               │
            ▼               ▼               ▼
           LLM             RAG            AI Agent
                            │               │
                            ▼               ▼
                     Vector Database       Tools
                            │               │
                            ▼               ▼
                   Enterprise Documents Enterprise Systems

The diagram should be simple enough to understand but detailed enough to support threat analysis.

11. Add Security Context

Add:

• Identities

• Protocols

• Trust boundaries

• Data sensitivity

• External services

Example:

Employee
  │
  │ SSO + MFA
  ▼
========================
TB-01
========================
Web Application
  │
  ▼
AI Orchestrator
  │
  ├──────────────► External LLM
  │                    │
  │              TB-02 External Boundary
  │
  ├──────────────► RAG
  │                    │
  │                    ▼
  │               Vector Database
  │
  └──────────────► AI Agent
                       │
                       ▼
                 Privileged Tool

12. Phase 3 — Create the Component Inventory

Create a table:

ID	Component	Purpose	Owner	Identity	Exposure
C-01	Web Application	User interface	App Team	User Session	Internal
C-02	AI Orchestrator	Coordinates AI flow	AI Team	Workload ID	Private
C-03	LLM	Model inference	Provider	API Identity	External
C-04	RAG Service	Knowledge retrieval	AI Team	Service ID	Private
C-05	Vector DB	Knowledge storage	Data Team	Service ID	Private
C-06	AI Agent	Tool execution	AI Team	Agent ID	Private

This ensures important components are not forgotten.

13. Phase 4 — Map Data Flows

Document how information moves.

Example:

DF-01
Employee → Web Application

DF-02
Web Application → AI Orchestrator

DF-03
AI Orchestrator → External LLM

DF-04
AI Orchestrator → RAG

DF-05
RAG → Vector Database

DF-06
AI Agent → Ticketing API

14. Build a Data Flow Register

Use:

ID	Source	Destination	Data	Identity	Sensitivity
DF-01	Employee	Web App	Prompt	Employee	Internal
DF-02	App	LLM	Prompt + Context	App ID	Confidential
DF-03	RAG	Vector DB	Search Query	RAG ID	Confidential
DF-04	Agent	Tool API	Action Request	Agent ID	Restricted

15. Phase 5 — Identify Assets

Create an asset inventory.

Examples:

Employee Identity
Enterprise Documents
Customer Information
System Prompt
LLM API Credential
Vector Database
Agent Identity
Tool Credentials
AI Logs
Production Resources

16. Build an AI Asset Register

Use:

ID	Asset	Category	Owner	Classification	Criticality
A-01	Enterprise Documents	Data	Knowledge Team	Confidential	High
A-02	Agent Identity	Identity	AI Team	Restricted	Critical
A-03	Vector DB	Data Store	AI Team	Confidential	High
A-04	AI Logs	Security	SOC	Confidential	High
A-05	LLM API Key	Credential	AI Team	Restricted	High

17. Identify Crown Jewels

Some assets deserve special attention.

Examples:

• Production administrator identity

• Customer data

• Confidential HR data

• Proprietary model weights

• Critical business workflows

Create:

## Crown Jewel Assets

- CJ-01 Production Cloud Environment
- CJ-02 Restricted Customer Data
- CJ-03 AI Agent Administrative Identity

Attack paths leading to these assets should receive high priority.

18. Phase 6 — Classify Data

Identify where sensitive data exists.

Example:

Data	Classification
Public Documentation	Public
General Internal Docs	Internal
Security Architecture	Confidential
Customer Data	Confidential
API Credentials	Restricted

Then follow that classification through the entire AI workflow.

19. Phase 7 — Identify Trust Boundaries

Typical AI boundaries include:

User → Application

Application → External LLM

RAG → Vector Database

Document Source → RAG

Agent → Enterprise Tool

AI → Production System

Create a Trust Boundary Register.

20. Trust Boundary Register

Use:

ID	Source	Destination	Trust Change	Primary Concern
TB-01	User	App	User → Enterprise	Malicious input
TB-02	App	External LLM	Enterprise → Third Party	Data exposure
TB-03	RAG	Vector DB	Service → Sensitive Data	Authorization
TB-04	Agent	Production API	AI → Privileged System	Unauthorized action

21. Phase 8 — Identify Threat Actors

Document realistic adversaries.

Examples:

External Attacker
Compromised Employee
Malicious Insider
Compromised Administrator
Malicious Document Contributor
Supply-Chain Attacker
Compromised Workload

22. Threat Actor Profile

Use:

## TA-01 — Compromised Employee

### Access

Valid enterprise account.

### Motivation

Depends on controlling attacker.

### Reachable Systems

- Internal AI assistant
- Approved RAG sources

### Target Assets

- Enterprise knowledge
- Agent tools
- Sensitive business data

23. Phase 9 — Map Attack Surfaces

Identify every important interaction point.

Examples:

• Chat interface

• API

• File upload

• Document ingestion

• Vector search

• Agent interface

• Tool interface

• Model registry

• CI/CD

• Cloud APIs

24. Attack Surface Register

Use:

ID	Component	Surface	Exposure	Target Asset	Priority
AS-01	Web App	Chat Input	Internal	AI Service	Medium
AS-02	RAG	Retrieval	Internal	Enterprise Data	High
AS-03	Agent	Tool Interface	Internal	Production	Critical
AS-04	Model Registry	Upload	Privileged	Model	High

25. Direct vs Indirect Surfaces

Remember to include both.

Direct

User
 ↓
Chat Interface

Indirect

Attacker
 ↓
Document
 ↓
RAG
 ↓
LLM

Indirect attack surfaces are especially important in AI systems.

26. Phase 10 — Apply STRIDE

Apply STRIDE to important:

• Components

• Data flows

• Trust boundaries

Use:

S — Spoofing
T — Tampering
R — Repudiation
I — Information Disclosure
D — Denial of Service
E — Elevation of Privilege

27. STRIDE Example — RAG Retrieval

Component:

RAG Retrieval

Threats:

Spoofing

Impersonate legitimate user or service.

Tampering

Modify retrieval metadata.

Repudiation

Missing retrieval attribution.

Information Disclosure

Retrieve unauthorized documents.

Denial of Service

Exhaust retrieval resources.

Elevation of Privilege

Access higher-classification data.

28. STRIDE Example — AI Agent

Spoofing

Agent identity theft.

Tampering

Tool parameters modified.

Repudiation

No audit trail.

Information Disclosure

Agent exposes sensitive tool results.

Denial of Service

Agent loops.

Elevation of Privilege

Low-privileged user influences privileged agent.

29. Phase 11 — Apply OWASP GenAI Guidance

Now identify AI-specific risk patterns.

Consider areas such as:

• Prompt injection

• Sensitive information disclosure

• Data/model poisoning

• Improper output handling

• Excessive agency

• Supply-chain risks

• Vector/embedding risks

• Resource consumption

Use current official OWASP guidance during real assessments.

30. OWASP Mapping Example

Threat:

Malicious RAG content influences an AI agent.

Possible AI-specific concerns include:

Indirect Prompt Injection
+
Data Poisoning
+
Excessive Agency

The exact current mapping should be validated against official OWASP guidance.

31. Phase 12 — Map MITRE ATLAS

Now shift to adversary behavior.

Ask:

What Does the Attacker Want?

How Would They Discover the System?

How Would They Gain Access?

What AI Component Would They Manipulate?

What Would They Do Next?

Map current relevant MITRE ATLAS tactics and techniques.

32. Framework Mapping Principle

Do not force frameworks into the analysis.

Start with:

Threat Scenario

then map:

STRIDE
OWASP
MITRE ATLAS

where useful.

33. Phase 13 — Build Threat Scenarios

A professional threat scenario should describe:

Threat Actor
      ↓
Entry Point
      ↓
Attack Surface
      ↓
Weakness
      ↓
Target Asset
      ↓
Impact

Example:

A compromised employee may use the AI assistant to retrieve HR documents outside their authorized department because RAG retrieval does not enforce source-system permissions.

34. Threat Scenario Register

Use:

ID	Threat Actor	Scenario	Asset	Impact	Risk
T-01	Compromised User	Unauthorized RAG retrieval	HR Data	Disclosure	Critical
T-02	Malicious Contributor	RAG poisoning	Knowledge	Integrity	High
T-03	Compromised User	Privileged agent abuse	Production	Modification	Critical

35. Phase 14 — Build Abuse Cases

Convert important threats into realistic misuse scenarios.

Example:

## AC-01 — Unauthorized RAG Data Retrieval

A compromised employee uses the internal AI assistant to search for confidential HR information outside the employee's authorized department.

36. Phase 15 — Build Attack Paths

Now show how the attack progresses.

Example:

Compromised Employee
       ↓
AI Assistant
       ↓
RAG Query
       ↓
Missing Document Authorization
       ↓
Restricted HR Document
       ↓
LLM Response

37. Agent Attack Path

Example:

Compromised Employee
       ↓
AI Agent
       ↓
Manipulated Request
       ↓
Privileged Tool
       ↓
Cloud API
       ↓
Production Modification

38. RAG-to-Agent Attack Path

Example:

Malicious Contributor
       ↓
Poisoned Document
       ↓
RAG
       ↓
LLM Context
       ↓
AI Agent
       ↓
Enterprise Tool
       ↓
Unauthorized Action

This may become one of the most important attack paths in an agentic RAG architecture.

39. Supply-Chain Attack Path

Example:

Supply-Chain Attacker
       ↓
Compromised Dependency
       ↓
AI Build Pipeline
       ↓
Production Deployment
       ↓
Credential Theft
       ↓
Enterprise Data

40. Phase 16 — Identify Control Breakpoints

For each attack path, determine where it can be interrupted.

Example:

Compromised User
      ↓
[MFA]
      ↓
AI Agent
      ↓
[User Authorization]
      ↓
Tool
      ↓
[Least Privilege]
      ↓
Production
      ↓
[Monitoring]

41. Phase 17 — Assess Risk

Evaluate:

• Likelihood

• Impact

• Exposure

• Attack complexity

• Asset criticality

• Privilege

• Blast radius

• Existing controls

• Detectability

Then assign:

• Inherent risk

• Residual risk

42. Risk Register

Use:

ID	Threat	Likelihood	Impact	Inherent Risk	Controls	Residual Risk
R-01	Unauthorized RAG Retrieval	High	High	Critical	Retrieval Authz	Medium
R-02	Agent Privilege Abuse	Medium	Critical	Critical	Least Privilege + Approval	High
R-03	RAG Poisoning	Medium	High	High	Source Governance	Medium

43. Phase 18 — Map Security Controls

Map each threat to:

Prevent
Detect
Respond

Example:

Threat	Prevent	Detect	Respond
RAG Disclosure	Authorization	Retrieval monitoring	Disable account
Agent Abuse	Least privilege	Tool alerts	Disable agent
RAG Poisoning	Source governance	Change monitoring	Reindex
Model Tampering	Integrity validation	Registry alerts	Rollback

44. Threat-to-Control Matrix

Create:

AI Threat-to-Control Matrix.md

Use:

Threat ID	Preventive Controls	Detective Controls	Responsive Controls	Requirement
T-01	Document Authorization	Retrieval Alert	Disable Session	RAG-SEC-001
T-02	Source Governance	Change Monitoring	Reindex	RAG-SEC-002
T-03	Least Privilege	Tool Monitoring	Disable Agent	AGENT-SEC-001

45. Phase 19 — Define Security Requirements

Convert control recommendations into testable requirements.

Example:

RAG-SEC-001

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

Another:

AGENT-SEC-001

The production AI agent must use a dedicated
least-privilege workload identity.

46. Requirement Register

Use:

ID	Requirement	Threat	Owner	Validation
RAG-SEC-001	Document-level authz	T-01	AI Team	Access test
AGENT-SEC-001	Least-privilege identity	T-03	Platform	IAM review
LOG-SEC-001	Agent tool-call logging	T-03	SOC	Log test

47. Phase 20 — Define Detection Requirements

Threat modeling should generate detection use cases.

Examples:

Detect unusual RAG retrieval volume.

Detect privileged agent actions initiated by low-privileged users.

Detect unauthorized changes to production RAG sources.

Detect model registry modifications.

48. Detection Register

Use:

ID	Threat	Required Telemetry	Detection
DET-01	RAG Collection	Retrieval Logs	High-volume sensitive access
DET-02	Agent Abuse	Tool Logs	Unexpected privileged tool use
DET-03	RAG Poisoning	Source Logs	Sensitive source change
DET-04	Model Tampering	Registry Logs	Unauthorized model update

49. Phase 21 — Define Response Requirements

For critical threats, define containment.

Example:

Agent Compromise

Disable Agent Identity
Revoke Tokens
Block Tools

RAG Poisoning

Remove Document
Rebuild Index
Review Affected Sessions

Model Compromise

Stop Model
Rollback
Investigate Registry

50. Phase 22 — Review Residual Risk

After planned controls, ask:

What risk remains?

Example:

Inherent Risk:
Critical

Controls:
Least Privilege
Authorization
Approval
Logging

Residual Risk:
Medium

If residual risk remains unacceptable, additional action may be required.

51. Phase 23 — Record Risk Decisions

Possible decisions:

• Mitigate

• Avoid

• Transfer

• Accept

Risk acceptance should be performed by the appropriate risk owner.

The security engineer should clearly communicate:

• Risk

• Evidence

• Recommendation

• Residual risk

52. Phase 24 — Build Executive Summary

Executives do not need every technical detail.

They need:

What System Was Reviewed?

What Are the Most Important Risks?

What Could the Business Impact Be?

What Must Be Fixed First?

What Residual Risk Remains?

53. Executive Summary Template

Use:

# Executive Summary

## System

## Business Purpose

## Assessment Scope

## Overall Risk

## Critical Risks

## High Risks

## Positive Security Controls

## Priority Recommendations

## Residual Risk

## Security Recommendation

54. Example Executive Summary

## Overall Assessment

The AI assistant introduces moderate-to-high security risk due to its access to confidential enterprise information and its integration with an AI agent capable of executing IT support actions.

The highest-priority risks are:

1. RAG retrieval does not consistently enforce source-document authorization.
2. The AI agent currently has broader permissions than required.
3. Agent tool activity is not fully correlated with the initiating user.

Priority remediation should focus on retrieval authorization, agent least privilege, tool-action authorization and centralized AI audit logging.

This is more useful to leadership than a list of 50 AI attack terms.

55. Positive Controls

Always document what is working well.

Examples:

• Enterprise SSO

• MFA

• Private vector database

• Dedicated workload identities

• Central secret storage

• Source-controlled configuration

Threat models should provide a balanced security picture.

56. Enterprise AI Threat Model Package

A professional assessment may use:

Enterprise-AI-Threat-Model/
│
├── 01-Scope.md
├── 02-Business-Context.md
├── 03-Architecture.md
├── 04-Component-Inventory.md
├── 05-Asset-Register.md
├── 06-Data-Flows.md
├── 07-Data-Classification.md
├── 08-Trust-Boundaries.md
├── 09-Threat-Actors.md
├── 10-Attack-Surface.md
├── 11-STRIDE-Analysis.md
├── 12-OWASP-Mapping.md
├── 13-MITRE-ATLAS-Mapping.md
├── 14-Threat-Scenarios.md
├── 15-Abuse-Cases.md
├── 16-Attack-Paths.md
├── 17-Risk-Register.md
├── 18-Threat-to-Control-Matrix.md
├── 19-Security-Requirements.md
├── 20-Detection-Requirements.md
├── 21-Residual-Risk.md
└── 22-Executive-Summary.md

You do not always need all 22 files.

For smaller projects, combine related sections.

57. Practical Minimal Threat Model

A smaller project could use:

AI-Threat-Model/
│
├── 01-Overview.md
├── 02-Architecture.md
├── 03-Assets-and-Data-Flows.md
├── 04-Threats-and-Attack-Paths.md
├── 05-Risk-Register.md
├── 06-Security-Controls.md
└── 07-Executive-Summary.md

The methodology matters more than the number of documents.

58. Threat Model Review Meeting

An enterprise threat model should ideally be reviewed collaboratively.

Participants may include:

• AI Engineering

• Application Security

• Cloud Security

• Security Architecture

• Platform Engineering

• Data Owners

• SOC

• Risk

• Business Owner

The goal is to validate:

Architecture
Assumptions
Threats
Risk Ratings
Controls
Ownership

59. Validate the Architecture First

Before discussing threats, ask:

Is this diagram actually correct?

A threat model built on an inaccurate architecture will produce inaccurate conclusions.

Ensure engineering teams confirm:

• Components

• Integrations

• Identities

• Data flows

• Permissions

60. Validate Threat Scenarios

For each significant scenario ask:

Is This Technically Possible?

Are the Preconditions Realistic?

Does the Attacker Have This Access?

Would Existing Controls Stop It?

Is the Business Impact Accurate?

Remove unrealistic scenarios.

Threat models should be focused, not inflated.

61. Validate Security Controls

Do not assume controls exist because documentation says they exist.

Example:

Documentation:

Agent has read-only access.

Validation:

Review the actual IAM policy.

Another:

RAG preserves source access controls.

Validation:

Test with users from different authorization groups.

62. Create Validation Tasks

Example:

Validation ID	Assumption	Method	Owner
V-01	RAG enforces HR ACL	Access Test	AI Team
V-02	Agent is read-only	IAM Review	Platform
V-03	Provider does not retain prompts	Contract Review	Governance
V-04	Agent tool calls logged	SIEM Review	SOC

63. Evidence

Important threat-model decisions should be supported by evidence.

Possible evidence:

• Architecture diagrams

• IAM configurations

• Access test results

• Logging screenshots

• Model configuration

• Data classification

• Provider documentation

• Source repository configuration

64. Evidence Register

Use:

ID	Evidence	Supports
EV-01	Agent IAM Policy	AG-T01
EV-02	RAG ACL Test	RAG-T01
EV-03	Model Registry Permissions	MODEL-T01
EV-04	Tool Logs	DET-02

65. Threat Model Versioning

AI systems change quickly.

Maintain:

Threat Model Version
Architecture Version
Review Date
Reviewer
Status

Example:

Threat Model Version: 1.2
Architecture Version: 3.4
Last Review: YYYY-MM-DD

66. When to Revisit the Threat Model

Review when:

• New LLM is introduced

• New RAG source is connected

• Sensitive data changes

• Agent gets a new tool

• Agent privileges change

• New external provider is added

• Cloud architecture changes

• Security incident occurs

• New threat intelligence becomes relevant

67. Example — Version 1

AI Assistant
      ↓
Public Knowledge

Risk may be low.

68. Example — Version 2

AI Assistant
      ↓
Confidential RAG

New threats appear.

69. Example — Version 3

AI Assistant
      ↓
RAG
      ↓
AI Agent
      ↓
Production

The risk profile changes dramatically.

Threat models must evolve with capability.

70. Threat Model Quality Criteria

A good threat model should be:

Accurate

Reflect the real architecture.

Focused

Prioritize meaningful threats.

Traceable

Connect threats to assets and controls.

Testable

Generate security requirements and tests.

Operational

Include detection and response.

Business-Aware

Explain impact.

Maintainable

Easy to update.

71. Signs of a Weak Threat Model

Examples:

Large OWASP checklist with no architecture context

Hundreds of generic threats

No business impact

No attack paths

No control mapping

No owners

No validation

These create documents but not necessarily better security.

72. Threat Model Traceability

Ideally, you should be able to trace:

Asset
 ↓
Threat
 ↓
Attack Path
 ↓
Risk
 ↓
Control
 ↓
Requirement
 ↓
Validation

Example:

Asset:
HR Data

Threat:
Unauthorized Retrieval

Risk:
Critical

Control:
Document Authorization

Requirement:
RAG-SEC-001

Validation:
Non-HR access test

This is a mature engineering approach.

73. Security Requirement Traceability Matrix

Create:

AI Security Traceability Matrix.md

Use:

Asset	Threat	Risk	Control	Requirement	Validation
HR Data	RAG-T01	Critical	Retrieval Authz	RAG-SEC-001	ACL Test
Production Cloud	AG-T01	Critical	Least Privilege	AGENT-SEC-001	IAM Review
Model	MODEL-T01	High	Integrity Validation	MODEL-SEC-001	Registry Test

74. Enterprise Threat Model Review Checklist

Scope

• Scope defined

• Out-of-scope defined

• Owners identified

Architecture

• Architecture validated

• Components inventoried

• External services identified

Data

• Data flows mapped

• Data classified

• Sensitive data identified

Assets

• Assets inventoried

• Crown jewels identified

• Owners assigned

Trust

• Trust boundaries identified

• Privilege boundaries identified

• Third-party boundaries identified

Threat Actors

• External attackers considered

• Compromised users considered

• Insiders considered

• Supply-chain attackers considered

• Indirect content attackers considered

Attack Surface

• User interface reviewed

• APIs reviewed

• RAG reviewed

• Agents reviewed

• Supply chain reviewed

• Cloud infrastructure reviewed

Framework Analysis

• STRIDE applied

• OWASP GenAI considered

• MITRE ATLAS considered

Threat Scenarios

• Threat scenarios documented

• Abuse cases documented

• Attack paths created

• Preconditions documented

Risk

• Likelihood evaluated

• Impact evaluated

• Inherent risk assigned

• Residual risk assessed

Controls

• Preventive controls mapped

• Detective controls mapped

• Response controls mapped

• Control owners assigned

Requirements

• Security requirements defined

• Detection requirements defined

• Validation criteria defined

Reporting

• Executive summary completed

• Critical risks highlighted

• Remediation priorities defined

• Risk decisions documented

75. Real-World Example — Enterprise AI Assistant

Consider:

Employee
   ↓
AI Assistant
   ↓
RAG
   ↓
Enterprise Knowledge
   ↓
AI Agent
   ↓
Ticketing System

Potential major threats:

T-01

Unauthorized RAG retrieval.

T-02

Knowledge poisoning.

T-03

Indirect prompt injection.

T-04

Agent tool abuse.

T-05

Agent identity compromise.

T-06

Sensitive information disclosure.

Now rank them according to actual:

• Access

• data sensitivity

• permissions

• business impact

76. Example Priority Risks

Suppose:

Risk 1

RAG exposes HR documents.

Critical

Risk 2

AI agent can create IT tickets without strong user authorization.

Medium

Risk 3

System prompt can be disclosed.

Low

This demonstrates why threat models should focus on business impact rather than hype.

77. Example Priority Remediation

A reasonable remediation plan could be:

Priority 1
Implement document-level RAG authorization.

Priority 2
Reduce agent permissions.

Priority 3
Correlate agent actions with initiating users.

Priority 4
Improve source governance.

Priority 5
Improve AI-specific monitoring.

This becomes an actionable security roadmap.

78. Threat Model to Security Architecture

Threat models should influence design.

Example threat:

Low-Privilege User
      ↓
Privileged Agent

Architecture change:

Low-Privilege User
      ↓
Read-Only Agent

and:

Administrator
      ↓
Privileged Agent
      ↓
Approval

A good threat model can therefore simplify and improve architecture.

79. Threat Model to Security Testing

Threat:

User may retrieve unauthorized HR content.

Test:

Attempt retrieval using a non-HR account.

Threat:

Agent may perform privileged write operations.

Test:

Verify write API calls fail for read-only agent identity.

The threat model becomes the basis for later security validation.

80. Threat Model to AI Red Teaming

Attack paths can become authorized red-team scenarios.

Example:

Threat Path:
RAG → Agent → Production Tool

Red-team test objective:

Validate whether controlled untrusted content can influence the agent into requesting a restricted operation and confirm policy enforcement prevents execution.

This creates targeted and meaningful testing.

81. Threat Model to SOC Monitoring

Threat:

Compromised employee uses AI assistant to collect confidential information.

SOC requirement:

Monitor unusually high retrieval volume and access across sensitive knowledge domains.

The threat model now informs security operations.

82. Threat Model to Incident Response

Threat:

Poisoned RAG content influences production agent activity.

Incident response needs to know how to:

• Identify source content

• Find ingestion events

• Identify retrieval events

• Correlate agent activity

• Disable agent

• Remove content

• Rebuild index

Threat modeling can identify these needs before an incident occurs.

83. AI Threat Modeling as Continuous Security

The final lifecycle is:

Design
  ↓
Threat Model
  ↓
Implement Controls
  ↓
Validate
  ↓
Deploy
  ↓
Monitor
  ↓
Threat Intelligence
  ↓
Architecture Changes
  ↓
Update Threat Model

Threat modeling should become part of the AI lifecycle, not a one-time document.

84. Enterprise AI Threat Modeling Mindset

When approaching a new AI system, think:

What Is the Business Goal?
        ↓
What Is the Architecture?
        ↓
What Are the Crown Jewels?
        ↓
Where Does Data Flow?
        ↓
Where Does Trust Change?
        ↓
Who Could Attack?
        ↓
Where Can They Enter?
        ↓
What AI-Specific Risks Exist?
        ↓
How Would an Adversary Progress?
        ↓
What Is the Attack Path?
        ↓
What Is the Business Impact?
        ↓
What Controls Break the Path?
        ↓
How Do We Detect Failure?
        ↓
How Do We Respond?
        ↓
What Risk Remains?

That is the core AI threat-modeling workflow.

85. Knowledge Check

Question 1

What is the purpose of an enterprise AI threat model?

Question 2

Why should scope be defined before threat analysis begins?

Question 3

Why should architecture be validated with engineering teams?

Question 4

Why are data flows important?

Question 5

What is the purpose of an asset register?

Question 6

Why should crown jewels receive additional attention?

Question 7

Why should direct and indirect attack surfaces both be considered?

Question 8

How do STRIDE, OWASP GenAI and MITRE ATLAS complement one another?

Question 9

What is the difference between a threat scenario and an attack path?

Question 10

Why should control breakpoints be identified?

Question 11

Why should security requirements be testable?

Question 12

Why should detection and response requirements be included?

Question 13

What is residual risk?

Question 14

Why should the threat model be updated when AI capabilities change?

Key Takeaways

A complete enterprise AI threat model connects:

Business
   ↓
Architecture
   ↓
Assets
   ↓
Data
   ↓
Trust
   ↓
Threat Actors
   ↓
Attack Surfaces
   ↓
Threat Scenarios
   ↓
Attack Paths
   ↓
Risk
   ↓
Security Controls
   ↓
Requirements
   ↓
Validation
   ↓
Residual Risk

The most important lesson is:

A threat model should not simply tell the organization what could go wrong. It should explain why it matters, how it could happen, what should stop it, how it would be detected and what risk remains.

That is what transforms threat modeling from documentation into security engineering.

What’s Next?

➡️ 15 — AI Threat Model Documentation

You now know how to build the complete threat model.

The final lesson in this section focuses on how to document, maintain, review and communicate that threat model professionally.

You will learn how to structure:

• Threat model overview

• Scope and assumptions

• Architecture diagrams

• Asset registers

• Trust-boundary registers

• Threat scenarios

• Attack-path diagrams

• Risk registers

• Threat-to-control matrices

• Security requirements

• Evidence

• Review history

• Executive summaries

You will also learn how to keep threat models:

• Version controlled

• Reviewable

• Traceable

• Auditable

• Easy to update as AI architecture evolves

The goal is to move from:

“I can perform an enterprise AI threat model.”

to:

“I can produce a professional threat modeling deliverable that engineering, security, risk and leadership teams can actually use.”

➡️ Next: 15 — AI Threat Model Documentation