11 Building AI Attack Paths and Abuse Cases

So far in this module, you have learned how to identify:

• AI assets
• Data flows
• Trust boundaries
• Threat actors
• Attack surfaces
• STRIDE threats
• OWASP GenAI risks
• MITRE ATLAS adversary behaviors
• RAG threats
• AI agent threats

Now the next step is to connect these individual findings together.

A real attack rarely happens as one isolated event.

For example:

Prompt Injection

by itself may not explain the full risk. A more realistic attack may look like:

Compromised User
      ↓
AI Assistant
      ↓
Prompt Manipulation
      ↓
Privileged AI Agent
      ↓
Cloud Administration Tool
      ↓
Production Resource
      ↓
Business Impact

This is an attack path.

Threat modeling becomes much more useful when security teams can explain:

How could an attacker move from an entry point to a critical asset?

This lesson focuses on building those attack paths and converting them into structured abuse cases.

Learning Objectives

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

• Explain what an AI attack path is.

• Explain what an abuse case is.

• Distinguish isolated threats from multi-stage attack scenarios.

• Build attack paths from threat actors to business impact.

• Identify preconditions for an attack.

• Connect entry points, trust boundaries and assets.

• Model RAG-to-agent attack chains.

• Model identity-to-agent privilege escalation.

• Model supply-chain attack paths.

• Model data collection and exfiltration.

• Model production-impact scenarios.

• Identify control breakpoints.

• Map Prevent, Detect and Respond controls to attack paths.

• Build an AI Abuse Case Register.

• Prioritize high-impact attack paths.

1. What Is an Attack Path?

An attack path is the sequence of steps an attacker may follow to move from an initial position to a target asset or business outcome.

A simple example:

Attacker
   ↓
Compromised Employee Account
   ↓
AI Assistant
   ↓
Unauthorized RAG Retrieval
   ↓
Confidential Data

A more complex example:

External Attacker
      ↓
Malicious Document
      ↓
RAG Ingestion
      ↓
LLM Context
      ↓
AI Agent
      ↓
Privileged Tool
      ↓
Production System

The attack path helps explain how multiple conditions connect.

2. Why Attack Paths Matter

Security teams often identify threats individually.

For example:

• Prompt injection

• Excessive agent permissions

• Weak RAG authorization

• Missing logging

Individually, these are useful findings.

But the business may ask:

What could actually happen if these weaknesses are combined?

Attack path analysis provides that answer.

For example:

Prompt Injection
      +
Excessive Agent Permissions
      +
Missing Approval
      =
Unauthorized Production Action

This is much easier for stakeholders to understand.

3. What Is an Abuse Case?

An abuse case describes how a system could be intentionally misused or abused.

A normal use case might be:

An employee asks the AI assistant to summarize an approved internal document.

An abuse case might be:

A compromised employee account attempts to use the AI assistant to retrieve documents outside the employee’s authorized department.

Another:

A malicious document contributor inserts instructions into a RAG source to influence an AI agent.

Abuse cases help security teams think from the attacker’s perspective.

4. Use Case vs Abuse Case

Consider a cloud security AI agent.

Use Case

Security Engineer
      ↓
AI Agent
      ↓
Read Cloud Security Findings
      ↓
Generate Summary

Abuse Case

Compromised User
      ↓
AI Agent
      ↓
Manipulated Request
      ↓
Privileged Cloud Tool
      ↓
Unauthorized Resource Change

Both involve the same application.

The difference is:

• Intent

• Authorization

• Attack path

5. Threat vs Abuse Case vs Attack Path

These concepts are related.

Threat

An undesirable event.

Example:

Unauthorized cloud modification.

Abuse Case

A realistic misuse scenario.

Example:

A compromised employee uses the AI agent to modify a production security group.

Attack Path

The technical sequence that makes the abuse possible.

Example:

Compromised Employee
      ↓
AI Agent
      ↓
Missing User Authorization
      ↓
Privileged Agent Identity
      ↓
Cloud API
      ↓
Production Security Group

The attack path explains the mechanics.

6. Attack Path Building Blocks

Most attack paths contain several building blocks.

Threat Actor
      ↓
Entry Point
      ↓
Attack Surface
      ↓
Trust Boundary
      ↓
