08 MITRE ATLAS

Understanding AI security risks is important.

Understanding how an adversary may actually attack an AI system is even more valuable.

In the previous lesson, we used the OWASP GenAI LLM Top 10 to understand common security risks affecting Large Language Model applications.

Now we change perspective.

Instead of asking:

What security weaknesses may exist?

we begin asking:

How might an attacker move through the environment and achieve their objective?

This is where MITRE ATLAS becomes useful.

MITRE ATLAS stands for:

Adversarial Threat Landscape for Artificial-Intelligence Systems

ATLAS provides a structured way to understand adversarial behaviors against AI-enabled systems.

For an AI Security Engineer, ATLAS can help with:

• Threat modeling
• Security architecture reviews
• AI red teaming
• Attack-path analysis
• Detection engineering
• Incident investigation
• Defensive control design
• Security assessments

The objective of this lesson is not to memorize every ATLAS technique.

Your goal is to understand how to use ATLAS to think like both an attacker and a defender.

Learning Objectives

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

• Explain what MITRE ATLAS is.
• Understand the difference between tactics and techniques.
• Understand how ATLAS relates to MITRE ATT&CK.
• Recognize major adversary behaviors affecting AI systems.
• Understand AI reconnaissance and discovery.
• Understand access to AI environments.
• Recognize model, data and supply-chain attacks.
• Understand prompt and inference-related attacks.
• Recognize model extraction and data exfiltration scenarios.
• Understand attacks against AI agents and supporting infrastructure.
• Map adversary behavior to an AI architecture.
• Use ATLAS during threat modeling.
• Use ATLAS with OWASP.
• Build defensive controls around attack paths.

What Is MITRE ATLAS?

MITRE is a knowledge base focused on adversarial threats against systems using Artificial Intelligence and Machine Learning. MITRE ATLAS currently describes, ATLAS is a living knowledge base and changes over time, as a knowledge base of adversary tactics and techniques against AI-enabled systems, built from real-world observations and realistic demonstrations. (MITRE ATLAS)

It helps describe:

What the attacker wants to achieve
        ↓
What technique they may use
        ↓
Which AI component they may target
        ↓
What security impact may result

This gives security teams a common language for discussing AI adversary behavior.

Why Do We Need ATLAS?

Consider a simple AI architecture:

User
 │
 ▼
AI Application
 │
 ├── LLM
 ├── RAG
 └── Agent
       │
       └── Cloud Tools

You might already identify risks such as:

• Prompt injection

• Sensitive information disclosure

• Excessive agency

But a real attacker may follow an attack path.

For example:

Discover AI Application
        ↓
Understand Model Behavior
        ↓
Manipulate Input
        ↓
Influence Agent
        ↓
Abuse Tool Permission
        ↓
Access Enterprise Resource

ATLAS helps us think about this complete adversarial sequence.

MITRE ATT&CK vs MITRE ATLAS

MITRE ATT&CK is widely used in cybersecurity to describe adversary behavior against enterprise systems.

Conceptually:

MITRE ATT&CK
      ↓
Traditional Cyber Adversary Behavior

Examples may involve:

• Credential access

• Execution

• Persistence

• Discovery

• Lateral movement

• Exfiltration

MITRE ATLAS extends threat-informed thinking into AI-enabled systems.

MITRE ATLAS
      ↓
Adversary Behavior Against AI Systems

AI environments frequently require both perspectives.

For example:

Phishing
   ↓
Credential Theft
   ↓
Cloud Account Access
   ↓
AI Platform Access
   ↓
Model or Data Manipulation

The first stages may resemble traditional ATT&CK behavior.

The later stages may involve AI-specific ATLAS techniques.

Therefore:

Enterprise AI attacks may combine traditional cyber techniques with AI-specific adversarial techniques.

Tactics vs Techniques

Understanding this distinction is important.

Tactic

A tactic represents the attacker’s objective.

Think:

Why is the attacker doing this?

Examples might include goals such as:

