07 OWASP GenAI Threat Modeling

STRIDE gives us a strong architecture-focused way to categorize threats.

Now we need to go one step further and ask:

What threats are especially relevant to Generative AI and LLM-enabled applications?

That is where OWASP GenAI security guidance becomes useful.

OWASP provides security guidance focused on modern Generative AI and Large Language Model applications.

For an AI Security Engineer, this guidance helps translate general architecture concerns into practical AI-specific threat scenarios involving:

• Prompts
• Model behavior
• RAG
• Embeddings
• Vector databases
• AI agents
• Model supply chains
• Sensitive information
• Unsafe output
• Resource consumption

This lesson focuses on how to use OWASP during threat modeling, not simply memorizing a list of risks.

Learning Objectives

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

• Explain how OWASP GenAI guidance supports threat modeling.
• Understand why OWASP and STRIDE complement each other.
• Identify AI-specific risks across LLM applications.
• Threat model prompt injection scenarios.
• Analyze sensitive information disclosure risks.
• Identify model and software supply-chain threats.
• Analyze data and model poisoning.
• Identify improper output handling.
• Understand excessive agency.
• Identify system prompt exposure risks.
• Understand vector and embedding security concerns.
• Analyze misinformation risks.
• Understand resource-consumption threats.
• Map OWASP risks to assets and trust boundaries.
• Convert OWASP categories into realistic threat scenarios.
• Build an OWASP AI Threat Register.

1. Why Use OWASP for AI Threat Modeling?

Traditional security frameworks remain important.

An AI application can still suffer from:

• Broken authentication
• Weak authorization
• Insecure APIs
• Cloud misconfiguration
• Credential theft
• Vulnerable dependencies

However, AI applications introduce different security behaviors.

For example:

User
 ↓
Natural Language Prompt
 ↓
LLM
 ↓
Generated Output

The input is not simply a structured parameter.

It may contain instructions that influence model behavior.

Now add RAG:

User
 ↓
Application
 ↓
RAG
 ↓
Retrieved Document
 ↓
LLM Context

Now documents can also influence the model.

Add an agent:

LLM
 ↓
AI Agent
 ↓
Tool
 ↓
Enterprise System

Now AI-generated behavior may cause real actions.

OWASP GenAI guidance helps security teams reason about these AI-specific attack surfaces.

2. OWASP Is Not a Replacement for Architecture Analysis

Do not begin threat modeling by selecting an OWASP category.

Start with:

Business Context
      ↓
Architecture
      ↓
Assets
      ↓
Data Flows
      ↓
Trust Boundaries
      ↓
Threat Actors
      ↓
Attack Surfaces

Then use OWASP guidance to ask:

Which AI-specific risks apply to this architecture?

This keeps the threat model grounded in the actual system.

3. OWASP + STRIDE

A useful way to think about the relationship is:

STRIDE
   ↓
What Type of Security Failure Is This?

OWASP GenAI
   ↓
What AI-Specific Risk Pattern Is This?

Example:

Threat:
Prompt manipulation causes AI agent to expose restricted data.

STRIDE may classify part of this as:

Information Disclosure

OWASP may help identify the AI-specific risk pattern involving:

Prompt Injection

Both descriptions are useful.

4. Frameworks Should Support the Threat Model

Frameworks should not become the threat model itself.

Avoid:

OWASP Risk Identified:
Prompt Injection

Instead create:

Threat Actor:
Compromised Employee

Attack Surface:
Internal AI Assistant

Threat:
Manipulated instructions influence the LLM.

Attack Path:
Employee → Prompt → LLM → Agent → Data Tool

Target Asset:
Restricted Customer Records

Impact:
Unauthorized information disclosure

Then map the scenario to the relevant OWASP guidance.

That is professional threat modeling.

5. Keep OWASP Guidance Current

Generative AI security evolves quickly.

OWASP categories, names and guidance may change over time.

Therefore:

Always validate the current official OWASP GenAI guidance when conducting a real security assessment.

Do not rely only on memorized identifiers.

The valuable skill is:

Identify Scenario
      ↓
Understand Risk
      ↓
Validate Current Guidance
      ↓
Map Relevant Category
      ↓
Recommend Controls

6. Prompt Injection

Prompt injection is one of the most important risks in LLM-enabled applications.

At a high level:

Untrusted content attempts to influence the model’s instructions or behavior.

A simple flow:

Trusted Instructions
       +
Untrusted Input
       ↓
      LLM
       ↓
