Lab 03 Map AI Threats Using OWASP and MITRE ATLAS

Mission Information

Item	Details
Mission	Map AI Threats Using OWASP and MITRE ATLAS
Role	Junior AI Security Engineer
Difficulty	Beginner → Intermediate
Estimated Time	60–90 minutes
Primary Skills	AI Threat Identification, OWASP Mapping, MITRE ATLAS Mapping, Risk Analysis
Environment	Documentation / Threat Modeling Lab
Output	AI Threat Register + Threat Mapping + Security Recommendations

Mission Scenario

You have recently joined the AI Security Engineering team of a fictional enterprise.

The organization is preparing to deploy an internal AI assistant called:

Enterprise Knowledge Assistant

Employees will use the assistant to search internal documentation, summarize information and answer business questions.

The application uses:

A web interface
Enterprise authentication
Application APIs
A Large Language Model
Retrieval-Augmented Generation
A vector database
Internal documents
Cloud storage
Logging and monitoring

The architecture team has asked the AI Security team to perform an initial threat assessment before production deployment.

Your task is to:

Understand the architecture.
Identify important assets.
Identify possible AI attack scenarios.
Map relevant risks to OWASP guidance.
Map adversary behaviors to MITRE ATLAS.
Identify existing and missing controls.
Prioritize the threats.
Produce an AI Threat Register.

You are not attacking a real system.

This is a threat modeling and security analysis exercise.

Mission Objective

By completing this lab, you should understand the difference between:

A vulnerability category

and

An adversary technique or behavior.

OWASP guidance helps us understand important application security risk categories and defensive considerations.

MITRE ATLAS helps us understand how adversaries may target AI-enabled systems through tactics and techniques.

Together they provide different perspectives on the same environment.

Learning Objectives

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

Analyze an enterprise AI architecture.
Identify important AI assets.
Identify trust boundaries.
Develop realistic AI attack scenarios.
Use OWASP AI/LLM security guidance during an assessment.
Use MITRE ATLAS to analyze adversary behavior.
Understand the difference between OWASP and MITRE ATLAS.
Map threats across multiple frameworks.
Identify preventive and detective controls.
Prioritize AI security risks.
Create an enterprise-style AI Threat Register.
Communicate AI security findings clearly.

Prerequisites

Before beginning, you should have completed:

01 Introduction to AI Security
02 How AI and Machine Learning Systems Work
03 Generative AI and LLM Architecture
04 Enterprise AI Architecture
05 AI Security Attack Surface
06 AI Security Threat Landscape
07 OWASP Top 10 for LLM Applications
08 MITRE ATLAS

You should also have completed:

Lab 01 — Explore an Enterprise AI Architecture
Lab 02 — Identify AI Attack Surfaces

This lab combines those skills.

Framework Note

AI security frameworks evolve quickly.

For this lab, use the current official OWASP guidance relevant to LLM/Generative AI applications and the current MITRE ATLAS knowledge base when performing your mapping.

Do not treat framework identifiers as permanent.

The important skill is learning how to:

Identify the threat → locate the relevant framework entry → justify the mapping → recommend controls.

Understanding the Two Frameworks

Before starting, understand what each framework contributes.

OWASP

OWASP guidance helps security teams understand common security risks affecting AI and LLM-enabled applications.

It is useful for questions such as:

What application security weakness exists?

What design problem makes the attack possible?

What controls should developers consider?

Examples of areas you may encounter include:

Prompt injection
Sensitive information disclosure
Supply-chain risk
Data or model poisoning
Improper output handling
Excessive agency
System prompt leakage
Vector and embedding weaknesses
Misinformation
Resource or consumption risks

Use the terminology from the current OWASP guidance available when you perform the lab.

MITRE ATLAS

MITRE ATLAS focuses more heavily on adversarial behavior against AI-enabled systems.

It helps answer:

What is the attacker trying to achieve?

What technique could they use?

Where does this behavior fit in an attack lifecycle?

ATLAS can therefore help security teams understand potential adversary activity and connect AI security with:

Threat intelligence
Detection engineering
Red teaming
Threat hunting
Incident response

OWASP vs MITRE ATLAS

A simple way to remember the distinction is:

OWASP
   ↓
"What security risks should we design and test for?"

MITRE ATLAS
   ↓
"How might an adversary operate against this AI system?"