Weakness
      ↓
Privilege / Access
      ↓
Target Asset
      ↓
Business Impact

Not every attack requires every element, but this is a useful structure.

7. Start With the Threat Actor

Every attack path should begin with:

Who is performing the attack?

Examples:

• External attacker

• Compromised employee

• Malicious insider

• Supply-chain attacker

• Malicious document contributor

• Compromised workload

Different actors have different starting positions.

8. Identify the Starting Position

Ask:

What access does the attacker already have?

Example:

External Attacker
      ↓
Public Chat Interface

or:

Compromised Employee
      ↓
Authenticated Internal AI Assistant

or:

Malicious Developer
      ↓
Source Repository

This starting point determines the rest of the path.

9. Identify the Objective

What does the attacker want?

Examples:

• Steal customer information

• Manipulate AI responses

• Gain cloud privileges

• Exfiltrate source code

• Cause service disruption

• Perform unauthorized transactions

Write the objective clearly.

For example:

Obtain confidential HR records using the enterprise AI assistant.

10. Identify the Target Asset

The target should be specific.

Weak:

Data

Better:

Restricted HR documents

or:

Production cloud administrator privileges

or:

Proprietary model weights

A clear target makes impact easier to understand.

11. Work Forward or Backward

Attack paths can be built in two ways.

Forward Analysis

Start with the attacker.

Attacker
   ↓
Entry Point
   ↓
...
   ↓
Critical Asset

Backward Analysis

Start with the critical asset.

Critical Asset
      ↑
What Can Access It?
      ↑
What Can Influence That?
      ↑
Who Can Reach It?

Both approaches are useful.

12. Backward Analysis Example

Critical asset:

Production Cloud Administrator API

Work backward:

Production Cloud API
       ↑
Cloud Agent
       ↑
AI Agent Interface
       ↑
Employee

Now ask:

Can a normal employee influence a privileged agent?

This may reveal a confused deputy path.

13. Preconditions

A realistic attack path should document what must already be true.

For example:

Preconditions:

- Attacker controls an employee account.
- AI agent has production cloud access.
- User authorization is not independently validated.

Without these conditions, the attack may not work.

Preconditions make the scenario more credible.

14. Attack Path 1 — Unauthorized RAG Data Retrieval

Consider an enterprise knowledge assistant.

Compromised Employee
       ↓
Internal AI Assistant
       ↓
RAG Query
       ↓
Weak Retrieval Authorization
       ↓
Restricted HR Document
       ↓
LLM Response
       ↓
Sensitive Data Disclosure

Threat Actor

Compromised employee account.

Objective

Obtain confidential HR information.

Entry Point

AI assistant.

Weakness

RAG retrieval checks authentication but not document-level authorization.

Target Asset

Confidential HR records.

Impact

Unauthorized disclosure of employee information.

15. Attack Path 2 — RAG Poisoning

Malicious Contributor
       ↓
Enterprise Knowledge Source
       ↓
Modified Document
       ↓
RAG Ingestion
       ↓
Vector Database
       ↓
LLM
       ↓
Manipulated Response

Potential impact:

• Incorrect security guidance

• User deception

• Policy manipulation

16. Attack Path 3 — RAG to Agent

One of the most important modern AI attack paths is:

External Attacker
      ↓
Malicious Document
      ↓
RAG Source
      ↓
Retrieved Context
      ↓
LLM
      ↓
AI Agent
      ↓
Privileged Tool
      ↓
Enterprise Action

This combines:

Indirect Prompt Injection
        +
RAG Trust
        +
Agent Capability

The actual risk depends heavily on downstream permissions.

17. Attack Path 4 — Identity to Privileged Agent

Consider:

Attacker
   ↓
Compromised Employee Credential
   ↓
Internal AI Agent
   ↓
Agent Uses Privileged Workload Identity
   ↓
Cloud Administration API
   ↓
Production Modification

This path may combine:

• Credential compromise

• Missing user-context authorization

• Excessive agent privilege

18. Attack Path 5 — Agent Credential Theft

Not every agent attack requires prompt manipulation.

Attacker
   ↓
Exposed Agent Credential
   ↓
Enterprise API
   ↓
Sensitive Resource

The attacker bypasses the AI interface entirely.