Gather Information

Gain Access

Learn About the AI System

Manipulate the AI System

Steal Information

Create Impact

Technique

A technique describes how the attacker attempts to achieve that objective.

Think:

How are they doing it?

For example:

Goal:
Understand the AI system

Possible Technique:
Query the model repeatedly

Another:

Goal:
Manipulate model behavior

Possible Technique:
Poison training or retrieval data

The general relationship is:

TACTIC
Why?

   ↓

TECHNIQUE
How?

   ↓

PROCEDURE
What did the attacker actually do?

Think in Attack Paths

One of the most valuable ways to use ATLAS is to build an attack path.

For example:

Reconnaissance
      ↓
Discover AI Application
      ↓
Identify RAG Capability
      ↓
Manipulate Retrieved Content
      ↓
Influence LLM
      ↓
Trigger Agent Action
      ↓
Enterprise Impact

This helps move security discussions beyond isolated vulnerabilities.

Enterprise AI Attack Lifecycle

A simplified adversary journey may look like:

Reconnaissance
      ↓
Resource Preparation
      ↓
Initial Access
      ↓
AI System Discovery
      ↓
AI System Manipulation
      ↓
Privilege / Capability Abuse
      ↓
Persistence or Evasion
      ↓
Data Collection
      ↓
Exfiltration
      ↓
Impact

Not every attack follows every stage.

Attack paths depend on the architecture and attacker objective.

1 — Reconnaissance

Attackers often begin by gathering information.

They may try to understand:

• Which AI applications exist

• Which models are used

• Which vendors are used

• What APIs are exposed

• Whether RAG exists

• Whether agents exist

• What tools agents can access

Possible public information sources may include:

• Documentation

• Job postings

• Public repositories

• Application responses

• Error messages

• API documentation

Example

An attacker discovers that an organization operates:

Internal Security Assistant
      +
Cloud AI Platform
      +
RAG
      +
Security Agent

This information may help the attacker plan later activity.

Defensive Perspective

Reduce unnecessary exposure of:

• Internal architecture

• Model details

• API endpoints

• Administrative interfaces

• Sensitive error information

Reconnaissance itself may not always be preventable.

The objective is to avoid giving attackers unnecessary information.

2 — AI System Discovery

Once an attacker has some access, they may try to understand how the AI system behaves.

They may investigate:

Which model is used?

What capabilities exist?

Is RAG enabled?

Can the system call tools?

What restrictions exist?

What data can the application access?

Example:

Attacker
   ↓
Queries AI Application
   ↓
Observes Responses
   ↓
Learns System Capabilities

This is similar to discovery in traditional cybersecurity.

3 — Model Discovery

Attackers may attempt to identify:

• Model family

• Model provider

• Model behavior

• Context limitations

• Safety controls

• Supported functionality

Why does this matter?

Different models and architectures may behave differently.

Understanding the target helps attackers refine later techniques.

Defensive Perspective

Avoid unnecessary disclosure of:

• Exact internal model configuration

• Sensitive system metadata

• Internal prompts

• Security architecture

But remember:

Security through obscurity alone is not sufficient.

Even if attackers know the architecture, technical controls should still protect the system.

4 — Prompt-Based Manipulation

An attacker may attempt to influence an LLM using crafted input.

Conceptually:

Attacker Input
     ↓
LLM
     ↓
Unexpected Behavior

This becomes more significant when the AI system connects to:

• Sensitive data

• RAG

• Tools

• AI agents

Attack Path

Prompt
  ↓
Manipulate Model
  ↓
Bypass Intended Behavior
  ↓
Access Sensitive Capability

Prompt manipulation may represent one stage of a larger attack rather than the complete attack itself.

5 — Indirect Manipulation

The attacker may not interact directly with the AI system.

Instead, they manipulate content that the AI later consumes.

Example:

Attacker
   ↓
Malicious Web Page
   ↓
AI Reads Web Page
   ↓
Model Processes Instructions

or:

Malicious Document
      ↓