Unexpected Behavior

The core problem is that the model processes instructions and data through the same natural-language context.

7. Direct Prompt Injection

A direct prompt injection comes from the user interacting with the AI.

Example:

User
 ↓
Manipulated Prompt
 ↓
LLM

The attacker may attempt to:

• Override instructions

• Alter expected behavior

• Bypass application constraints

• Cause information disclosure

• Influence tool usage

The real risk depends on what the application allows the model to access or influence.

8. Prompt Injection Risk Is Architecture-Dependent

Consider two systems.

System A

User
 ↓
LLM
 ↓
Generates Joke

Impact of manipulation may be low.

System B

User
 ↓
LLM
 ↓
AI Agent
 ↓
Production Cloud API

The same ability to influence model behavior may have much higher impact.

Therefore:

Prompt injection severity depends heavily on downstream capability.

9. Prompt Injection Threat Scenario

Example:

Threat Actor:
Compromised Employee

Entry Point:
Chat Interface

Attack:
Manipulated Prompt

Target:
AI Cloud Agent

Weakness:
Agent trusts model-generated action requests.

Impact:
Unauthorized cloud action

This is much stronger than simply writing:

Prompt injection exists.

10. Indirect Prompt Injection

Indirect prompt injection occurs when malicious instructions enter through content the model processes rather than directly from the user.

Example:

Attacker
 ↓
Malicious Document
 ↓
RAG
 ↓
LLM Context

or:

Attacker
 ↓
Website
 ↓
Browsing Agent
 ↓
LLM Context

or:

Attacker
 ↓
Email
 ↓
AI Assistant

The user may never intentionally submit malicious instructions.

11. Why Indirect Injection Is Important

Modern AI applications consume information from many sources:

Documents
Email
Websites
Databases
Support Tickets
Code
APIs

This means an attacker can potentially influence the AI system by controlling content, not the AI application itself.

Threat modeling must therefore ask:

Who controls the content the AI reads?

12. Prompt Injection Controls

No single control completely solves prompt injection.

Defense should focus on limiting impact.

Potential controls include:

• Strong authorization

• Separation of untrusted content

• Restricted agent tools

• Least privilege

• Output validation

• Policy enforcement

• Human approval for high-impact actions

• Monitoring

• Data access restrictions

A key principle is:

Do not rely on prompt instructions alone to enforce critical security boundaries.

13. Sensitive Information Disclosure

LLM applications may expose sensitive information through:

• Responses

• RAG retrieval

• Conversation history

• Logs

• Errors

• Tool results

Potential sensitive assets include:

Customer Data
Employee Data
Source Code
Security Architecture
Credentials
Internal Documents

14. RAG Information Disclosure

Consider:

Employee
 ↓
RAG Search
 ↓
Vector Database
 ↓
Confidential Documents

If retrieval does not enforce source-level authorization:

Normal Employee
      ↓
Restricted HR Document

This becomes a data disclosure risk.

15. Cross-User Information Disclosure

A multi-user AI application should isolate data between users.

Example:

User A
 ↓
Conversation A

must not become:

User B
 ↓
Conversation A

Potential causes include:

• Session problems

• Caching

• Shared context

• Incorrect retrieval filtering

16. Sensitive Data in Prompts

Users may paste sensitive information into AI systems.

Examples:

• Credentials

• Customer records

• Security logs

• Incident evidence

• Source code

Threat modeling should therefore include:

User Prompt
     ↓
Application
     ↓
LLM Provider
     ↓
Logs / Storage

Ask where the information travels and where it is retained.

17. Information Disclosure Controls

Potential controls include:

• Data classification

• Data minimization

• User-level authorization

• Retrieval filtering

• Output validation

• Sensitive-data policies

• Log sanitization

• Provider governance

• Encryption

18. Supply-Chain Risks

AI systems depend on many external components:

Models
Datasets
Python Packages
Containers
Plugins
APIs
AI Providers

Each represents a trust dependency.

An attacker may compromise one of these components before it reaches your environment.

19. Model Supply Chain

Example:

External Model Repository
        ↓
Downloaded Model
        ↓
Internal AI Platform
        ↓
Production

Questions include:

• Is the model source known?

• Is provenance available?

• Is integrity validated?

• Is deployment approved?

• Can unauthorized models be introduced?

20. Software Supply Chain

AI systems often rely heavily on open-source software.

Example:

Public Package
      ↓
AI Application
      ↓