This demonstrates why traditional security remains critical.

19. Attack Path 6 — Supply-Chain Compromise

Consider:

Supply-Chain Attacker
        ↓
Compromised Package
        ↓
AI Application Build
        ↓
Production Deployment
        ↓
Credential Theft
        ↓
Enterprise Data

or:

Supply-Chain Attacker
        ↓
Compromised Model
        ↓
Model Registry
        ↓
Production AI Service

Supply-chain attacks may enter through trusted engineering workflows.

20. Attack Path 7 — Model Registry Compromise

Attacker
   ↓
Compromised Developer / Registry Credential
   ↓
Model Registry
   ↓
Replace Approved Model
   ↓
Production Deployment
   ↓
Manipulated AI Behavior

Controls should exist at:

• Registry access

• Model validation

• Deployment approval

• Integrity verification

21. Attack Path 8 — Sensitive Data Collection

Consider:

Compromised Employee
       ↓
AI Assistant
       ↓
Repeated RAG Queries
       ↓
Sensitive Documents
       ↓
Local Collection

Each query may appear legitimate.

The attack becomes visible when viewed as a pattern.

Detection may require:

• Volume analysis

• Cross-domain access

• User behavior monitoring

22. Collection vs Exfiltration

Do not combine these automatically.

Collection

Attacker gathers data.

AI Assistant
      ↓
Sensitive Information
      ↓
Attacker Session

Exfiltration

Attacker moves data outside the trusted environment.

Collected Data
      ↓
External Email / API / Storage

These may require different controls.

23. Attack Path 9 — Agent-Based Exfiltration

Compromised User
      ↓
AI Agent
      ↓
RAG Data
      ↓
External Email Tool
      ↓
External Recipient

The AI agent may unintentionally become an exfiltration channel.

Controls could include:

• External send restrictions

• DLP

• User authorization

• Approval

• Destination controls

24. Attack Path 10 — Production Impact

Consider:

Compromised User
      ↓
AI Cloud Agent
      ↓
Privileged Tool
      ↓
Security Group Modification
      ↓
Production Service Exposure

This connects AI security directly with enterprise cloud security.

25. Attack Path 11 — Denial of Service

An AI attack path does not always target confidentiality or privilege.

Example:

External Attacker
      ↓
Public AI API
      ↓
Automated Large Requests
      ↓
LLM + RAG + Tool Calls
      ↓
Resource Exhaustion
      ↓
Service Degradation

Potential impact:

• Availability loss

• Increased cost

• Quota exhaustion

26. Attack Path 12 — Memory Poisoning

Attacker
   ↓
Malicious Input
   ↓
Persistent Agent Memory
   ↓
Future User Session
   ↓
Influenced Agent Behavior

This path can persist beyond the original interaction.

27. Attack Path 13 — Multi-Agent Privilege Escalation

Consider:

Low-Privilege User
      ↓
General Assistant
      ↓
Privileged Cloud Agent
      ↓
Cloud Tool
      ↓
Production

If the second agent trusts instructions from the first agent without validating authority, privilege boundaries may be bypassed.

28. Attack Path 14 — Tool Response Manipulation

AI Agent
   ↓
External API
   ↓
Manipulated Response
   ↓
LLM Context
   ↓
Next Tool Decision
   ↓
Enterprise Action

This illustrates that tool responses are also inputs.

29. Attack Trees

An attack tree represents multiple ways an attacker could achieve one objective.

Example objective:

Obtain confidential enterprise data.

                   Steal Enterprise Data
                           │
         ┌─────────────────┼─────────────────┐
         │                 │                 │
         ▼                 ▼                 ▼
    Abuse RAG       Steal Agent Token    Compromise API
         │
    ┌────┴────┐
    │         │
    ▼         ▼
Weak Authz  Compromised User

Attack trees help security teams identify alternative paths.

30. Attack Graphs

Attack graphs are useful when multiple components connect.

Example:

Compromised User
      │
      ├────► RAG ─────► Sensitive Data
      │
      └────► Agent ───► Cloud API
                         │
                         ▼
                    Production

This shows that one compromised identity may have several potential attack paths.

31. Identify Choke Points

A choke point is a control that interrupts multiple attack paths.

For example:

User
 ↓