RAG
      ↓
LLM

This is particularly important for:

• Browsing agents

• RAG

• Email assistants

• Document-processing systems

6 — Data Poisoning

Attackers may attempt to influence data used by AI systems.

Targets may include:

• Training data

• Fine-tuning data

• RAG documents

• Evaluation datasets

• Agent memory

Conceptually:

Trusted Data
     +
Malicious Data
     ↓
AI Pipeline
     ↓
Modified Behavior

Example

Imagine an AI security assistant retrieves internal runbooks.

An attacker manages to modify a runbook:

Security Runbook
      ↓
Malicious Content Added
      ↓
RAG Index
      ↓
AI Retrieves It
      ↓
Incorrect Security Recommendation

The attacker compromised the knowledge source, not necessarily the model.

7 — Model Poisoning or Manipulation

Attackers may target the model itself.

Possible scenarios include:

• Unauthorized fine-tuning

• Model replacement

• Backdoored model

• Tampered weights

• Modified model configuration

Example:

Model Registry
      ↓
Unauthorized Model Replacement
      ↓
Production Deployment
      ↓
Unexpected Behavior

This demonstrates why model integrity and provenance are important.

8 — ML Supply-Chain Compromise

AI systems depend on extensive software and model supply chains.

Attackers may target:

Model Repository
Python Package
Container Image
ML Framework
Dataset
Development Tool
CI/CD Pipeline

Example:

Compromised AI Package
        ↓
Developer Installs Package
        ↓
AI Development Environment
        ↓
Credentials Stolen
        ↓
Production Compromise

This may resemble traditional supply-chain attacks but occur inside the AI development ecosystem.

9 — Model Repository Compromise

Organizations may obtain models from repositories.

Potential threats include:

• Model replacement

• Malicious artifact upload

• Repository account compromise

• Untrusted model sources

A model repository should therefore be treated as a software supply-chain component.

Defensive Controls

Consider:

• Trusted repositories

• Version tracking

• Integrity validation

• Restricted publishing rights

• Model provenance

• Security review

10 — Credential Access

AI platforms depend heavily on credentials.

Examples include:

LLM API Keys
Cloud Credentials
Database Credentials
Model Repository Tokens
Service Accounts

An attacker may target these through traditional methods.

Example:

Compromised Developer Laptop
        ↓
API Credential Stolen
        ↓
AI Platform Access

This demonstrates why ATLAS does not replace traditional cybersecurity.

11 — AI Agent Credential Abuse

AI agents may use powerful identities.

Example:

AI Agent
   │
   ▼
Cloud Service Account
   │
   ▼
Production Resources

If an attacker manipulates the agent or steals its credentials, they may inherit those permissions.

This is why:

Agent identity is a critical AI security asset.

12 — Model Extraction

An attacker may attempt to reproduce or steal model functionality.

Possible motivations include:

• Intellectual property theft

• Competitive advantage

• Understanding model behavior

• Improving attack techniques

A simplified scenario:

Attacker
   ↓
Repeated Model Queries
   ↓
Collect Responses
   ↓
Approximate Model Behavior

Defensive Controls

Possible controls include:

• Authentication

• Rate limiting

• Usage monitoring

• Query analysis

• Access restrictions

13 — Model Theft

Where model files are accessible, attackers may attempt direct theft.

Example:

Compromised Storage
      ↓
Model File
      ↓
Exfiltration

Models may represent significant organizational intellectual property.

Protect:

• Model registries

• Object storage

• Development environments

• Backups

14 — Training Data Theft

Training data may contain highly sensitive information.

Examples include:

• Customer records

• Research data

• Proprietary datasets

• Source code

• Business information

Attackers may attempt:

Compromise Training Environment
        ↓
Access Dataset
        ↓
Exfiltrate Data

AI Security Engineers must therefore protect both models and data.

15 — Model Inversion and Data Inference

Attackers may attempt to infer information related to the model’s training data or behavior.

Security concerns may include:

• Privacy

• Confidentiality

• Sensitive training information

The specific feasibility and impact depend heavily on the model and use case.

The engineering lesson is:

Sensitive training data can remain a security concern even after training is complete.

16 — Evasion

Attackers may attempt to craft inputs that cause an AI system to make the wrong decision.

This is particularly relevant for classification models.

Example:

Malicious File
     ↓
Modified Input
     ↓
Detection Model
     ↓
Classified as Safe

Potential targets include:

• Malware classifiers

• Fraud systems

• Spam detection

• Image recognition

• Security analytics

17 — Defense Evasion

An attacker may attempt to avoid AI security monitoring or protective mechanisms.

For example:

• Obfuscating malicious input

• Changing attack patterns

• Avoiding detection thresholds

• Blending malicious behavior with normal activity

Defenders should not rely on one detection mechanism.

18 — AI Agent Manipulation

Agents create new attack opportunities.

Consider:

User
 │
 ▼
AI Agent
 │
 ├── Email
 ├── Cloud
 ├── Database
 └── Ticketing

The attacker may attempt to influence:

• Tool selection

• Tool parameters

• Agent planning

• Agent memory

• Agent output

The key security question becomes:

What happens when attacker-controlled input reaches an AI system with real permissions?

19 — Tool Abuse

Suppose an agent has:

Cloud Tool
   ↓
Administrator Access

The attacker may not need to compromise the cloud platform directly.

Instead:

Manipulated Input
      ↓
AI Agent
      ↓
Cloud Tool
      ↓
Unauthorized Action

This is why tool permission design is critical.

20 — Agent Memory Manipulation

Some AI agents retain information across interactions.

Example:

User Interaction
       ↓
Agent Memory
       ↓
Future Decisions

If attacker-controlled content becomes persistent memory, it may influence future behavior.

Security considerations include:

• Who can write memory?

• How long is memory retained?

• Can memory cross users?

• Can users review or remove stored information?

21 — RAG Manipulation

RAG introduces multiple attack paths.

Example:

Attacker
   ↓
Document Source
   ↓
Document Ingestion
   ↓
Vector Database
   ↓
Retriever
   ↓
LLM

Attackers may target:

• Document integrity

• Retrieval logic

• Metadata

• Authorization

• Embeddings

The attack may occur long before a user asks a question.

22 — Vector Database Targeting

An attacker may attempt to access or manipulate the vector store.

Potential impact includes:

• Unauthorized data retrieval

• Cross-tenant access

• Knowledge manipulation

• Metadata exposure

Treat vector databases like sensitive enterprise data stores.

23 — Resource Abuse

AI systems often use expensive resources.

Attackers may attempt to consume:

• GPU

• CPU

• Tokens

• API quota

• Cloud budget

Example:

Automated Requests
      ↓
AI Endpoint
      ↓
Resource Exhaustion
      ↓
Service Degradation

Potential impact includes both:

Availability
+
Financial Cost

24 — Exfiltration

Ultimately, many attacks seek to steal something.

Possible AI assets include:

Training Data
Model Files
System Prompts
Enterprise Documents
Credentials
Conversation Data
Source Code

Attackers may exfiltrate them through:

• Direct network access

• Application responses

• Agent tools

• Cloud storage access

• Compromised credentials

25 — Impact

The final attacker goal may include:

• Data theft

• Model theft

• Business disruption

• Financial loss

• Manipulated AI decisions

• Unauthorized actions

• Reputation damage

Example:

Malicious Document
      ↓
AI Agent Manipulation
      ↓
Unauthorized Cloud Change
      ↓
Production Service Failure

The impact occurred outside the model.

That is why AI threat modeling must include the complete enterprise environment.

Mapping ATLAS to Enterprise Architecture

Consider:

External User
     │
     ▼
AI Application
     │
     ├── LLM
     ├── RAG
     │     └── Enterprise Documents
     │
     └── Agent
           │
           └── Cloud Tools

