Lab 04 Build an AI Attack Tree

Mission Information

In this lab, you will build an AI Attack Tree for a realistic enterprise AI environment.

In the previous labs, you learned how to identify:

Assets
Threat actors
Attack surfaces
Trust boundaries
Threat scenarios
RAG risks
AI agent risks
Attack paths
Security controls

Now you will organize those individual attack paths around a specific attacker objective.

An attack tree helps answer:

What are all the realistic ways an attacker could achieve a particular objective?

For example:

Objective:
Compromise Production Through AI

              ↓

    ┌─────────┼─────────┐
    │         │         │
    ▼         ▼         ▼
Abuse Agent  Steal    Manipulate
Interface   Agent ID   RAG Content

Each branch can then be expanded into additional attack steps.

The goal is to move from a flat list of threats to a visual representation of:

Attacker Objective
       ↓
Alternative Attack Routes
       ↓
Prerequisites
       ↓
Security Weaknesses
       ↓
Critical Assets
       ↓
Business Impact

Lab Difficulty

Intermediate to Advanced

Estimated Time

90–120 minutes

Lab Type

Threat Modeling + Attack Path Analysis + Security Architecture

Prerequisites

Before starting this lab, you should understand:

AI threat modeling
Assets and crown jewels
Threat actors
Attack surfaces
Trust boundaries
STRIDE
OWASP GenAI risks
MITRE ATLAS concepts
RAG security
AI agent security
Attack paths
Risk assessment
Threat-to-control mapping

What You Will Build

By the end of this lab, you will create:

AI-Attack-Tree/
│
├── 01 Attack Objective.md
├── 02 Threat Actors.md
├── 03 Attack Tree.md
├── 04 Attack Branches.md
├── 05 Preconditions.md
├── 06 Control Breakpoints.md
├── 07 Detection Mapping.md
├── 08 Attack Tree Risk Register.md
└── 09 Executive Summary.md

Scenario

You are working as an AI Security Engineer reviewing an enterprise platform called:

Enterprise AI Operations Assistant

The platform combines:

Enterprise Users
      ↓
AI Assistant
      ↓
RAG
      ↓
Enterprise Knowledge

and:

AI Assistant
      ↓
AI Agent
      ↓
Cloud Tools
      ↓
Production Environment

The AI platform can:

Search internal documentation
Retrieve security procedures
Analyze cloud findings
Create incident tickets
Restart selected workloads
Perform approved network changes

The security team is particularly concerned about one objective:

Could an attacker use the AI platform to cause unauthorized changes to production?

Your mission is to build an attack tree for this objective.

Step 1 — Define the Attack Objective

Create:

01 Attack Objective.md

Start with:

# Attack Objective

## Objective ID

AO-01

## Objective

Cause an unauthorized production change through the Enterprise AI Operations Assistant.

## Target Asset

Production Cloud Environment

## Business Impact

Potential:

- Service disruption
- Security control modification
- Unauthorized network exposure
- Data exposure
- Operational impact

## Criticality

Critical

A good attack-tree objective should be:

Specific
Outcome focused
Connected to an asset
Connected to business impact

Avoid vague objectives such as:

Hack AI

Prefer:

Use AI Agent to Perform Unauthorized Production Change

Step 2 — Identify the Root Node

The attack objective becomes the root node.

[AO-01]
Unauthorized Production Change
Through Enterprise AI Platform

Everything below this node represents a possible route to achieving it.

Step 3 — Identify the Main Attack Routes

Ask:

What broad routes could an attacker use to achieve the objective?

For this scenario, use:

                        Unauthorized
                     Production Change
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
        ▼                  ▼                  ▼
 Abuse Agent          Compromise          Manipulate
 Interface            Agent Identity      AI Context

Add another route:

                        Unauthorized
                     Production Change
                           │
       ┌─────────────┬─────┼──────┬─────────────┐
       │             │            │             │
       ▼             ▼            ▼             ▼
 Agent Abuse    Credential     RAG / Context   Tool /
               Compromise      Manipulation    Supply Chain

These become the major branches.

Step 4 — Understand OR Nodes

An OR node means:

Any one of these paths may achieve the objective.

Example:

             Production Compromise
                     OR
          ┌───────────┼───────────┐
          ▼           ▼           ▼
     Agent Abuse   Token Theft   RAG Attack

If any branch succeeds, the attacker may reach the objective.