Neither replaces the other.

Together they can provide a stronger view.

Enterprise Architecture

The system being assessed looks like this:

                        Employees
                            │
                            ▼
                    ┌───────────────┐
                    │ Web Interface │
                    └───────┬───────┘
                            │
                            ▼
                    ┌───────────────┐
                    │ Application   │
                    │ API           │
                    └───────┬───────┘
                            │
                            ▼
                    ┌───────────────┐
                    │ AI / LLM      │
                    │ Application   │
                    └───────┬───────┘
                            │
             ┌──────────────┼──────────────┐
             │              │              │
             ▼              ▼              ▼
        ┌─────────┐   ┌───────────┐   ┌───────────┐
        │   LLM   │   │    RAG    │   │ Logging & │
        │ Service │   │ Pipeline  │   │ Monitoring│
        └─────────┘   └─────┬─────┘   └───────────┘
                            │
                            ▼
                    ┌───────────────┐
                    │ Vector        │
                    │ Database      │
                    └───────┬───────┘
                            │
                            ▼
                    ┌───────────────┐
                    │ Enterprise    │
                    │ Documents     │
                    └───────────────┘

The application processes internal company information.

Some documents may contain:

HR information
Security procedures
Engineering documentation
Internal policies
Customer information
Operational documentation

This means both the AI system and the underlying enterprise data require protection.

Step 1 — Identify the Assets

Begin by identifying what the organization needs to protect.

Create an asset inventory.

Example:

Asset	Why It Matters
LLM Application	Provides the AI capability
Enterprise Documents	May contain sensitive information
Vector Database	Contains embeddings and indexed knowledge
Application API	Provides access to backend functionality
User Identity	Determines who can access the application
Service Credentials	Allow components to communicate
System Instructions	Influence application behavior
Logs	Provide security and investigation evidence
Cloud Infrastructure	Hosts supporting components

Add additional assets you identify.

Step 2 — Classify the Assets

Not every asset has the same sensitivity.

Create a simple classification.

Example:

Asset	Classification
Public documentation	Public
Internal procedures	Internal
Architecture documentation	Confidential
Customer records	Confidential
Credentials	Restricted
API keys	Restricted

Ask:

What would happen if this asset were disclosed?

What would happen if it were modified?

What would happen if it became unavailable?

This introduces the traditional security principles of:

Confidentiality + Integrity + Availability

into AI threat analysis.

Step 3 — Identify Trust Boundaries

Look at the architecture again.

Identify locations where data moves between different security contexts.

Potential trust boundaries include:

Employee
    │
    ▼
Web Application

Application
    │
    ▼
LLM Service

RAG Pipeline
    │
    ▼
Enterprise Documents

Application
    │
    ▼
External AI Provider

Each trust boundary deserves security attention.

Ask:

Is the caller authenticated?
Is authorization enforced?
Is input trusted?
Is output trusted?
Is communication protected?
Is activity logged?

Step 4 — Identify Threat Actors

Now consider who or what could create risk.

Possible threat actors include:

External Attacker

Attempts to gain unauthorized access.

Malicious Insider

Already has legitimate access but intentionally abuses it.

Compromised Employee Account

A legitimate identity is controlled by an attacker.

Compromised Application

A connected system has been breached.

Malicious Content

Documents or external content contain instructions intended to influence AI behavior.

Supply-Chain Adversary

Compromises models, packages, dependencies or supporting components.

Record the threat actors relevant to your scenario.

Step 5 — Identify Entry Points

Determine how information enters the AI environment.

Potential entry points include:

User prompts
Uploaded documents
RAG documents
APIs
Model inputs
External websites
Plugins
Agent tools
Third-party data
Software dependencies

Represent them as:

User Prompt
     │
     ▼
AI Application

and:

External Document
       │
       ▼
RAG Pipeline
       │
       ▼
LLM Context

The second path is especially important.

The user may not directly control everything that enters the model context.

Step 6 — Create Initial Threat Scenarios

Now create realistic scenarios.

Do not start with framework identifiers.

Start with the business and technical threat.

Threat Scenario 1 — Direct Prompt Manipulation

An employee submits specially crafted instructions attempting to make the AI ignore intended restrictions.

Potential impact:

Unauthorized behavior
Security control bypass
Information disclosure
Unexpected application actions