We can map possible adversarial behaviors.

User Layer

Potential behaviors:

• Reconnaissance

• Capability discovery

• Prompt manipulation

RAG Layer

Potential behaviors:

• Poisoning

• Unauthorized retrieval

• Data manipulation

Model Layer

Potential behaviors:

• Extraction

• Manipulation

• Evasion

Agent Layer

Potential behaviors:

• Tool abuse

• Credential abuse

• Excessive action

Infrastructure Layer

Potential behaviors:

• Credential theft

• Cloud compromise

• Supply-chain compromise

This creates a much more complete threat model.

ATLAS Attack Path Example

Consider an AI assistant connected to cloud infrastructure.

Attacker
   │
   ▼
Discovers Public AI Interface
   │
   ▼
Learns Agent Capability
   │
   ▼
Crafts Manipulative Input
   │
   ▼
Influences Agent
   │
   ▼
Agent Calls Cloud Tool
   │
   ▼
Overprivileged Service Account
   │
   ▼
Cloud Resource Access

Now security teams can analyze each stage.

Defensive Analysis

Stage 1 — Discovery

Control:

• Reduce unnecessary information exposure.

Stage 2 — Model Interaction

Control:

• Input and context controls.

Stage 3 — Agent

Control:

• Agent policy enforcement.

Stage 4 — Tool

Control:

• Tool allowlisting.

Stage 5 — Permission

Control:

• Least privilege.

Stage 6 — Action

Control:

• Human approval for high-risk operations.

Stage 7 — Detection

Control:

• Log and alert on unusual agent actions.

This is threat-informed defense.

ATLAS and Threat Modeling

ATLAS can help generate realistic threat scenarios during design.

Suppose your architecture contains:

Employee
  ↓
AI Assistant
  ↓
RAG
  ↓
Confidential Documents

Instead of simply writing:

Threat:
Data Leak

use adversary thinking:

Threat Actor:
Malicious Employee

Objective:
Access Confidential Information

Entry Point:
AI Assistant

Technique:
Manipulate queries and application behavior

Target:
RAG Retrieval

Weakness:
Missing document-level authorization

Impact:
Confidential data exposure

This is far more actionable.

ATLAS Threat Modeling Workflow

Use:

1. Draw Architecture
       ↓
2. Identify Assets
       ↓
3. Identify Threat Actors
       ↓
4. Identify Attacker Goals
       ↓
5. Review Relevant ATLAS Behaviors
       ↓
6. Build Attack Paths
       ↓
7. Identify Existing Controls
       ↓
8. Identify Detection Opportunities
       ↓
9. Identify Security Gaps
       ↓
10. Prioritize Remediation

This turns ATLAS into an engineering tool.

ATLAS and OWASP Together

OWASP and ATLAS solve related but different problems.

A useful distinction is:

OWASP
"What security weakness exists?"

        +

MITRE ATLAS
"How could an adversary abuse it?"

Together:

OWASP
   ↓
Identify Weakness
   ↓
ATLAS
   ↓
Map Adversary Behavior
   ↓
Attack Path
   ↓
Security Controls

Example: Prompt Injection

OWASP perspective:

Risk:
Prompt Injection

ATLAS perspective:

Threat Actor
    ↓
Discovers AI Capability
    ↓
Crafts Manipulative Input
    ↓
Changes Model Behavior
    ↓
Abuses Connected Tool

Combining them gives much more useful context.

Example: Excessive Agency

OWASP may identify:

Excessive Agency

ATLAS thinking asks:

How does the attacker reach the agent?

How do they influence its decision?

What tool will the agent use?

What credential will the tool use?

What action becomes possible?

Now you have an attack path.

Example: Supply Chain

OWASP identifies:

Supply Chain Risk

ATLAS can help explore:

Attacker
   ↓
Compromised Model / Package
   ↓
Developer Environment
   ↓
Deployment Pipeline
   ↓
Production AI System

This maps the attacker journey.

ATLAS and MITRE ATT&CK Together