Authorization Layer
 ↓
AI Systems

Strong authorization may interrupt:

• Unauthorized RAG access

• Agent privilege abuse

• Tool misuse

Choke points are valuable because one strong control can reduce multiple risks.

32. Identify Single Points of Security Failure

The opposite may also occur.

Example:

All AI Agents
      ↓
Shared Admin Credential

If this credential is compromised, many controls fail simultaneously.

This creates a dangerous concentration of risk.

33. Attack Path Decomposition

Break complex paths into stages.

Example:

Stage 1 — Access
Compromise Employee

Stage 2 — Discovery
Identify Cloud Agent

Stage 3 — Manipulation
Influence Agent Request

Stage 4 — Privilege Abuse
Agent Uses Cloud Admin Role

Stage 5 — Impact
Modify Production Resource

This makes the scenario easier to map to controls and detection.

34. Map MITRE ATLAS to Attack Stages

A multi-stage path may contain several relevant adversary behaviors.

Example:

Discovery
   ↓
AI Capability Identification
   ↓
Context Manipulation
   ↓
Agent Tool Abuse
   ↓
Impact

Validate specific tactics and technique identifiers against the current MITRE ATLAS knowledge base during real assessments.

35. Map STRIDE to Attack Paths

A single attack path may cross multiple STRIDE categories.

Example:

Compromised Employee

may involve:

Spoofing

Then:

Malicious RAG Document

may involve:

Tampering

Then:

Sensitive Data Returned

may involve:

Information Disclosure

Then:

Privileged Agent Action

may involve:

Elevation of Privilege

Attack paths connect categories that are otherwise analyzed separately.

36. Map OWASP GenAI Risks to Attack Paths

Example:

Indirect Prompt Injection
      ↓
AI Agent
      ↓
Excessive Agency
      ↓
Sensitive Information Disclosure

One attack path may contain multiple AI risk patterns.

That is normal.

37. Attack Path Impact

Do not stop at the technical asset.

Ask:

What happens to the business?

Example:

Production IAM Modification
      ↓
Unauthorized Privilege
      ↓
Customer Data Exposure
      ↓
Incident
      ↓
Regulatory / Financial Impact

Security teams should communicate the complete impact chain where appropriate.

38. Business Impact Categories

Potential outcomes include:

• Confidentiality breach

• Financial loss

• Service disruption

• Regulatory exposure

• Customer impact

• Intellectual property theft

• Reputation damage

• Operational disruption

• Safety impact

Not every scenario will involve all of these.

39. Identify Control Breakpoints

For each attack path, identify where the path can be interrupted.

Example:

Compromised User
      ↓
[MFA / Conditional Access]
      ↓
AI Agent
      ↓
[User Authorization]
      ↓
Privileged Tool
      ↓
[Least Privilege]
      ↓
Production Action
      ↓
[Approval]

Each bracketed control represents a possible breakpoint.

40. Prevent, Detect and Respond

For every significant attack path, map:

PREVENT
Where can we stop it?

DETECT
Where can we observe it?

RESPOND
How do we contain it?

This makes the threat model operational.

41. Example — Privileged Agent Abuse

Attack Path

Compromised Employee
       ↓
AI Agent
       ↓
Privileged Cloud Tool
       ↓
Production Modification

Prevent

• MFA

• User-context authorization

• Least privilege

• Tool restrictions

• Approval

Detect

• Authentication anomaly

• Privileged tool invocation

• Unusual cloud change

Respond

• Disable user session

• Disable agent identity

• Revoke token

• Restore configuration

42. Example — RAG Poisoning

Attack Path

Malicious Contributor
       ↓
Document Modification
       ↓
RAG Ingestion
       ↓
Manipulated Response

Prevent

• Contributor restrictions

• Source approval

• Change control

Detect

• Document modification alerts

• Ingestion anomalies

• Model behavior changes

Respond

• Remove poisoned content

• Reindex knowledge

• Investigate contributor

• Review affected interactions

43. Example — Data Exfiltration

Attack Path

Compromised User
      ↓
AI Assistant
      ↓
Sensitive RAG Data
      ↓
AI Agent
      ↓
External Email

Prevent

• Retrieval authorization

• Data classification

• External tool restrictions