Threat Scenario 2 — Malicious RAG Document

An attacker places malicious instructions inside a document that later enters the RAG knowledge base.

Flow:

Malicious Document
       ↓
Document Repository
       ↓
RAG Ingestion
       ↓
Vector Database
       ↓
Retrieved Context
       ↓
LLM
       ↓
Manipulated Response

This represents an important indirect trust problem.

Threat Scenario 3 — Sensitive Information Disclosure

A user attempts to retrieve information they should not be permitted to access.

Potential targets:

HR records
Customer information
Credentials
Internal architecture
Security procedures

Threat Scenario 4 — Unsafe Model Output

The model produces output that another component treats as trusted instructions or executable content.

Flow:

LLM Output
     ↓
Application
     ↓
Trusted Processing
     ↓
Security Impact

Threat Scenario 5 — Poisoned Knowledge Source

An attacker modifies enterprise content used by the AI system.

The system begins producing manipulated or incorrect responses.

Potential impact:

Integrity loss
Misinformation
Incorrect decisions
Security control manipulation

Threat Scenario 6 — AI Supply-Chain Compromise

A compromised dependency, model, library or package is introduced into the environment.

Potential impact:

Code execution
Data theft
Backdoors
Model manipulation
Infrastructure compromise

Threat Scenario 7 — Excessive AI Permissions

An AI component or future AI agent has more permissions than required.

If manipulated or compromised, the AI may access unrelated systems or data.

Threat Scenario 8 — Resource Abuse

An attacker repeatedly sends expensive requests.

Potential consequences:

Increased cost
Resource exhaustion
Service degradation
Availability problems

Step 7 — Map Threats to OWASP

Now use the official OWASP guidance.

For every threat scenario:

Search the relevant OWASP AI/LLM security guidance.
Identify the closest applicable risk category.
Read the description.
Compare it with your scenario.
Record the mapping.
Explain why the mapping applies.

Your worksheet might look like:

Threat Scenario	OWASP Mapping	Why It Applies
Direct prompt manipulation	Current prompt-injection category	Untrusted instructions attempt to influence model behavior
Sensitive data exposure	Current sensitive-information category	AI output may expose protected information
Unsafe downstream processing	Current output-handling category	Application trusts model-generated output
Poisoned knowledge source	Current poisoning category	Manipulated information influences AI behavior
Excessive AI permissions	Current agency/permission-related category	AI capabilities exceed required authorization

Do not copy this table blindly.

Validate every mapping using the current official OWASP documentation.

Step 8 — Add Security Controls

For each OWASP-mapped threat, identify controls.

Example:

Prompt Manipulation

Possible controls may include:

Input handling
Context separation
Authorization enforcement
Output validation
Least privilege
Human approval for sensitive actions
Monitoring

Sensitive Information Disclosure

Possible controls may include:

Data classification
Access control
RAG authorization
Data minimization
Output filtering where appropriate
Logging and monitoring

Excessive Agency

Possible controls may include:

Least privilege
Restricted tool access
Scoped credentials
Action allowlists
Human approval
Transaction validation
Monitoring

The key principle is:

Do not rely on the LLM alone to enforce critical security boundaries.

Step 9 — Open MITRE ATLAS

Now switch perspective.

Instead of asking:

What application weakness exists?

ask:

How could an adversary operate against this AI environment?

Review the current MITRE ATLAS knowledge base.

Look for relevant:

Tactics
Techniques
Sub-techniques where applicable
Case studies
Mitigations

Do not attempt to memorize the entire framework.

Learn how to navigate it.

Step 10 — Understand Tactics and Techniques

A tactic describes an adversary objective.

A technique describes how an adversary may achieve that objective.

Conceptually:

Adversary Goal
      │
      ▼
    Tactic
      │
      ▼
  Technique
      │
      ▼
Observed Behavior

This is useful when analyzing an attack as a sequence of behaviors rather than a single vulnerability.

Step 11 — Map Your Threat Scenarios to ATLAS

Return to your scenarios.

For each scenario:

Identify the adversary objective.
Search ATLAS for related behavior.
Identify applicable techniques.
Record the technique.
Explain the relationship.
Record relevant mitigations or detection opportunities.

Create:

Threat Scenario	ATLAS Tactic	ATLAS Technique	Reason
Malicious AI input	Validate from current ATLAS	Validate	Attacker attempts to influence model behavior
Poisoned knowledge	Validate from current ATLAS	Validate	Adversary manipulates AI data or knowledge
Sensitive information theft	Validate from current ATLAS	Validate	Adversary seeks protected information
Model manipulation	Validate from current ATLAS	Validate	Adversary attempts to alter system behavior

Again:

Use the current ATLAS knowledge base to complete the exact mappings.

The objective is learning the mapping process, not copying static identifiers.

Step 12 — Build a Combined Threat Map

Now combine both perspectives.

Your threat register can contain:

ID	Threat	Asset	OWASP	MITRE ATLAS	Impact	Control
T01	Direct prompt manipulation	LLM App	Validate	Validate	High	Input/output controls + authorization
T02	Malicious RAG content	RAG	Validate	Validate	High	Content governance + isolation
T03	Sensitive data disclosure	Enterprise Data	Validate	Validate	Critical	Authorization + data controls
T04	Poisoned knowledge	RAG Data	Validate	Validate	High	Source validation + integrity controls
T05	Excessive AI permissions	AI Agent	Validate	Validate	Critical	Least privilege + approval
T06	Supply-chain compromise	AI Platform	Validate	Validate	Critical	Provenance + dependency controls

Complete the exact framework mappings yourself.

Step 13 — Build an Attack Path

Choose one scenario.

For example:

Indirect manipulation through RAG content

Map the possible attack path:

Threat Actor
     │
     ▼
Creates Malicious Document
     │
     ▼
Document Enters Trusted Repository
     │
     ▼
RAG Pipeline Ingests Document
     │
     ▼
Vector Database Stores Representation
     │
     ▼
User Performs Related Search
     │
     ▼
Malicious Content Is Retrieved
     │
     ▼
Content Enters LLM Context
     │
     ▼
Model Behavior Is Manipulated
     │
     ▼
Potential Data / Action Impact

Now identify where security controls could interrupt the path.

Malicious Document
     │
     ▼
[Content Governance]
     │
     ▼
RAG Ingestion
     │
     ▼
[Source Validation]
     │
     ▼
Retrieval
     │
     ▼
[Context Controls]
     │
     ▼
LLM
     │
     ▼
[Output Validation]
     │
     ▼
Application
     │
     ▼
[Authorization + Least Privilege]

This is defense in depth.

Step 14 — Identify Preventive Controls

Preventive controls attempt to stop the threat.

Examples may include:

Authentication
Authorization
Least privilege
Data classification
Input validation
Output validation
Secure RAG design
Trusted data sources
Dependency verification
Network restrictions
Secret management
Agent permission boundaries
Human approval

Record which threats each control addresses.

Step 15 — Identify Detective Controls

Prevention will not always succeed.

Ask:

How would we know this attack was happening?

Potential telemetry includes:

Authentication Logs
Application Logs
API Logs
Prompt Activity
Model Responses
RAG Retrieval Activity
Document Ingestion Logs
Agent Actions
Cloud Audit Logs
Security Alerts

For each major threat, identify at least one detection opportunity.

Example:

Threat	Possible Detection
Prompt manipulation	Suspicious prompt patterns or anomalous interactions
Data access abuse	Unusual retrieval activity
Resource abuse	Request-rate and cost anomalies
Agent misuse	Unexpected tool invocation
Knowledge poisoning	Unauthorized document changes

Step 16 — Identify Response Actions

Now ask:

If this threat becomes an incident, what would we do?

Possible actions include:

Detect
  ↓
Validate
  ↓
Identify User / Workload
  ↓
Collect Evidence
  ↓
Determine Affected Data
  ↓
Disable Access if Required
  ↓
Contain AI Capability
  ↓
Remove Malicious Content
  ↓
Rotate Credentials
  ↓
Remediate Control
  ↓
Retest

This connects threat modeling with AI Security Operations.

Step 17 — Score the Threats

Use a simple qualitative model.

Likelihood

Low
Medium
High

Impact

Low
Medium
High
Critical

Example:

Threat	Likelihood	Impact	Priority
Prompt manipulation	High	High	High
Sensitive data disclosure	Medium	Critical	Critical
Knowledge poisoning	Medium	High	High
Resource abuse	High	Medium	Medium/High
Supply-chain compromise	Low/Medium	Critical	High