AI systems still depend on traditional enterprise infrastructure.

Consider:

Phishing
   ↓
Developer Credential Compromise
   ↓
Cloud Access
   ↓
Model Registry Access
   ↓
Model Modification

The early attack may involve traditional enterprise behavior.

The later attack involves AI-specific assets.

Therefore:

AI Security Engineers should be comfortable combining ATT&CK and ATLAS where appropriate.

ATLAS and Red Teaming

AI red teams can use ATLAS to build realistic test scenarios.

Instead of testing isolated prompts:

Can I make the chatbot say something unusual?

test an attack objective:

Can attacker-controlled content influence
an AI agent in a way that affects an enterprise system?

A realistic red team scenario could involve:

Reconnaissance
      ↓
Discover AI Capability
      ↓
Introduce Malicious Content
      ↓
Influence AI Behavior
      ↓
Attempt Tool Invocation
      ↓
Validate Security Boundary

Always remain within authorized scope.

ATLAS and Detection Engineering

ATLAS is not only useful for offensive testing.

Defenders can ask:

What telemetry would reveal this adversary behavior?

Suppose an attacker repeatedly queries the model to learn its behavior.

Potential telemetry might include:

User Identity
+
High Query Volume
+
Unusual Prompt Patterns
+
Repeated Similar Requests

Another example:

Agent Executes Sensitive Tool

Potential telemetry:

User Request
+
Agent Decision
+
Tool Invocation
+
Service Identity
+
Target Resource
+
Action Result

This can support detection development.

Detection Opportunities Across AI Architecture

Identity

Monitor:

• Failed authentication

• Impossible travel

• Unusual account access

Application

Monitor:

• Abnormal request rates

• Suspicious interaction patterns

RAG

Monitor:

• Unusual retrieval volume

• Access to sensitive collections

Model

Monitor:

• Unexpected usage

• High-volume systematic queries

Agent

Monitor:

• Sensitive tool invocation

• Unusual actions

• Permission failures

Infrastructure

Monitor:

• Cloud audit activity

• model registry changes

• secret access

AI monitoring therefore combines traditional and AI-specific telemetry.

ATLAS and Incident Response

Suppose an AI agent performs an unauthorized action.

Investigators should reconstruct:

Who initiated the interaction?

What input was supplied?

What context was retrieved?

Which model processed it?

Which agent decision occurred?

Which tool was selected?

Which identity executed the action?

What resource was affected?

A complete timeline might look like:

09:01 User Prompt
09:01 RAG Retrieval
09:02 LLM Response
09:02 Agent Tool Selection
09:02 Cloud API Call
09:02 Resource Change
09:03 Security Alert

This is why AI security logging is so important.

Enterprise Scenario

Imagine an organization deploys:

Security Analyst
      │
      ▼
AI Security Assistant
      │
      ├── RAG
      │     └── Incident Runbooks
      │
      └── Agent
             ├── SIEM
             └── Cloud

Now imagine the following attack.

Stage 1 — Initial Position

A malicious insider has legitimate access to the assistant.

Stage 2 — Discovery

The insider determines that the assistant can query cloud resources.

Stage 3 — Manipulation

The attacker crafts requests designed to influence agent behavior.

Stage 4 — Agent Action

The agent invokes a cloud tool.

Stage 5 — Permission Abuse

The underlying service account has more privileges than required.

Stage 6 — Collection

Sensitive cloud configuration is retrieved.

Stage 7 — Exfiltration

The attacker copies the information.

Attack path:

Insider
  ↓
AI Application
  ↓
Capability Discovery
  ↓
Model Manipulation
  ↓
AI Agent
  ↓
Overprivileged Tool
  ↓
Cloud Data
  ↓
Exfiltration

This is exactly the kind of scenario ATLAS-style thinking helps us analyze.

Now Add Defenses

Identity

Limit access to authorized users.

Authorization

Restrict which cloud accounts each user can query.

Agent Permissions

Use read-only, scoped service roles.