Use OR relationships for alternative attack paths.

Step 5 — Understand AND Nodes

An AND node means multiple conditions must be satisfied.

Example:

         Abuse Privileged Agent
                 AND
          ┌───────┴───────┐
          ▼               ▼
 Control User       Weak Authorization
     Account

Both may be required.

Another example:

Unauthorized Tool Execution

          AND
       ┌───┼───┐
       ▼   ▼   ▼
Agent   Tool  Missing
Access  Privilege  Approval

Attack trees become especially useful when distinguishing between:

Alternative routes
Required combinations

Step 6 — Build Branch A: Compromised User + Agent Abuse

Start with:

A — Abuse Agent Interface

Expand:

A — Abuse Agent Interface
        │
        ├── A1 Compromise Employee Account
        │
        ├── A2 Access Cloud Operations Agent
        │
        ├── A3 Submit Unauthorized Request
        │
        ├── A4 Bypass / Missing User Authorization
        │
        └── A5 Agent Executes Privileged Tool

Attack path:

Compromise Employee
       ↓
Access AI Agent
       ↓
Request Production Change
       ↓
Missing User-Level Authorization
       ↓
Privileged Tool
       ↓
Production Change

Step 7 — Identify Preconditions for Branch A

Create:

05 Preconditions.md

Document:

## Branch A Preconditions

- Attacker controls a valid employee identity.
- Employee can access the AI agent.
- Agent possesses production capabilities.
- User-level authorization is missing or ineffective.
- Production action does not require sufficient independent approval.

Preconditions help determine how realistic the branch is.

Step 8 — Identify Controls for Branch A

Potential controls:

Compromised User
      ↓
[MFA / Conditional Access]
      ↓
AI Agent
      ↓
[User-Context Authorization]
      ↓
Sensitive Tool
      ↓
[Parameter Validation]
      ↓
[Human Approval]
      ↓
Production

Document which controls:

Exist
Are missing
Need validation

Step 9 — Build Branch B: Agent Credential Compromise

Create:

B — Compromise Agent Identity

Expand:

B — Compromise Agent Identity
        │
        ├── B1 Obtain Agent Credential
        ├── B2 Authenticate to Cloud API
        ├── B3 Use Agent Permissions
        └── B4 Modify Production Resource

Attack path:

Attacker
   ↓
Steal Agent Credential
   ↓
Cloud API
   ↓
Agent Permissions
   ↓
Production Change

Notice:

This path does not require prompt injection or model manipulation.

The attacker bypasses the AI interface completely.

Step 10 — Identify Agent Credential Sources

Potential credential exposure points:

Environment Variables

Application Configuration

CI/CD Secrets

Logs

Developer Workstation

Container Runtime

Cloud Metadata

Secret Store Misconfiguration

Your threat model should determine which are actually relevant.

Step 11 — Branch B Control Breakpoints

Possible controls:

Credential Storage
      ↓
[Managed Identity]
      ↓
Authentication
      ↓
[Short-Lived Token]
      ↓
Cloud API
      ↓
[Least Privilege]
      ↓
Production

Additional controls:

Runtime identity restrictions
Credential monitoring
Fast revocation
Cloud audit logging

Step 12 — Build Branch C: RAG / Context Manipulation

Create:

C — Manipulate AI Context

Expand:

C — Manipulate AI Context
        │
        ├── C1 Modify Enterprise Document
        ├── C2 Document Is Ingested
        ├── C3 Content Is Retrieved
        ├── C4 Content Influences LLM
        ├── C5 Agent Interprets Action
        └── C6 Tool Executes Action

Attack path:

Malicious Contributor
       ↓
Poisoned Document
       ↓
RAG
       ↓
Retrieved Context
       ↓
AI Agent
       ↓
Privileged Tool
       ↓
Production

Step 13 — Identify the Critical RAG-to-Agent Boundary

Highlight:

Retrieved Content
      ↓
========================
UNTRUSTED CONTEXT
========================
      ↓
LLM
      ↓
Agent Decision

The security question is:

Can retrieved content directly or indirectly influence privileged tool execution?

If yes, this branch deserves serious attention.

Step 14 — Branch C Preconditions

Possible preconditions:

## Branch C Preconditions

- Attacker can create or modify an indexed knowledge source.
- The malicious content is successfully ingested.
- The content is later retrieved.
- Retrieved content can influence the model.
- The agent possesses sensitive tools.
- Tool execution lacks sufficient independent authorization.