• DLP

Detect

• Sensitive retrieval

• External destination anomaly

• Agent tool monitoring

Respond

• Disable session

• Revoke tool access

• Investigate data scope

• Notify incident response

44. Attack Path Scoring

Attack path priority should consider more than one weakness.

A simple model may include:

Likelihood
+
Impact
+
Path Complexity
+
Existing Controls

Consider:

• Number of prerequisites

• Exposure

• Required privileges

• Attacker capability

• Asset value

• Blast radius

45. Path Complexity

Compare:

Path A

Public User
   ↓
Weak API Authorization
   ↓
Sensitive Data

Very short.

Path B

External Attacker
      ↓
Compromise Developer
      ↓
Compromise CI/CD
      ↓
Replace Model
      ↓
Production

More complex.

The second may have higher impact but lower likelihood.

46. Attack Path Prioritization Table

Example:

Path	Likelihood	Impact	Complexity	Priority
Unauthorized RAG Retrieval	High	High	Low	Critical
Privileged Agent Abuse	Medium	Critical	Medium	Critical
Model Supply Chain	Low/Medium	Critical	High	High
Resource Exhaustion	High	Medium	Low	High

Use an organizational risk methodology where available.

47. Abuse Case Register

Create an Obsidian note:

AI Abuse Case Register.md

Use:

ID	Abuse Case	Threat Actor	Entry Point	Target Asset	Business Impact	Priority
AC-01	Unauthorized RAG Retrieval	Compromised Employee	AI Assistant	HR Data	Data Breach	Critical
AC-02	Privileged Agent Abuse	Compromised User	Agent Interface	Cloud Production	Service Impact	Critical
AC-03	Knowledge Poisoning	Malicious Contributor	Document Source	RAG Knowledge	Incorrect Decisions	High
AC-04	Model Replacement	Supply-Chain Attacker	Model Registry	Production Model	AI Compromise	High

48. Abuse Case Template

Use:

# AC-XX — Abuse Case Name

## Business Scenario

## Threat Actor

## Attacker Objective

## Starting Position

## Entry Point

## Attack Surface

## Trust Boundaries

## Target Assets

## Preconditions

## Abuse Scenario

## Attack Path

## STRIDE Mapping

## OWASP Mapping

## MITRE ATLAS Mapping

## Existing Controls

## Control Gaps

## Detection Opportunities

## Response Actions

## Business Impact

## Risk Rating

49. Example Abuse Case — RAG to Agent

# AC-05 — Malicious RAG Content Causes Privileged Agent Action

## Business Scenario

An enterprise AI assistant uses RAG for internal knowledge and can execute approved IT actions through an AI agent.

## Threat Actor

Malicious document contributor.

## Attacker Objective

Cause the AI agent to perform an unauthorized enterprise action.

## Starting Position

The attacker can create or modify a document in an indexed knowledge repository.

## Entry Point

RAG knowledge source.

## Attack Surface

Document ingestion pipeline.

## Trust Boundaries

- Document Source → RAG
- RAG → LLM
- LLM → AI Agent
- Agent → Enterprise Tool

## Target Assets

Enterprise systems accessible through agent tools.

## Preconditions

- Attacker can modify an indexed document.
- Retrieved content may influence model behavior.
- Agent has access to sensitive tools.
- Sensitive actions lack independent authorization.

## Abuse Scenario

The attacker embeds malicious natural-language instructions in a document. The document is later retrieved by the RAG service and included in the LLM context. The model interprets part of the content as an instruction and proposes an action. The AI agent invokes a privileged enterprise tool without sufficient independent authorization.

## Attack Path

Malicious Contributor
       ↓
Knowledge Document
       ↓
RAG Ingestion
       ↓
Vector Database
       ↓
Retrieved Context
       ↓
LLM
       ↓
AI Agent
       ↓
Privileged Tool
       ↓
Enterprise Action

## STRIDE Mapping

- Tampering
- Elevation of Privilege

## OWASP Mapping

Relevant current prompt injection, poisoning and excessive-agency guidance.

## MITRE ATLAS Mapping

Validate relevant current AI data/context manipulation and impact techniques.

## Existing Controls

- Repository authentication
- Agent workload identity

## Control Gaps