Tool Policy

Allow only approved operations.

Data Controls

Restrict sensitive configuration retrieval.

Logging

Record tool invocation and target resources.

Detection

Alert on unusual queries or sensitive access.

Response

Provide procedures for disabling the agent or revoking its identity.

This turns an attack path into a security architecture.

Threat-Informed Defense

The goal is not simply:

Block Every Possible Attack

A stronger model is:

Understand Likely Adversary Behavior
        ↓
Prioritize Important Attack Paths
        ↓
Deploy Appropriate Controls
        ↓
Collect Useful Telemetry
        ↓
Detect Suspicious Behavior
        ↓
Respond Effectively

This is the essence of threat-informed security engineering.

Using ATLAS in an Architecture Review

When reviewing an AI system:

Step 1 — Understand the System

Identify:

• Users

• Models

• Data

• RAG

• Agents

• Tools

• Infrastructure

Step 2 — Identify High-Value Assets

Examples:

• Customer data

• Model files

• Cloud credentials

• AI agent identities

Step 3 — Identify Threat Actors

Examples:

• External attacker

• Insider

• Supply-chain attacker

Step 4 — Ask Adversary Questions

How would they discover this?

How would they gain access?

How would they influence the AI?

How would they reach the asset?

How would they avoid detection?

How would they create impact?

Step 5 — Map Controls

Identify:

• Preventive controls

• Detective controls

• Response controls

Preventive, Detective and Responsive Controls

A strong assessment should consider all three.

Preventive

Designed to stop or reduce the attack.

Examples:

• Authentication

• Authorization

• Least privilege

• Secure model repositories

Detective

Designed to identify suspicious activity.

Examples:

• Security logs

• Usage analytics

• Agent activity monitoring

Responsive

Designed to contain and recover.

Examples:

• Credential revocation

• Model rollback

• Agent disablement

• Incident response

Think:

Prevent
   +
Detect
   +
Respond

ATLAS Attack Path Worksheet

For each scenario, document:

Threat Actor:

Objective:

Initial Position:

Target AI Component:

Adversary Behavior:

Attack Path:

Required Permissions:

Target Asset:

Potential Impact:

Preventive Controls:

Detection Opportunities:

Response Actions:

This can later be used in labs and enterprise projects.

Example Worksheet

Threat Actor:
Malicious Insider

Objective:
Access restricted HR information

Initial Position:
Authenticated employee

Target:
Enterprise AI Assistant

Attack Path:
Employee
  ↓
AI Assistant
  ↓
RAG Query
  ↓
Missing Authorization
  ↓
HR Vector Collection
  ↓
Sensitive Document

Impact:
Confidential employee data exposure

Preventive Controls:
Document-level authorization
Identity-aware retrieval

Detection:
Alert on access to restricted HR collections

Response:
Disable account
Review retrieval logs
Investigate affected data

Notice that the framework helps structure the investigation rather than simply naming an attack.

Common Beginner Mistakes

Mistake 1 — Memorizing Technique Names

ATLAS should help you understand attacker behavior, not become another memorization exercise.

Mistake 2 — Treating Every Technique Independently

Real attacks often combine multiple behaviors.

Mistake 3 — Ignoring Traditional ATT&CK Behavior

AI attacks often begin with normal credential, cloud or application compromise.

Mistake 4 — Looking Only at the Model

The attacker may target:

• Data

• Infrastructure

• Pipelines

• Agents

• Tools

Mistake 5 — Using ATLAS Only for Red Teaming

ATLAS is also useful for:

• Architecture

• Detection

• Incident response

• Threat modeling

Mistake 6 — Ignoring Business Impact

An interesting AI technique may have little impact in an isolated environment.

Always map the behavior to business assets.

AI Security Engineer ATLAS Checklist

Architecture

• AI components are identified.

• Data flows are mapped.

• Trust boundaries are identified.

• Agent tools are documented.

Threat Actors

• External threats considered.

• Insider threats considered.