The number of required conditions may reduce likelihood.

But potential impact remains high.

Step 15 — Branch C Controls

Possible controls:

Contributor
   ↓
[Source Governance]
   ↓
Document
   ↓
[Review + Provenance]
   ↓
RAG
   ↓
[Treat Content as Untrusted]
   ↓
Agent
   ↓
[Restricted Tools]
   ↓
[Authorization]
   ↓
[Approval]

This is defense in depth.

Step 16 — Build Branch D: Tool or Integration Compromise

Create:

D — Compromise Tool / Integration

Expand:

D — Compromise Tool / Integration
        │
        ├── D1 Compromise Tool Service
        ├── D2 Modify Tool Configuration
        ├── D3 Manipulate Destination / Parameters
        └── D4 Perform Unauthorized Action

Example:

Attacker
   ↓
Compromise Tool Configuration
   ↓
Modify Target Resource
   ↓
Agent Invokes Trusted Tool
   ↓
Unauthorized Production Change

The agent may believe it is calling a legitimate tool.

Step 17 — Tool Supply-Chain Branch

Another path may be:

Supply-Chain Attacker
       ↓
Compromise Agent Tool Package
       ↓
Production Deployment
       ↓
Tool Executes Malicious Behavior
       ↓
Cloud API

This demonstrates that attack trees can include traditional software-security threats.

Step 18 — Build Branch E: Authorization Configuration Tampering

Create:

E — Tamper With Authorization / Policy

Attack path:

Privileged Attacker
      ↓
Modify Agent Policy
      ↓
Expand Allowed Actions
      ↓
Agent Performs Production Change

Possible targets include:

IAM policies
Tool policy
Resource allowlists
Approval configuration
Agent configuration

Step 19 — Build Branch F: Approval Bypass

Suppose high-risk production actions require approval.

Attack objective may still be reached if:

F — Bypass Approval

Sub-paths:

F1 — Approval Not Triggered

F2 — Approval Context Manipulated

F3 — Approval Service Misconfigured

F4 — Approver Account Compromised

Attack path example:

Compromised User
      ↓
AI Agent
      ↓
Sensitive Action
      ↓
Incorrectly Classified as Low Risk
      ↓
No Approval
      ↓
Execution

Step 20 — Build the First Complete Attack Tree

Create:

03 Attack Tree.md

Use:

ROOT:
Unauthorized Production Change Through AI Platform

OR
│
├── A. Abuse Agent Interface
│   │
│   ├── Compromise Employee
│   ├── Access Agent
│   ├── Request Sensitive Action
│   ├── Bypass User Authorization
│   └── Execute Privileged Tool
│
├── B. Compromise Agent Identity
│   │
│   ├── Obtain Agent Credential
│   ├── Authenticate to Cloud
│   └── Use Agent Privilege
│
├── C. Manipulate RAG / AI Context
│   │
│   ├── Modify Knowledge
│   ├── RAG Ingests Content
│   ├── Content Retrieved
│   ├── LLM Influenced
│   └── Agent Executes Tool
│
├── D. Compromise Tool / Integration
│   │
│   ├── Compromise Tool
│   ├── Modify Parameters
│   └── Execute Cloud Action
│
├── E. Tamper With Authorization Policy
│   │
│   ├── Gain Policy Access
│   ├── Modify Policy
│   └── Expand Agent Capability
│
└── F. Bypass Approval
    │
    ├── Avoid Approval Trigger
    ├── Manipulate Approval Context
    └── Obtain Approval Illegitimately

Step 21 — Add Threat Actors to the Tree

Create:

02 Threat Actors.md

Map actors to branches.

Example:

Branch	Possible Threat Actors
A	Compromised Employee, Malicious Insider
B	External Attacker, Supply-Chain Attacker
C	Malicious Contributor, External Content Author
D	Supply-Chain Attacker, Compromised Developer
E	Malicious Administrator, Compromised Platform Identity
F	Compromised User, Compromised Approver

One actor may appear in several branches.

Step 22 — Add Trust Boundaries

Annotate where each branch crosses trust boundaries.

Example Branch A:

Employee
   ↓
TB-01
   ↓
AI Agent
   ↓
TB-02
   ↓
Tool Router
   ↓
TB-03
   ↓
Cloud API

Branch C:

Document Contributor
       ↓
TB-04
       ↓
RAG
       ↓
TB-05
       ↓
LLM
       ↓
TB-02
       ↓
Tool

Attack-tree branches often reveal which trust boundaries are most important.

Step 23 — Add Privilege Changes

Highlight privilege transitions.

Example:

Employee
Normal Privilege
      ↓
AI Agent
      ↓
Privileged Workload Identity
      ↓
Production Cloud

Mark:

PRIVILEGE ESCALATION POINT

This is a key control location.

Step 24 — Add Assets

For every leaf or branch identify affected assets.

Examples:

A-01 Employee Identity

A-02 Agent Identity

A-03 Agent Configuration

A-04 Tool Credentials

A-05 RAG Knowledge

A-06 Production Cloud

A-07 Approval Records

A-08 Security Logs

The root target remains:

CJ-01 Production Cloud

Step 25 — Build Detailed Attack Branch Records

Create:

04 Attack Branches.md

Use:

# Branch A — Agent Interface Abuse

## Threat Actor

## Objective

## Entry Point

## Preconditions

## Attack Steps

## Trust Boundaries

## Privilege Changes

## Target Assets

## Existing Controls

## Missing Controls

## Detection Opportunities

## Likelihood

## Impact

## Risk

Repeat for each major branch.

Step 26 — Score Branch A

Example:

Agent Interface Abuse

Likelihood

Medium

Reason:

Requires valid employee access.
Agent is directly reachable internally.

Impact

Critical

Reason:

Successful attack could modify production.

Risk

Critical

depending on your defined risk methodology.

Step 27 — Score Branch B

Agent Identity Compromise

Likelihood

Low to Medium

Requires credential compromise.

Impact

Critical

Attacker may bypass AI controls entirely.

Risk

High / Critical

depending on identity protection and privilege.

Step 28 — Score Branch C

RAG-to-Agent Manipulation

Likelihood

Medium

Requires:

Content influence
Retrieval
Agent behavior
Weak downstream controls

Impact

Critical

if production tools are available.

Risk

High

or Critical depending on architecture.

Step 29 — Score Branch D

Tool / Supply-Chain Compromise

Likelihood

Low to Medium

Usually requires privileged or supply-chain access.

Impact

Critical

Potential direct production impact.

Risk

High

Step 30 — Compare Branches

Create:

08 Attack Tree Risk Register.md

Use:

Branch	Attack Route	Likelihood	Impact	Complexity	Risk
A	Agent Interface Abuse	Medium	Critical	Medium	Critical
B	Agent Credential Compromise	Low/Medium	Critical	Medium	High
C	RAG-to-Agent Manipulation	Medium	Critical	High	High
D	Tool Supply Chain	Low	Critical	High	High
E	Policy Tampering	Low/Medium	Critical	High	High
F	Approval Bypass	Medium	High	Medium	High

Your ratings should reflect actual controls.

Step 31 — Identify the Shortest Attack Path

Ask:

Which branch requires the fewest steps and prerequisites?

Example:

Compromised Employee
       ↓
AI Agent
       ↓
Missing Authorization
       ↓
Production Tool

Short attack paths may deserve additional attention because they may be easier to execute.

Step 32 — Identify the Highest-Impact Branch

Ask:

Which path gives the attacker the greatest control?

Example:

Agent Identity Compromise
       ↓
Cloud Administrator Role
       ↓
Production Environment

Even with lower likelihood, the impact may justify high priority.

Step 33 — Identify the Most Difficult-to-Detect Branch

Example:

Malicious Document
      ↓
RAG
      ↓
Subtle Context Manipulation
      ↓
Agent Action

This may appear like legitimate system activity.

Difficult-to-detect branches may require stronger preventative controls.

Step 34 — Identify Common Dependencies

Several branches may depend on the same weakness.

Example:

A — Agent Abuse
C — RAG Manipulation
F — Approval Bypass

may all depend on:

Agent has excessive production privilege.

This is an important observation.

Step 35 — Identify High-Leverage Controls

If one control breaks multiple branches, it may be highly valuable.

Example:

Least-Privilege Agent Identity

may reduce:

Agent interface abuse
Credential compromise
Prompt injection impact
RAG-to-agent impact
Tool compromise impact

Another:

User-Context Authorization

may reduce:

Compromised employee abuse
Direct prompt manipulation
Confused deputy paths