Your rating should be justified by the scenario.

Do not assign severity simply because a framework lists a threat.

Step 18 — Consider Business Impact

Translate technical threats into business language.

Instead of only:

Prompt injection exists.

Explain:

Manipulated model behavior could allow unauthorized disclosure of internal information or trigger actions outside the intended business workflow.

Instead of:

RAG poisoning exists.

Explain:

Manipulated knowledge sources could cause employees to receive incorrect or malicious information from a system they believe is authoritative.

This is how security findings become useful to decision-makers.

Step 19 — Create Your AI Threat Register

Create:

AI-Threat-Register.md

Use:

# Enterprise Knowledge Assistant — AI Threat Register

## System

Enterprise Knowledge Assistant

## Assessment Scope

- Web Application
- Application API
- LLM
- RAG
- Vector Database
- Enterprise Documents
- Identity
- Supporting Infrastructure

## Threat Register

| ID | Threat | Asset | Threat Actor | Attack Path | OWASP Mapping | MITRE ATLAS Mapping | Likelihood | Impact | Existing Controls | Recommended Controls |
|---|---|---|---|---|---|---|---|---|---|---|

## Critical Findings

## High-Risk Findings

## Detection Opportunities

## Recommended Security Controls

## Residual Risk

## Assessment Conclusion

Complete the register using your analysis.

Step 20 — Create a Threat Mapping Matrix

Create:

AI-Threat-Mapping-Matrix.md

Structure:

# AI Threat Mapping Matrix

| Threat | OWASP | MITRE ATLAS | Prevent | Detect | Respond |
|---|---|---|---|---|---|

## Observations

## Framework Gaps

## Security Recommendations

The Prevent → Detect → Respond columns are important.

A mature security program needs all three.

Step 21 — Create an Executive Summary

Your security manager does not need every technical detail first.

Create a short executive summary.

Example structure:

## Executive Summary

The assessment identified several security risks associated with the
Enterprise Knowledge Assistant.

The most significant areas include:

- Manipulation of LLM behavior through untrusted input
- Unauthorized disclosure of enterprise information
- Manipulation of RAG knowledge sources
- Excessive permissions assigned to AI components
- AI software supply-chain risks

The assessment recommends implementing defense-in-depth controls across
identity, data access, RAG ingestion, application processing, AI permissions,
logging and security monitoring before production deployment.

Do not exaggerate findings.

Security reporting should be evidence-based.

Step 22 — Review Your Architecture Again

Return to the architecture.

Your view should now be different.

At the beginning you saw:

User
Application
API
LLM
RAG
Vector Database
Documents

Now you should begin seeing:

Assets
     +
Entry Points
     +
Trust Boundaries
     +
Threat Actors
     +
Attack Paths
     +
OWASP Risks
     +
ATLAS Techniques
     +
Preventive Controls
     +
Detection Opportunities
     +
Response Actions

That shift is the real objective of this lab.

Expected Deliverables

By the end of the mission, you should have:

Lab-03/
│
├── AI-Threat-Register.md
├── AI-Threat-Mapping-Matrix.md
├── Architecture.md
├── Attack-Paths.md
├── Executive-Summary.md
└── Evidence/
    ├── OWASP-Mapping/
    └── MITRE-ATLAS-Mapping/

Your evidence may include screenshots or notes showing how you validated framework mappings.

Evidence Checklist

Capture evidence showing:

Enterprise architecture reviewed
Assets identified
Trust boundaries identified
Threat actors identified
Entry points identified
Threat scenarios documented
OWASP mappings validated
MITRE ATLAS mappings validated
Preventive controls identified
Detective controls identified
Response actions considered
Threats prioritized
Threat register completed
Executive summary completed

Validation Questions

Before completing the lab, answer these questions without referring to your notes.

Question 1

What is the primary difference between OWASP AI/LLM security guidance and MITRE ATLAS?

Question 2

Why should framework mappings be validated against the current official documentation?

Question 3

Why is prompt injection not purely an input-validation problem?

Question 4

How can malicious content enter an LLM without being directly submitted by the user?

Question 5

Why does RAG introduce additional trust boundaries?

Question 6

Why should AI agents follow least privilege?

Question 7

What is the difference between a preventive and detective control?

Question 8

Why should AI security threats be translated into business impact?