- Weak content governance
- Retrieved content overly trusted
- Agent has excessive authority
- Missing action authorization

## Detection Opportunities

- Suspicious document changes
- RAG ingestion activity
- Retrieved-content correlation
- Unusual tool invocation
- Privileged enterprise events

## Response Actions

- Disable agent
- Remove malicious document
- Rebuild affected index
- Review impacted agent actions
- Investigate contributor identity

## Business Impact

Unauthorized changes to enterprise systems.

## Risk Rating

Critical

50. Build an Attack Path Diagram

For major risks, create a simple diagram.

Example:

[Threat Actor]
      │
      ▼
[Entry Point]
      │
      ▼
[Trust Boundary]
      │
      ▼
[AI Component]
      │
      ▼
[Privilege Boundary]
      │
      ▼
[Critical Asset]
      │
      ▼
[Business Impact]

This is especially useful during architecture reviews.

51. Add Controls to the Diagram

Example:

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

This makes the defensive architecture visible.

52. Attack Path Evidence

When validating threat paths later in labs or security assessments, gather evidence such as:

• IAM policies

• Tool permissions

• Architecture diagrams

• Authorization configuration

• RAG access controls

• Logs

• Agent configuration

• Model registry permissions

The threat model should eventually be supported by evidence.

53. Assumptions and Unknowns

Attack paths often contain assumptions.

Example:

Assumption:
The AI agent uses a privileged workload identity.

or:

Unknown:
Whether RAG retrieval enforces source ACLs.

Record these clearly.

Unknowns become validation tasks.

54. Threat Path Validation

A threat path may begin as hypothetical.

Security teams can later validate:

Assumption
   ↓
Configuration Review
   ↓
Lab / Authorized Test
   ↓
Confirmed or Rejected

This is where threat modeling connects to security testing.

55. Attack Path to Security Test Case

Example threat path:

Normal User
    ↓
AI Agent
    ↓
Privileged Cloud Action

Create a test case:

Verify that a user without cloud administrative permissions cannot cause the AI agent to perform an administrative cloud action.

This creates direct traceability between:

Threat Model
    ↓
Security Requirement
    ↓
Security Test

56. Attack Path to Detection Requirement

Threat:

RAG data collection through repeated queries.

Detection requirement:

Alert when a user retrieves an unusually high volume of sensitive documents through the AI assistant.

Again:

Threat
   ↓
Detection Requirement
   ↓
SIEM / Monitoring

57. Attack Path to Incident Runbook

Threat:

Malicious RAG document influences agent activity.

Runbook should define:

• Identify affected document

• Identify ingestion event

• Identify retrieval events

• Identify agent actions

• Disable agent if necessary

• Remove malicious knowledge

• Rebuild index

• Assess business impact

Threat modeling therefore supports operational readiness.

58. Prioritize Paths to Crown Jewels

Focus especially on paths leading to:

• Restricted data

• Production systems

• Administrative identities

• Model registries

• Credentials

• Financial processes

Example:

User
 ↓
Agent
 ↓
Admin Identity
 ↓
Production

should receive much more attention than:

User
 ↓
AI
 ↓
Public FAQ

59. Minimize Attack Path Length

Where possible, reduce the number of ways low-trust inputs can reach high-impact assets.

Risky:

Internet Content
      ↓
LLM
      ↓
Agent
      ↓
Admin Tool
      ↓
Production

Safer:

Internet Content
      ↓
Read-Only Analysis Agent

Capability reduction can eliminate entire attack paths.

60. Threat Modeling as Architecture Simplification

One of the most valuable outcomes of threat modeling is discovering:

We do not need this connection at all.

Removing an unnecessary tool, permission or integration may be stronger than adding additional security controls around it.

61. Attack Path Review Questions

For every significant path ask:

Who Starts the Attack?

What Do They Already Control?

What Is the First Reachable Surface?

Which Trust Boundary Is Crossed?

Which Weakness Enables Progress?

Does Privilege Increase?

Which Sensitive Asset Is Reached?

What Is the Business Impact?

Where Can We Break the Path?

How Would We Detect Progress?

How Would We Contain It?

62. Common Attack Path Mistakes

Listing Only Vulnerabilities

Attack paths should show how weaknesses connect.