Step 36 — Build the Control Breakpoint Map

Create:

06 Control Breakpoints.md

Use:

Branch	Attack Stage	Control	Control Type
A	User Access	MFA	Prevent
A	Agent Action	User Authorization	Prevent
A	Tool Execution	Parameter Validation	Prevent
B	Agent Identity	Managed Identity	Prevent
B	Cloud API	Least Privilege	Impact Reduction
C	Document Source	Source Governance	Prevent
C	Agent Action	Policy Enforcement	Prevent
D	Dependency	Artifact Integrity	Prevent
F	Approval	Approval Integrity	Prevent

Step 37 — Map Preventive Controls

Possible preventive controls include:

MFA

Conditional Access

Source Governance

Least Privilege

User-Context Authorization

Tool Allowlisting

Parameter Validation

Approval

Network Restrictions

Model / Dependency Integrity

Do not attempt to place every control on every branch.

Map only those relevant to the path.

Step 38 — Add Detective Controls

Create:

07 Detection Mapping.md

Examples:

Branch	Detection Opportunity
A	User/agent privilege mismatch
B	Agent identity used from unexpected runtime
C	Suspicious document changes + unusual agent action
D	Unexpected tool package or configuration modification
E	IAM / policy change monitoring
F	Approval anomalies

Step 39 — Detection Along Branch A

Attack path:

Compromised Employee
       ↓
AI Agent
       ↓
Privileged Tool
       ↓
Production

Detection points:

Authentication Anomaly
       ↓
Agent Interaction Anomaly
       ↓
High-Risk Tool Call
       ↓
Cloud Configuration Change

Multiple detection layers increase visibility.

Step 40 — Detection Along Branch C

Attack path:

Document Change
      ↓
RAG
      ↓
Agent Action

Possible telemetry:

Document Change Logs

RAG Ingestion Logs

Retrieval Logs

Agent Tool Logs

Cloud Audit Logs

Correlating these sources can reveal the complete sequence.

Step 41 — Map Responsive Controls

For each branch determine containment.

Example:

Branch	Primary Containment
A	Disable compromised user + agent
B	Revoke agent identity
C	Remove poisoned content + disable agent
D	Disable tool integration
E	Roll back policy
F	Disable affected approval flow

Step 42 — Build a Kill-Chain View

Convert one attack-tree branch into a linear sequence.

Example:

Initial Access
      ↓
Compromise Employee
      ↓
AI Discovery
      ↓
Identify Privileged Agent
      ↓
Manipulation
      ↓
Request Sensitive Action
      ↓
Privilege Abuse
      ↓
Tool Execution
      ↓
Impact
      ↓
Production Change

This makes it easier to map MITRE ATT&CK / ATLAS concepts where appropriate.

Step 43 — Map STRIDE

Each branch may involve multiple STRIDE categories.

Example Branch A:

Compromised User
      ↓
Spoofing

Agent Privilege Abuse
      ↓
Elevation of Privilege

Production Modification
      ↓
Tampering

Branch B:

Agent Identity Theft
      ↓
Spoofing

Production Change
      ↓
Tampering

Branch C:

RAG Poisoning
      ↓
Tampering

Agent Action
      ↓
Elevation of Privilege

Step 44 — Map OWASP GenAI Guidance

Relevant areas may include:

Prompt injection
Data poisoning
Excessive agency
Sensitive information disclosure
Supply-chain risks
Improper output handling

Do not force every branch into an OWASP category.

Use mappings only when they improve understanding.

Step 45 — Map MITRE ATLAS

Review the attack branches from an adversary-behavior perspective.

Potential stages include:

Reconnaissance

Discovery

Access

AI Context Manipulation

Credential Abuse

Collection

Impact

Validate current ATLAS technique names and identifiers during real assessments.

Step 46 — Create Attack Tree Security Requirements

Use the attack tree to generate requirements.

TREE-SEC-001

Sensitive AI agent operations must be independently authorized using the initiating user's identity.

TREE-SEC-002

Production AI agent identities must follow least privilege and must not contain unrestricted administrative permissions.

TREE-SEC-003

Content retrieved through RAG must not directly authorize privileged agent operations.

TREE-SEC-004

High-risk production actions must require deterministic policy validation.

TREE-SEC-005

Critical production actions must require approval where defined by risk policy.

TREE-SEC-006

Agent credentials must be short-lived and rapidly revocable.