Production

A malicious dependency could:

• Execute code

• Steal credentials

• Exfiltrate data

• Modify AI behavior

Traditional dependency security remains critical.

21. Container Supply Chain

Example:

Container Registry
      ↓
AI Container Image
      ↓
Production Workload

Potential risks include:

• Malicious images

• Vulnerable dependencies

• Embedded secrets

• Untrusted provenance

22. Supply-Chain Controls

Potential controls include:

• Approved repositories

• Provenance verification

• Dependency inventory

• Vulnerability scanning

• Container scanning

• Artifact signing

• Deployment approval

• Software Bill of Materials where appropriate

• Model validation

23. Data and Model Poisoning

Poisoning attacks attempt to influence AI behavior by manipulating:

• Training data

• Fine-tuning data

• RAG data

• Model artifacts

The security objective primarily affected is:

Integrity

24. RAG Poisoning

Consider:

Malicious Contributor
       ↓
Enterprise Document
       ↓
RAG Ingestion
       ↓
Vector Database
       ↓
LLM

If malicious or misleading information enters trusted knowledge sources, users may receive manipulated responses.

25. Training Data Poisoning

Example:

Attacker
 ↓
Manipulated Training Data
 ↓
Model Training
 ↓
Altered Model

Potential effects include:

• Incorrect behavior

• Backdoors

• Reduced reliability

• Biased outputs

26. Model Poisoning

An attacker may modify the model itself.

Approved Model
      ↓
Unauthorized Modification
      ↓
Modified Model
      ↓
Production

Threat modeling should include the model registry and deployment pipeline.

27. Poisoning Controls

Potential controls include:

• Data provenance

• Restricted ingestion

• Dataset review

• Integrity validation

• Model approval

• Version control

• Change logging

• Separation of duties

• Monitoring

28. Improper Output Handling

One of the most important architectural lessons in LLM security is:

Model output should generally be treated as untrusted input to downstream components.

Consider:

LLM
 ↓
Generated Output
 ↓
Application

If the application blindly trusts the output, security problems may occur.

29. Example — Generated SQL

Consider:

LLM
 ↓
Generated SQL
 ↓
Database

If SQL is executed without validation, AI-generated output can directly influence the database.

A safer pattern is:

LLM Output
    ↓
Validation
    ↓
Policy Enforcement
    ↓
Approved Query
    ↓
Database

30. Example — Generated Shell Command

A risky design:

LLM
 ↓
Shell Command
 ↓
Automatic Execution

A stronger architecture may require:

LLM
 ↓
Proposed Command
 ↓
Validation
 ↓
Allowlisted Operation
 ↓
Human Approval
 ↓
Execution

31. Output Handling Threats

Model output may contain:

• Code

• URLs

• HTML

• SQL

• Commands

• API parameters

• Business decisions

Threat modeling must ask:

What happens to the output after generation?

The downstream system often determines the actual security impact.

32. Excessive Agency

AI agents can take actions.

The more capabilities an AI agent has, the larger the potential blast radius.

Example:

AI Agent
   ├── Read Email
   ├── Send Email
   ├── Modify Tickets
   ├── Access Database
   └── Modify Cloud

Each capability should be justified.

33. Excessive Permission Example

Suppose the business requirement is:

Read cloud security findings.

But the agent has:

AdministratorAccess

This creates unnecessary risk.

A better permission model would allow only the required operations.

34. Agent Tool Scope

Do not only restrict IAM permissions.

Also restrict which tools are available.

Instead of:

AI Agent
   ├── Read
   ├── Write
   ├── Delete
   └── Admin

prefer:

AI Agent
   └── Read Approved Security Data

where the business use case requires only reading.

35. User vs Agent Authorization

Consider:

Normal Employee
      ↓
AI Agent
      ↓
High-Privilege Tool

The agent may have permission to perform an operation that the user does not.

Therefore authorization should consider:

User Authority
      +
Agent Authority
      +
Target Resource

36. Human Approval

High-impact actions may require approval.

Example:

AI Agent
   ↓
Proposed Production Change
   ↓
Human Approval
   ↓
Execution

Human approval should not be required for every low-risk action, but can be valuable for:

• Deleting data

• Changing IAM

• Modifying production

• Financial actions

• Sending sensitive communications

37. System Prompt Leakage

System prompts may contain internal instructions and implementation details.

Threat modeling should consider whether system prompts expose:

• Sensitive business information

• Internal configuration