Question 9

Why should security teams understand attack paths rather than individual vulnerabilities only?

Question 10

How could OWASP and MITRE ATLAS complement each other during an enterprise AI security assessment?

If you can explain these clearly, you have understood the purpose of the lab.

Real-World Security Engineer Perspective

In a real organization, you may receive an architecture diagram and be asked:

“Can Security review this AI solution before production?”

You will rarely receive a perfect checklist telling you exactly what to investigate.

You may need to:

Understand the Business Use Case
          ↓
Understand the Architecture
          ↓
Identify Sensitive Assets
          ↓
Identify Trust Boundaries
          ↓
Identify Threats
          ↓
Consult Security Frameworks
          ↓
Map Attack Scenarios
          ↓
Review Existing Controls
          ↓
Identify Gaps
          ↓
Prioritize Risk
          ↓
Recommend Controls
          ↓
Document Findings

That is why this lab focuses on the methodology, not memorizing framework numbers.

Frameworks change.

The engineering thought process remains valuable.

Common Mistakes

Mistake 1 — Starting With Framework Numbers

Do not begin by searching for something to map.

First understand the system and identify the threat.

Then use frameworks to support the analysis.

Mistake 2 — Treating OWASP and ATLAS as Identical

They provide different perspectives.

Use them together where appropriate.

Mistake 3 — Mapping Everything to Everything

Not every OWASP category or ATLAS technique applies to every system.

Only map what you can justify.

Mistake 4 — Ignoring Traditional Security

AI applications still require:

IAM
API security
Cloud security
Data security
Network security
Application security
Logging

AI-specific frameworks do not replace these controls.

Mistake 5 — Ignoring Detection

Security architecture should not consist only of preventive controls.

Ask:

How would we detect failure or abuse?

Mistake 6 — Ignoring Business Impact

A technical weakness becomes meaningful when you understand what it could do to:

Data
Customers
Operations
Revenue
Reputation
Compliance
Business decisions

Security Engineer Checklist

Before approving your assessment:

I understand the business use case.
I understand the architecture.
I identified important assets.
I identified trust boundaries.
I identified realistic threat actors.
I documented realistic attack scenarios.
I validated OWASP mappings.
I validated MITRE ATLAS mappings.
I identified preventive controls.
I identified detective controls.
I considered incident response.
I prioritized threats.
I documented business impact.
I recommended actionable controls.
I retained evidence supporting my assessment.

Key Takeaways

You have now moved beyond simply learning individual AI threats.

You have practiced how to analyze them systematically.

Remember:

OWASP helps you understand important application security risks and defensive considerations.

MITRE ATLAS helps you understand adversarial behaviors targeting AI-enabled systems.

But frameworks alone do not perform threat analysis.

The AI Security Engineer must understand:

Architecture
     +
Assets
     +
Data
     +
Identity
     +
Trust Boundaries
     +
Attack Surface
     +
Threat Intelligence
     +
Security Controls
     =
AI Threat Analysis

The most important skill is not memorizing identifiers.

It is being able to look at an AI architecture and determine:

What could go wrong, how could it happen, what would the impact be, how would we prevent it, how would we detect it, and how would we respond?

Mission Complete

You have completed:

Lab 03 — Map AI Threats Using OWASP and MITRE ATLAS

You should now be able to:

Identify AI threats from an enterprise architecture.
Map application risks using OWASP guidance.
Analyze adversary behavior using MITRE ATLAS.
Build attack paths.
Identify preventive and detective controls.
Prioritize AI risks.
Build an AI Threat Register.
Communicate findings in enterprise language.

These skills will be reused throughout the AI Security Engineer Learning Path.

What’s Next?

➡️ Runbook 01 — AI Security Assessment Checklist

You have learned how to analyze an AI system and map its threats.

The next step is to turn that knowledge into a repeatable enterprise security assessment process.

In the next runbook, you will learn how to systematically review:

Business context
AI architecture
Assets
Data
Identity and access
Models
LLM applications
RAG systems
AI agents
APIs
Infrastructure
Supply chain
Logging and monitoring
Threats
Security controls
Governance
Findings and evidence

The goal is to move from:

“I know how to identify AI threats.”

to:

“I can perform a structured AI Security Assessment.”

➡️ Next: Runbook 01 — AI Security Assessment Checklist