TREE-SEC-007

Changes to AI agent policies, tool definitions and permissions must be auditable.

TREE-SEC-008

Security Operations must be able to disable production AI agent tool access during an incident.

Step 47 — Remove an Attack Branch Through Architecture

One of the strongest security outcomes is eliminating a path completely.

Suppose:

Network Modification Tool

is not actually required.

Before:

User
 ↓
Agent
 ↓
Network Tool
 ↓
Production

After:

Network Tool Removed

The entire attack branch disappears.

This is stronger than adding additional prompt filters.

Step 48 — Reduce a Branch Through Privilege

Before:

Agent
 ↓
Cloud Administrator

After:

Agent
 ↓
Restart Approved Workloads Only

The attack may still be possible.

But its impact is significantly reduced.

Step 49 — Validate Critical Branches

For high-priority attack branches, create authorized security tests.

Example:

Branch A Validation

Objective:

Confirm that a user without production restart rights cannot use the agent to restart a production workload.

Expected:

DENIED

Branch C Validation

Objective:

Confirm that test RAG content cannot cause the agent to bypass tool authorization.

Expected:

Sensitive Action
      ↓
Authorization / Approval
      ↓
DENIED

Do this only in authorized testing environments.

Step 50 — Validate Credential Blast Radius

Review the agent workload identity.

Document:

If Agent Identity Is Compromised:

Can It Read Production?

Can It Modify Production?

Can It Modify IAM?

Can It Disable Logging?

Can It Access Secrets?

Can It Reach Other Accounts?

Use the answers to validate Branch B’s impact rating.

Step 51 — Build a Second Attack Tree

Now create another root objective:

Steal Confidential Enterprise RAG Data

Use:

                Steal Confidential RAG Data
                          OR
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
   Abuse Retrieval   Compromise DB   Compromise
    Authorization      Identity       User Account
          │
          ▼
   Restricted Data

Add additional branches such as:

Cross-department retrieval
Vector database compromise
RAG service identity compromise
Data leakage through external LLM
Agent-based exfiltration

Step 52 — Build a Third Attack Tree

Root objective:

Manipulate Enterprise AI Responses

Possible branches:

Knowledge Poisoning

Model Tampering

Prompt / Context Injection

Vector Metadata Tampering

Compromised Data Source

Supply-Chain Manipulation

This demonstrates that attack trees are reusable across different security objectives.

Step 53 — Attack Tree Risk Prioritization

Ask:

Which Branch Is Easiest?

Which Branch Has Greatest Impact?

Which Branch Has Fewest Controls?

Which Branch Is Hardest to Detect?

Which Branch Has Largest Blast Radius?

Which Branch Can Be Removed by Design?

These questions make the attack tree actionable.

Step 54 — Build the Executive Summary

Create:

09 Executive Summary.md

Use:

# Executive Summary

## Assessment

AI Attack Tree — Unauthorized Production Change

## Root Objective

Cause unauthorized production changes through the Enterprise AI Operations Assistant.

## Overall Risk

High

## Highest-Risk Branches

1. Compromised employee abusing privileged AI agent.
2. Agent workload identity compromise.
3. RAG or external content influencing privileged agent actions.
4. Excessive tool permissions or unsafe tool parameters.
5. Authorization or approval policy tampering.

## Highest-Value Controls

1. User-context authorization.
2. Least-privilege agent identities.
3. Restricted tool availability.
4. Deterministic tool parameter validation.
5. Human approval for critical operations.
6. Strong source governance for RAG.
7. Centralized user-to-agent-to-tool logging.
8. Tested agent kill switch.

## Security Conclusion

The most important risk is not simply that the model can be influenced.

The highest risk occurs when influenced AI behavior is connected to privileged enterprise capabilities without strong independent authorization.

Reducing agent permissions and enforcing deterministic authorization breaks multiple attack-tree branches simultaneously.

Expected Deliverables

Your completed lab should include:

Clearly defined root attack objective
Target crown-jewel asset
Threat actor mapping
At least 6 major attack branches
OR relationships
AND relationships
Preconditions
Trust boundaries
Privilege transitions
Target assets
At least 3 detailed branch analyses
Risk rating for each major branch
Preventive control mapping
Detective control mapping
Responsive control mapping
High-leverage controls
At least 8 security requirements
Validation scenarios
Executive summary

Lab Success Criteria