• Security assumptions

• Operational rules

However:

System prompt confidentiality should not be relied upon as the main security control.

Assume important security controls remain effective even if application instructions become known.

38. Secrets Must Never Depend on Prompt Secrecy

Do not place:

• Passwords

• API keys

• Private keys

• Tokens

inside system prompts.

If a secret is required, use an appropriate secret management mechanism.

39. Vector and Embedding Risks

RAG systems introduce:

• Vector databases

• Embeddings

• Metadata

• Retrieval indexes

Potential threats include:

• Unauthorized vector queries

• Unauthorized writes

• Poisoning

• Metadata leakage

• Cross-user retrieval

• Weak data segmentation

40. Vector Database Authorization

Consider:

User
 ↓
RAG Service
 ↓
Vector Database

The service should not automatically expose every matching record.

A stronger design:

User Identity
      ↓
Authorization
      ↓
Allowed Data Scope
      ↓
Vector Search

41. Embedding Sensitivity

Embeddings should not automatically be classified as harmless.

Their sensitivity depends on:

• Original information

• Associated metadata

• Implementation

• Ability to query or reconstruct meaningful patterns

Protect them according to the risk of the underlying data.

42. Misinformation

AI systems may generate inaccurate or misleading information.

This may be caused by:

• Model limitations

• Poor context

• Poisoned data

• Outdated information

• Manipulated input

The security impact depends on how the information is used.

43. Low-Impact Misinformation

Example:

AI Travel Assistant
 ↓
Incorrect Restaurant Recommendation

Impact may be limited.

44. High-Impact Misinformation

Consider:

AI Security Assistant
 ↓
Incorrect Incident Response Guidance
 ↓
Production Action

or:

AI Financial Assistant
 ↓
Incorrect Decision
 ↓
Financial Impact

The business context determines risk.

45. Misinformation Controls

Possible controls include:

• Source grounding

• Approved knowledge sources

• Human validation for high-impact decisions

• Confidence and uncertainty handling

• Source references

• Data freshness controls

46. Resource and Consumption Risks

AI inference can be expensive.

Attackers may exploit:

• Large prompts

• Repeated requests

• High output limits

• Agent loops

• Expensive tool chains

Potential consequences include:

• Resource exhaustion

• Increased latency

• Service failure

• Excessive API cost

47. Agent Loop Example

Consider:

AI Agent
 ↓
Tool Call
 ↓
LLM
 ↓
Tool Call
 ↓
LLM
 ↓
Tool Call
 ↓
...

Without limits, an unexpected loop may consume significant resources.

48. Resource Controls

Potential controls include:

• Rate limiting

• Token limits

• Request quotas

• Agent execution limits

• Tool-call limits

• Timeouts

• Budget controls

• Cost monitoring

49. Map OWASP Risks to Architecture

Do not create a generic OWASP checklist.

Map relevant risk areas to actual components.

Example:

Component	AI Risk Area
Chat Interface	Prompt Injection
RAG Ingestion	Data Poisoning
Vector DB	Vector / Embedding Security
AI Agent	Excessive Agency
Agent Tool Output	Improper Output Handling
External Model	Supply-Chain Risk
RAG Retrieval	Sensitive Information Disclosure

This makes the framework actionable.

50. Map OWASP Risks to Trust Boundaries

Example:

User
 ↓
=====================
TB-01
=====================
 ↓
LLM

Potential concern:

Direct prompt manipulation

Another:

External Document
       ↓
=====================
TB-04
=====================
       ↓
RAG

Potential concern:

Indirect prompt manipulation / poisoning

Another:

AI Agent
   ↓
=====================
TB-06
=====================
   ↓
Production Tool

Potential concern:

Excessive agency / unsafe output handling

51. Map OWASP Risks to Assets

Example:

Risk:
Sensitive Information Disclosure

Asset:
Customer Data

Another:

Risk:
Data Poisoning

Asset:
Enterprise Knowledge Base

Another:

Risk:
Excessive Agency

Asset:
Production Infrastructure

This helps later risk prioritization.

52. Build an OWASP Threat Register

Create an Obsidian note:

OWASP GenAI Threat Register.md

Use:

ID	AI Risk	Threat Actor	Attack Surface	Trust Boundary	Target Asset	Threat Scenario	Impact	Controls
OW-01	Prompt Injection	Compromised User	Chat Interface	TB-01	AI Agent	Manipulated input influences agent action	High	Authorization, policy enforcement
OW-02	Sensitive Disclosure	Employee	RAG Retrieval	TB-04	HR Data	User retrieves unauthorized HR documents	Critical	Retrieval authorization
OW-03	Data Poisoning	Malicious Contributor	RAG Ingestion	TB-05	Knowledge Base	Malicious document influences AI responses	High	Source governance
OW-04	Excessive Agency	User	AI Agent	TB-06	Production Cloud	Agent performs action beyond user authority	Critical	Least privilege, approval

Use the terminology from the current official OWASP guidance during real assessments.

53. Build Better AI Threat Scenarios

Instead of:

Excessive Agency exists.

write:

A compromised employee account may instruct the cloud operations agent to modify a production resource. Because the agent operates using an overprivileged workload identity and does not independently validate the initiating user’s permissions, the attacker may perform actions beyond the employee’s normal authorization.

This contains:

Threat Actor
      +
Entry Point
      +
AI Risk
      +
Weakness
      +
Target Asset
      +
Business Impact

54. Threat Scenario Template

Use:

# OW-XX — Threat Name

## OWASP Mapping

## Threat Actor

## Business Scenario

## Target Component

## Attack Surface

## Trust Boundary

## Target Asset

## Preconditions

## Attack Scenario

## Existing Controls

## Security Gap

## Potential Impact

## Detection Opportunities

## Recommended Controls

## Residual Risk

55. Example — Indirect Prompt Injection Through RAG

# OW-05 — Malicious RAG Document Influences AI Agent

## OWASP Mapping

Prompt Injection / applicable current OWASP GenAI guidance

## Threat Actor

Malicious document contributor

## Business Scenario

An enterprise AI assistant retrieves internal documentation and can create support tickets using an AI agent.

## Target Component

RAG pipeline and AI agent

## Attack Surface

Enterprise document repository

## Trust Boundary

Document Repository → RAG → LLM

## Target Asset

Enterprise workflow and internal information

## Preconditions

The attacker can contribute content to a source indexed by the RAG system.

## Attack Scenario

The attacker inserts malicious natural-language instructions into an approved document. The document is ingested by the RAG pipeline and later retrieved into the model context. The instructions influence the AI agent to perform an unintended action.

## Existing Controls

- User authentication
- Basic document repository permissions

## Security Gap

Retrieved content is treated as sufficiently trusted to influence agent behavior, and sensitive actions lack independent policy validation.

## Potential Impact

Unauthorized enterprise actions and possible information disclosure.

## Detection Opportunities

- Unusual agent actions
- Recently modified documents associated with suspicious activity
- Tool invocations inconsistent with user intent

## Recommended Controls

- Restrict document contributors
- Maintain source provenance
- Treat retrieved content as untrusted
- Restrict agent capabilities
- Independently authorize sensitive actions
- Require approval for high-impact actions
- Log retrieval and tool activity

## Residual Risk

To be assessed after control validation.

56. Prevent, Detect and Respond

For each AI-specific threat, consider all three.

Example:

Prompt Injection

Prevent

• Restrict downstream authority

• Apply authorization

• Isolate untrusted context

Detect

• Monitor suspicious interaction patterns

• Monitor unusual tool usage

Respond

• Disable agent

• Revoke session

• Investigate affected actions

57. OWASP Threat Modeling Checklist

When reviewing an AI system, ask:

Prompt and Context

• Can untrusted instructions influence the model?

• Can external content enter the context?

• Can retrieved documents influence behavior?

Sensitive Information

• What confidential data can the AI access?

• Can another user retrieve it?

• Is data sent externally?

Supply Chain

• Where do models come from?

• Where do dependencies come from?

• Are containers trusted?

• Is provenance validated?

Data Integrity

• Who can modify RAG content?

• Who can modify training data?

• Can the vector database be written directly?

Output Handling

• What happens to model output?

• Is it executed?

• Is it rendered?

• Is it passed to another system?

Agent Capability

• Which tools exist?

• What permissions exist?

• Can actions affect production?

• Is user authorization enforced?

System Instructions

• Do prompts contain sensitive information?

• Is critical security dependent on prompt secrecy?

Vector / Embedding Security

• Who can query?

• Who can write?

• Is retrieval authorized?

Misinformation

• What happens if the answer is incorrect?

• Are high-impact decisions independently validated?

Resource Consumption

• Can users create expensive workloads?

• Are agent loops limited?

• Are budgets monitored?