Starting With the Framework

Start with the actual architecture and business scenario.

Ignoring Preconditions

Realistic attack paths require realistic starting assumptions.

Ignoring Identity

Many AI attack paths depend heavily on human and workload identities.

Stopping at the LLM

The highest impact may occur several systems later.

Ignoring Business Impact

Explain why the technical path matters.

Creating Only One Path

Attackers may have multiple routes to the same asset.

Ignoring Detection

A useful threat path should generate monitoring requirements.

63. Real-World AI Security Engineer Workflow

At this stage, your threat modeling workflow becomes:

Understand Business Context
        ↓
Map Architecture
        ↓
Identify Assets
        ↓
Map Data Flows
        ↓
Identify Trust Boundaries
        ↓
Identify Threat Actors
        ↓
Map Attack Surfaces
        ↓
Apply STRIDE
        ↓
Apply OWASP GenAI
        ↓
Map MITRE ATLAS
        ↓
Threat Model RAG
        ↓
Threat Model AI Agents
        ↓
Build Abuse Cases
        ↓
Build Attack Paths
        ↓
Identify Control Breakpoints
        ↓
Define Detection & Response

This is now a mature threat modeling process.

64. Attack Path Mindset

Whenever you identify a threat, do not stop at:

What could go wrong?

Continue asking:

What Happens First?
        ↓
What Happens Next?
        ↓
What Must Already Be True?
        ↓
Which Boundary Fails?
        ↓
Does Privilege Increase?
        ↓
What Asset Becomes Reachable?
        ↓
What Happens After That?
        ↓
What Is the Final Business Impact?

This turns a threat list into a realistic security model.

65. Knowledge Check

Question 1

What is an attack path?

Question 2

What is an abuse case?

Question 3

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

Question 4

Why should attack path preconditions be documented?

Question 5

What is backward attack-path analysis?

Question 6

How can RAG poisoning become an AI agent attack?

Question 7

How can a compromised employee identity lead to AI privilege escalation?

Question 8

Why is agent credential theft different from prompt manipulation?

Question 9

What is the difference between collection and exfiltration?

Question 10

What is a choke point?

Question 11

Why can a single attack path involve multiple STRIDE categories?

Question 12

How do attack paths help create security test cases?

Question 13

How can attack paths create detection requirements?

Question 14

Why should threat modeling sometimes result in removing an unnecessary capability?

Key Takeaways

Individual threats become much more valuable when connected into realistic attack paths.

A strong attack path explains:

Threat Actor
      ↓
Starting Position
      ↓
Entry Point
      ↓
Attack Surface
      ↓
Trust Boundary
      ↓
Security Weakness
      ↓
Privilege / Capability
      ↓
Target Asset
      ↓
Business Impact

Attack paths help security teams answer:

How could this actually happen?

They also help defenders determine:

Where Can We Prevent It?
        ↓
Where Can We Detect It?
        ↓
How Can We Contain It?

The most important principle is:

Do not evaluate AI weaknesses only in isolation. The real risk often comes from how multiple weaknesses, identities, permissions and integrations connect.

A moderate prompt-manipulation issue combined with a highly privileged agent may create critical risk.

A serious-looking model weakness connected only to public information may have much lower business impact.

Architecture determines the path.

The path determines the impact.

What’s Next?

➡️ 12 — AI Threat Prioritization and Risk Assessment

You now have a collection of:

• Threat scenarios

• Abuse cases

• Attack paths

• Framework mappings

• Target assets

• Potential business impacts

But not every threat can or should be treated with the same priority.

The next lesson focuses on determining:

Which AI threats matter most and what should the organization fix first?

You will learn how to evaluate:

• Threat likelihood

• Business impact

• Asset criticality

• Exposure

• Attack complexity

• Required attacker access

• Existing security controls

• Agent privilege

• Blast radius

• Detectability

• Residual risk

You will also learn how to create:

• AI risk ratings

• Risk matrices

• Prioritized threat registers

• Remediation priorities

• Risk acceptance decisions

The goal is to move from:

“I can explain how an AI attack could happen.”

to:

“I can determine which attack paths create the greatest enterprise risk and where security investment should be prioritized.”

➡️ Next: 12 — AI Threat Prioritization and Risk Assessment