You have successfully completed the lab when you can explain:

                ROOT OBJECTIVE
                      ↓
               ATTACK BRANCHES
                      ↓
               ATTACK STEPS
                      ↓
                PRECONDITIONS
                      ↓
               TRUST BOUNDARIES
                      ↓
             PRIVILEGE TRANSITIONS
                      ↓
                 TARGET ASSETS
                      ↓
               BUSINESS IMPACT

and then map:

Attack Branch
      ↓
Prevent
      ↓
Detect
      ↓
Respond

You should also be able to identify:

Which single security control reduces the greatest number of important attack paths?

That is one of the most valuable outcomes of attack-tree analysis.

Security Engineer Challenge

The organization proposes changing the agent from:

AI Agent
 ↓
Approved Production Operations

to:

AI Agent
 ↓
Cloud Administrator

Rebuild the relevant branches.

Determine:

Which branches now become shorter?
Which branches increase in impact?
Does credential compromise become Critical?
Does prompt manipulation become more dangerous?
Does RAG poisoning risk increase?
Does the confused deputy path become easier?
Which controls become mandatory?
Can architecture remove the need for Administrator access?

A mature security recommendation should question whether broad administrative capability is needed at all.

Real-World Takeaway

An attack tree helps security teams move from:

"There are many AI risks."

to:

"Here are the realistic routes an attacker could use
to reach our critical asset."

It also allows you to identify:

Common Weaknesses
       ↓
Common Control Points
       ↓
High-Leverage Security Improvements

For example:

Prompt Manipulation ───────┐
                           │
RAG Poisoning ─────────────┼──► Privileged Agent
                           │
Compromised User ──────────┘
                                ↓
                         Least Privilege
                                +
                       User Authorization

Instead of trying to perfectly prevent every possible manipulation method, you can secure the privilege boundary that all of those attacks depend on.

Lab Review Questions

Question 1

What is the root node of an attack tree?

Question 2

What is the difference between an AND node and an OR node?

Question 3

Why should attack-tree objectives be specific?

Question 4

What is a precondition?

Question 5

Why should trust boundaries be added to attack trees?

Question 6

Why are privilege transitions particularly important?

Question 7

How can agent credential compromise bypass model-level protections?

Question 8

How can RAG content become part of a production attack path?

Question 9

What is a high-leverage security control?

Question 10

Why can removing an unnecessary tool be stronger than adding additional controls?

Question 11

Why should detection opportunities be mapped to attack-tree branches?

Question 12

How do attack trees help prioritize security investments?

Question 13

Why should multiple root objectives sometimes have separate attack trees?

Question 14

How does least privilege reduce multiple attack-tree branches simultaneously?

Key Takeaways

An AI attack tree begins with a specific adversary objective:

Attacker Objective
       ↓
Alternative Attack Routes
       ↓
Required Conditions
       ↓
Security Weaknesses
       ↓
Trust / Privilege Boundaries
       ↓
Critical Asset
       ↓
Business Impact

For modern enterprise AI systems, important attack branches may involve:

Compromised Users
        +
Prompt / Context Manipulation
        +
RAG Poisoning
        +
Agent Credential Compromise
        +
Tool Abuse
        +
Policy Tampering
        +
Supply-Chain Compromise

The central principle is:

Do not secure every AI threat independently when several attack paths depend on the same privilege boundary. Identify the shared control points and secure those first.

Attack trees help you see those shared dependencies.

What’s Next?

➡️ Runbook 01 — AI Threat Modeling Methodology

You have now completed the practical labs for the AI Threat Modeling module.

You have practiced:

Building an AI threat model
Threat modeling enterprise RAG
Threat modeling AI agents
Building AI attack trees

The next section converts everything you have learned into operational runbooks.

In Runbook 01, you will create a repeatable methodology that an AI Security Engineer can use during real security engagements.

You will build a step-by-step process for:

Scoping an AI threat model
Gathering architecture information
Identifying assets
Mapping data flows
Identifying trust boundaries
Identifying threats
Applying STRIDE
Using OWASP GenAI
Using MITRE ATLAS
Building attack paths
Assessing risk
Mapping controls
Documenting results
Reviewing and maintaining the threat model

The goal is to move from:

“I know how to perform AI threat modeling.”

to:

“I have a repeatable professional methodology I can use on real AI systems.”

➡️ Next: Runbook 01 — AI Threat Modeling Methodology