• Supply-chain threats considered.

• Third-party threats considered.

Reconnaissance

• Public AI exposure reviewed.

• Architecture information exposure reviewed.

• Administrative interfaces identified.

Models

• Model discovery risk considered.

• Model extraction risk considered.

• Model integrity protected.

• Model repositories secured.

Data

• Training data protected.

• RAG data protected.

• Data poisoning considered.

• Data exfiltration considered.

Agents

• Agent identity documented.

• Tool permissions reviewed.

• Excessive privilege assessed.

• High-impact actions controlled.

Supply Chain

• Model sources verified.

• Dependencies reviewed.

• CI/CD protected.

• MLOps pipeline protected.

Detection

• AI interactions are observable.

• RAG activity can be investigated.

• Agent actions are logged.

• Model repository changes are monitored.

Response

• Credentials can be revoked.

• Agents can be disabled.

• Models can be rolled back.

• Evidence can be collected.

Interview Perspective

You may be asked:

What is MITRE ATLAS?

A strong answer is:

MITRE ATLAS is a knowledge base of adversarial tactics and techniques targeting AI-enabled systems. I use it to understand attacker behavior, develop AI threat scenarios, map attack paths and identify prevention, detection and response controls.

Another question may be:

What is the difference between OWASP LLM Top 10 and MITRE ATLAS?

A strong answer is:

OWASP helps identify common security risk categories affecting LLM applications, while MITRE ATLAS focuses more on adversary tactics and techniques against AI systems. I can use OWASP to identify a weakness and ATLAS to understand how an attacker might incorporate that weakness into a larger attack path.

Another question may be:

Why should AI Security Engineers know both ATT&CK and ATLAS?

A strong answer is:

Because enterprise AI environments run on traditional applications, identities, cloud infrastructure and networks. An attacker may use conventional cyber techniques to gain access and then AI-specific techniques against models, data or agents. Combining ATT&CK and ATLAS provides a more complete view of the attack path.

Another question may be:

How would you use ATLAS during threat modeling?

A strong answer is:

I would first map the AI architecture, assets, identities, data flows and trust boundaries. I would then identify relevant threat actors and use ATLAS adversary behaviors to develop realistic attack paths. For each path I would document preventive controls, detection opportunities, potential impact and response requirements.

Key Takeaways

MITRE ATLAS helps us move from:

What weakness exists?

to:

How would an attacker use it?

The core thought process is:

Threat Actor
      ↓
Objective
      ↓
Attack Surface
      ↓
Adversary Technique
      ↓
Attack Path
      ↓
Target Asset
      ↓
Business Impact

ATLAS can support:

• Architecture reviews

• Threat modeling

• AI red teaming

• Detection engineering

• Incident investigation

• Security control design

Use ATLAS together with:

OWASP
+
MITRE ATT&CK
+
Architecture Analysis
+
Threat Modeling
+
Security Operations

The most important lesson is:

Do not study AI attacks as isolated techniques. Learn to understand the complete adversary journey from initial opportunity to business impact.

What’s Next?

➡️ 09 — AI Security Roles and Responsibilities

You now understand AI Security from three important perspectives:

Attack Surface
      ↓
Where can the system be attacked?

Threat Landscape
      ↓
Who may attack it and why?

MITRE ATLAS
      ↓
How may the adversary operate?

The next step is understanding who is responsible for securing the enterprise AI environment.

In the next lesson, you will explore:

• AI Security Engineer responsibilities

• AI developers

• Machine Learning engineers

• Cloud security teams

• Application security teams

• Data security teams

• SOC and incident response teams

• AI red teams

• Privacy teams

• GRC teams

• AI governance teams

• Business owners

• Shared responsibility

• Security ownership across the AI lifecycle

• RACI-style responsibility mapping

• How security teams collaborate during real enterprise AI projects

This will help you understand where the AI Security Engineer fits inside the organization and how the role works with other teams.

➡️ Next: 09 — AI Security Roles and Responsibilities