58. Common OWASP Threat Modeling Mistakes

Treating the OWASP List as the Threat Model

Framework categories are only inputs.

The threat model must describe the actual architecture and scenario.

Mapping Every Category

Not every risk applies to every system.

Map what is relevant.

Ignoring Traditional Security

OWASP GenAI guidance does not replace:

• IAM

• Cloud security

• API security

• Network security

• Application security

Treating Prompt Filtering as the Main Defense

The stronger strategy is limiting downstream authority and enforcing trusted security boundaries.

Ignoring Business Impact

The same AI weakness can have very different consequences depending on the system.

Ignoring AI Agents

Modern AI threat models must carefully examine agent capabilities and permissions.

59. Real-World AI Security Engineer Workflow

At this stage, your threat modeling workflow becomes:

Understand Architecture
        ↓
Identify Assets
        ↓
Map Data Flows
        ↓
Identify Trust Boundaries
        ↓
Identify Threat Actors
        ↓
Map Attack Surfaces
        ↓
Apply STRIDE
        ↓
Apply OWASP GenAI Guidance
        ↓
Create AI-Specific Threat Scenarios
        ↓
Map Controls

This creates a much richer security analysis.

60. OWASP GenAI Threat Modeling Mindset

Whenever you review an AI system ask:

What Untrusted Content Can Enter?
        ↓
What Does the Model Trust?
        ↓
What Sensitive Data Can It Access?
        ↓
What External Dependencies Exist?
        ↓
What Data or Models Can Be Modified?
        ↓
What Happens to Model Output?
        ↓
What Actions Can AI Perform?
        ↓
What Privileges Exist Behind Those Actions?
        ↓
Can AI Produce High-Impact Incorrect Information?
        ↓
Can Resources or Costs Be Abused?

61. Knowledge Check

Question 1

Why should OWASP GenAI guidance be used together with architecture analysis?

Question 2

How does STRIDE differ from OWASP GenAI threat guidance?

Question 3

What is direct prompt injection?

Question 4

What is indirect prompt injection?

Question 5

Why does RAG increase indirect prompt injection risk?

Question 6

How can sensitive information be exposed through RAG?

Question 7

Why do models and dependencies create supply-chain risk?

Question 8

What is data poisoning?

Question 9

Why should model output be treated as untrusted?

Question 10

What does excessive agency mean in practice?

Question 11

Why should system prompt secrecy not be treated as a primary security control?

Question 12

How can resource consumption create business risk?

Question 13

Why should OWASP categories be converted into realistic threat scenarios?

Question 14

Why should the current official OWASP guidance be validated during real assessments?

Key Takeaways

OWASP GenAI guidance helps AI Security Engineers recognize security risks that arise specifically from modern Generative AI architectures.

The most important areas include:

Untrusted Prompts and Context
        +
Sensitive Data
        +
AI Supply Chains
        +
Data and Model Integrity
        +
Model Output
        +
AI Agent Capability
        +
RAG and Vector Security
        +
Misinformation
        +
Resource Consumption

The key principle is:

Do not simply map an architecture to an OWASP category. Build the actual attack scenario and then use OWASP to strengthen and validate your analysis.

A strong AI threat scenario should connect:

Threat Actor
      ↓
Attack Surface
      ↓
Trust Boundary
      ↓
AI-Specific Risk
      ↓
Target Asset
      ↓
Business Impact
      ↓
Security Control

STRIDE gives you the security categories.

OWASP helps you understand AI-specific application risks.

The next step is to understand how real adversaries may behave against AI systems.

What’s Next?

➡️ 08 — MITRE ATLAS and AI Adversary Techniques

You now understand how to identify AI-specific risks using OWASP GenAI security guidance.

The next lesson changes perspective.

Instead of asking:

What weakness exists in the AI application?

we will ask:

How might an adversary actually operate against this AI environment?

You will learn how to use MITRE ATLAS to understand:

• AI-focused adversary behavior

• Tactics

• Techniques

• Attack objectives

• Model and data attacks

• AI system discovery

• Credential and access abuse

• AI supply-chain attacks

• Defense evasion

• Impact

• Detection opportunities

You will also learn how to connect:

OWASP Risks → MITRE ATLAS Techniques → Enterprise Attack Paths

The goal is to move from:

“I understand the security weakness.”

to:

“I understand how an adversary may exploit AI systems across an attack lifecycle.”

➡️ Next: 08 — MITRE ATLAS and AI Adversary Techniques