What Is the MITRE ATLAS AI Threat Framework?
- Aug 4
- 30 min read
An AI model can be tricked by a manipulated image, a poisoned training set, or a hidden sentence in a document it was never meant to trust, and none of that shows up on a network diagram. Traditional cybersecurity frameworks protect servers, credentials, and traffic, not a model's statistical behavior or the pipeline that feeds it. That gap is what MITRE ATLAS closes. It gives security teams, AI engineers, and risk leaders a shared, evidence-based vocabulary for how adversaries actually attack artificial intelligence and machine learning systems, from data collection through production deployment.
TL;DR: Key Takeaways
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a free, living knowledge base of adversary tactics and techniques aimed at AI and ML systems, built from real incidents and red-team exercises.
As of the July 2026 data release (2026.07), ATLAS documents 16 tactics, 101 top-level techniques with 77 sub-techniques, 37 mitigations, and 68 case studies, and updates monthly, so exact counts shift over time.
ATLAS is modeled on MITRE ATT&CK's structure but focuses on AI-specific behavior, such as training data poisoning, prompt injection, model extraction, and abuse of autonomous AI agents, while ATT&CK covers traditional IT and OT behavior.
Security architects, SOC teams, AI red teams, MLOps engineers, and GRC professionals use ATLAS for AI threat modeling, adversary emulation, control-gap analysis, and vendor risk assessment.
ATLAS is not a certification, regulation, or automatic risk score; it becomes useful only once mapped to an organization's own systems, controls, and detection capability.
What Is the MITRE ATLAS AI Threat Framework?
The MITRE ATLAS AI threat framework is a publicly available knowledge base that catalogs how adversaries attack artificial intelligence and machine learning systems. Built by MITRE and modeled on MITRE ATT&CK, it organizes real-world and demonstrated attack behavior into tactics, techniques, mitigations, and case studies, giving security teams a shared vocabulary for threat modeling, red teaming, and defense across predictive, generative, and agentic AI systems.
Table of Contents
What Is MITRE ATLAS?
In plain English, MITRE ATLAS is a public library of attack behavior aimed at AI systems. It tells defenders what adversaries have actually done, or convincingly demonstrated they can do, to compromise machine learning models, generative AI applications, and AI agents, organized into a structure teams can act on.
Technically, ATLAS is a threat-informed knowledge base: a structured collection of tactics (adversary goals), techniques and sub-techniques (methods used to reach those goals), mitigations (defensive controls), and case studies (real incidents or exercises that employed the techniques), connected through explicit, typed relationships. MITRE publishes the data as an open, machine-readable dataset on GitHub, exportable to STIX 2.1, Excel, and ATT&CK Navigator formats (MITRE ATLAS Data, GitHub, accessed August 3, 2026).
ATLAS is threat-informed and community-driven: contributors from industry, academia, and government AI red teams populate it with techniques observed in real incidents or proven against production-representative systems, and the public GitHub repository accepts new proposals reviewed for monthly releases.
MITRE calls ATLAS a "living knowledge base." Tactics, techniques, mitigations, and case studies are added and reorganized as the AI threat landscape shifts, most recently as adversaries move from attacking predictive classifiers toward generative AI and autonomous agents. Treat any specific count, including the ones in this article, as a snapshot rather than a permanent fact, and check the official matrix before quoting it in a report.
Equally important is what ATLAS is not: not a certification a vendor can earn, not a regulatory requirement, not a product, and not a substitute for an organization's own risk management program. Applying ATLAS does not guarantee security. It gives a shared vocabulary and a way to organize evidence; the judgment about what matters for your systems is still yours to make.
Why AI Systems Need a Dedicated Threat Framework
Every stage of the AI lifecycle introduces attack surface that looked different, or did not exist, in traditional software. Data collection can be poisoned before a model ever trains. Fine-tuning pipelines can be manipulated to implant backdoors. Inference APIs can leak the intellectual property they were built to protect. RAG systems and vector databases introduce indirect injection risk, since retrieved content an application trusts may have been planted by an adversary. Plugins, tools, and agentic workflows extend an AI system's blast radius into the real systems it can now act on, not just the text it generates.
Traditional cybersecurity frameworks remain necessary; identity, segmentation, endpoint protection, and secure development practices still matter for the infrastructure hosting AI workloads, and ATT&CK still describes much of the behavior adversaries use to reach it. What those frameworks do not fully capture is behavior that targets the model itself: manipulating what it learns, infers, or does when granted authority to act.
It helps to keep four concepts distinct: a vulnerability is a weakness, such as a model not hardened against adversarial inputs; a risk is the potential business impact if that weakness is exploited; an adversary behavior is a concrete action, which is what ATLAS techniques describe; and a business impact is the downstream consequence when a behavior succeeds. ATLAS primarily documents the behavior layer; connecting it to your specific risks and impact is still your work.
AI Lifecycle Stage | Representative Attack Surface |
Data collection | Scraped or crowdsourced data an adversary can influence before labeling |
Training and fine-tuning | Poisoned samples, manipulated labels, backdoored checkpoints |
Model hosting and inference | Exposed APIs, model extraction via repeated queries |
RAG and vector databases | Indirect prompt injection through retrieved documents |
Plugins, tools, and agents | Excessive permissions, tool misuse, unsafe autonomous actions |
Downstream business process | Decisions made on manipulated model output |
The History and Evolution of MITRE ATLAS
MITRE released the framework in 2020 as the Adversarial ML Threat Matrix, built with organizations including Microsoft, before rebranding it MITRE ATLAS. It grew from the adversarial machine-learning research community, work that had shown production ML models could be evaded, poisoned, or stolen well before generative AI became mainstream. The official collection metadata records the matrix's creation date as October 23, 2020 (MITRE ATLAS Data repository, GitHub, accessed August 3, 2026).
Early releases concentrated on predictive AI: image classifiers and malware detectors, where the concerns were evasion, extraction, and poisoning. As large language models moved into production, MITRE progressively added generative AI tactics and techniques, including prompt injection, jailbreaking, and system-prompt extraction. Most recently, the matrix has expanded into agentic AI, adding techniques for AI agent tool invocation, credential access from agent configuration, and agent-based command and control.
ATLAS now releases monthly, versioned as YYYY.MM (for example, 2026.07). As of the current release, it documents 16 tactics, 101 top-level techniques, 77 sub-techniques, 37 mitigations, and 68 case studies, 50 Exercise and 18 Incident (MITRE ATLAS Data repository, dist/v6/ATLAS-2026.07.yaml, accessed August 3, 2026). Because ATLAS is a living knowledge base, these totals will already have shifted by the time you read this; always confirm current counts against the live matrix rather than treating any published figure as permanent.
How the MITRE ATLAS Matrix Is Organized
The ATLAS Matrix sits at the top: one matrix containing an ordered sequence of tactics. Each tactic is an adversary's objective at a stage of attack, such as Reconnaissance or Exfiltration. Under each tactic sit techniques, specific methods for reaching that objective, and many break down further into sub-techniques for added precision. Mitigations are controls linked to the techniques they help address, and case studies are documented incidents or exercises mapping a real attack sequence to tactics and techniques.
Every object carries a stable, typed identifier. A tactic ID looks like AML.TA0002 (Reconnaissance). A technique ID looks like AML.T0051 (LLM Prompt Injection), and a sub-technique adds a third segment, such as AML.T0010.002. A mitigation ID looks like AML.M0020 (Generative AI Guardrails), and a case-study ID looks like AML.CS0056 (MITRE ATLAS Data repository, GitHub, accessed August 3, 2026). Preserving these IDs exactly, rather than paraphrasing them, is what lets a detection rule, a risk register entry, and a MITRE report all refer to the same behavior.
ATLAS Element | What It Represents | Example ID | How Defenders Use It |
Tactic | Adversary's objective at a stage of attack | AML.TA0004 (Initial Access) | Groups techniques by attacker goal |
Technique | A specific method to achieve a tactic | AML.T0051 (LLM Prompt Injection) | Anchors detections to a named behavior |
Sub-technique | A more specific variant of a technique | AML.T0010.002 (Data supply chain) | Adds precision for prioritization |
Mitigation | A defensive control mapped to techniques | AML.M0020 (Generative AI Guardrails) | Feeds control-gap analysis |
Case study | A documented incident or exercise | AML.CS0056 | Supports tabletop exercises |
MITRE ATLAS Tactics Across the AI Attack Lifecycle
ATLAS defines 16 tactics, sequenced left to right in roughly the order an attacker progresses through them, verified against the official matrix ordering (MITRE ATLAS Data repository, accessed August 3, 2026). The list below preserves MITRE's official names and order, with the objective and a representative technique for each.
Reconnaissance (AML.TA0002)
Adversary objective: gathering information about a target AI system before attacking it, such as Search Open Technical Databases (AML.T0000).
Resource Development (AML.TA0003)
Adversary objective: building or acquiring attack capability, such as Acquire Public AI Artifacts (AML.T0002) or Obtain Capabilities (AML.T0016).
Initial Access (AML.TA0004)
Adversary objective: gaining an initial foothold, such as AI Supply Chain Compromise (AML.T0010) via a poisoned pretrained model.
AI Model Access (AML.TA0000)
Adversary objective: establishing the level of model access needed, from AI Model Inference API Access (AML.T0040) to Full AI Model Access (AML.T0044).
Execution (AML.TA0005)
Adversary objective: running adversary-controlled logic, most visibly LLM Prompt Injection (AML.T0051).
Persistence (AML.TA0006)
Adversary objective: maintaining a foothold across retraining or sessions, such as Training Data Poisoning (AML.T0020).
Privilege Escalation (AML.TA0012)
Adversary objective: gaining higher permissions than granted, such as LLM Jailbreak (AML.T0054).
Defense Evasion (AML.TA0007)
Adversary objective: avoiding detection; the most heavily populated tactic, including Evade AI Model (AML.T0015).
Credential Access (AML.TA0013)
Adversary objective: stealing credentials tied to AI systems, such as RAG Credential Harvesting (AML.T0082).
Discovery (AML.TA0008)
Adversary objective: learning about the environment after access, such as Discover AI Model Family (AML.T0014).
Lateral Movement (AML.TA0015)
Adversary objective: moving between systems or agents, such as AI Agent Tool Invocation (AML.T0053).
Collection (AML.TA0009)
Adversary objective: gathering data or artifacts before exfiltration, such as AI Artifact Collection (AML.T0035).
AI Attack Staging (AML.TA0001)
Adversary objective: preparing a tailored attack, such as Create Proxy AI Model (AML.T0005).
Command and Control (AML.TA0014)
Adversary objective: directing compromised AI infrastructure, such as AI Service API (AML.T0096).
Exfiltration (AML.TA0010)
Adversary objective: getting data out, such as Extract LLM System Prompt (AML.T0056).
Impact (AML.TA0011)
Adversary objective: achieving the final goal, such as Denial of AI Service (AML.T0029) or Erode AI Model Integrity (AML.T0031).
Which of these 16 tactics matters most depends on architecture. A public-facing agent with tool access should weight Execution, Privilege Escalation, and Command and Control heavily; an internal classifier should weight Reconnaissance, AI Model Access, and Defense Evasion. ATLAS supplies the map, not the route.
Techniques, Sub-Techniques, Platforms, and Maturity Levels
A tactic states a goal; a technique states a method. Some techniques need sub-techniques to narrow the method to a context, such as AI Supply Chain Compromise (AML.T0010) breaking into hardware, artifact, and data sub-techniques. A single technique can also achieve more than one tactic; AI Agent Tool Invocation (AML.T0053) appears as both a Privilege Escalation and a Lateral Movement technique in the current matrix.
Every technique is tagged with one or more platforms describing the AI system type it applies to: Predictive AI, Generative AI, Agentic AI, and Enterprise, the last covering conventional IT and OT behavior adapted from ATT&CK (MITRE ATLAS Data repository, accessed August 3, 2026). Filtering by platform is the fastest way to cut 178 technique-level objects down to what actually applies; a computer-vision fraud model has no exposure to LLM Jailbreak.
ATLAS also tags each technique with a maturity level: Feasible (shown in controlled research), Demonstrated (executed against a production-representative system), or Realized (observed in a real incident). Maturity is not the same as severity, prevalence, or exploitability; a Feasible technique against a weakly controlled system can matter more right now than a Realized technique against a system you do not run.
Technique | ID | Platform(s) | What It Illustrates |
LLM Prompt Injection | AML.T0051 | Generative AI, Agentic AI | Malicious instructions in input override intended behavior |
AI Supply Chain Compromise | AML.T0010 | Predictive AI, Generative AI, Enterprise | Compromised model artifacts or dependencies as entry point |
RAG Credential Harvesting | AML.T0082 | Generative AI, Agentic AI | Secrets exposed through retrieval components |
Denial of AI Service | AML.T0029 | Predictive AI, Generative AI, Agentic AI | Resource exhaustion against expensive AI compute |
Combining platform and maturity filters lets a team build a scoped worklist instead of defending against all 178 technique-level objects equally.
MITRE ATLAS Mitigations
A mitigation is a defensive control linked to one or more techniques it helps address. ATLAS documents 37 mitigations (MITRE ATLAS Data repository, accessed August 3, 2026), from established practices like access control and AI guardrails to AI-specific controls like AI Bill of Materials and Human In-the-Loop for AI Agent Actions.
Mitigations are not one-to-one fixes. Control Access to AI Models and Data in Production (AML.M0019) maps to many techniques across several tactics, and one technique is usually only partially addressed by any single mitigation. Layered controls matter: preventive controls block an action, detective controls spot it, limiting controls reduce blast radius, and recovery controls restore service afterward.
Access control: Control Access to AI Models and Data at Rest (AML.M0005) and in Production (AML.M0019) limit who can reach models and data.
Model and data integrity: Sanitize Training Data (AML.M0007) and Validate AI Model (AML.M0008) reduce the chance poisoned inputs reach production.
Input and output handling: Generative AI Guardrails (AML.M0020) filters what goes into and comes out of a model.
Monitoring: AI Telemetry Logging (AML.M0024) gives defenders evidence to detect and investigate AI-specific incidents.
Segmentation: Segmentation of AI Agent Components (AML.M0032) limits how far a compromised agent can reach.
Supply-chain controls: AI Bill of Materials (AML.M0023) and Verify AI Artifacts (AML.M0014) address third-party model risk.
Human approval: Human In-the-Loop for AI Agent Actions (AML.M0029) keeps a person in the loop for consequential actions.
Testing: AI Red Team (AML.M0035) exercises controls against realistic techniques before an adversary does.
Applying a mitigation reduces exposure; it does not guarantee a technique is blocked. Treat mapping as a way to prioritize gaps, then validate coverage through testing rather than assuming it from the mapping alone.
MITRE ATLAS Case Studies
Case studies map a documented sequence of adversary steps to specific tactics and techniques, showing how an attack actually progressed. ATLAS documents 68 case studies: 18 labeled Incident (a real-world attack occurred) and 50 labeled Exercise (researchers or red teams demonstrated the path without a malicious actor) (MITRE ATLAS Data repository, accessed August 3, 2026). Both categories carry value: Incidents confirm real-world impact, and Exercises often surface techniques before adversaries catch up.
Defenders use case studies for tabletop exercises, detection engineering, and threat modeling, giving a documented starting point instead of a blank page.
VirusTotal Poisoning (AML.CS0002)
McAfee's Advanced Threat Research team traced an unusual spike in one ransomware family to a large batch of file samples uploaded to VirusTotal in a short window, an attempt to poison shared threat-intelligence data other vendors' models train on (MITRE ATLAS, case study AML.CS0002, accessed August 3, 2026). It shows AI Supply Chain Compromise reaching beyond a single organization through shared training data.
ClearviewAI Misconfiguration (AML.CS0006)
Researchers at spiderSilk found Clearview AI's source-code repository was misconfigured to allow open account creation, exposing its facial-recognition algorithm and pretrained models (MITRE ATLAS, case study AML.CS0006, accessed August 3, 2026). It shows AI Model Access failures are often ordinary misconfigurations, not exotic adversarial-ML attacks.
Amazon Q VS Code Extension: Destructive AI Agent Code (AML.CS0047)
In July 2025, an actor using an improperly scoped GitHub token committed malicious code into the Amazon Q Developer VS Code extension, designed to trigger destructive actions on developer machines (MITRE ATLAS, case study AML.CS0047, accessed August 3, 2026). It is a recent Incident showing AI supply-chain compromise reaching directly into agent-based developer tooling.
SesameOp: A Backdoor Using the OpenAI Assistants API for C2 (AML.CS0042)
Microsoft's Detection and Response Team found an implant using the OpenAI Assistants API itself as a covert command-and-control channel for espionage, rather than an attacker-controlled server (MITRE ATLAS, case study AML.CS0042, accessed August 3, 2026), illustrating AI Service API abuse for Command and Control.
Model Distillation Campaigns Targeting Anthropic Claude (AML.CS0056)
Anthropic identified coordinated efforts by three AI labs, using roughly 24,000 accounts and 16 million queries, to extract Claude's capabilities through model distillation (MITRE ATLAS, case study AML.CS0056, accessed August 3, 2026), a large-scale, recent example of the model-extraction pattern under Resource Development and Exfiltration.
These five case studies span six years and every current ATLAS platform label. The pattern is consistent: adversaries adapt techniques to whatever architecture is in front of them, and the fastest-growing category is abuse of APIs, agents, and supply chains rather than a model's mathematics directly.
Major AI Threats Explained Through ATLAS
This section ties common AI-security terms to their place in ATLAS. A few terms, such as jailbreaking as a general concept, come from the wider AI-security field rather than being an official ATLAS tactic or technique name; those are noted below.
Reconnaissance Against AI Systems
Studying a target before attacking it maps to Reconnaissance (AML.TA0002), including Search Open Technical Databases (AML.T0000).
Resource Development for AI Attacks
Building or acquiring attack capability, such as a similar open model to rehearse against, maps to Resource Development (AML.TA0003).
Initial Access and AI Supply Chain Compromise
A large share of real-world incidents start with AI supply chain compromise (AML.T0010): a poisoned model, dependency, or dataset.
Prompt Injection and Indirect Prompt Injection
Prompt injection (AML.T0051) causes a model to follow attacker instructions instead of its own; the indirect variant delivers those instructions through retrieved content a RAG or tool-connected system trusts.
Jailbreak-Related Behavior
AI jailbreaking getting a model to override its safety behavior, is documented as LLM Jailbreak (AML.T0054), classified as Privilege Escalation.
Training-Data and Fine-Tuning-Data Poisoning
Data poisoning (AML.T0020) manipulates training data so the resulting model behaves as the adversary intends.
Model Poisoning and Manipulation
Manipulate AI Model (AML.T0018) covers direct tampering with a model artifact's weights, code, or configuration.
Evasion and Adversarial Examples
Evade AI Model (AML.T0015) covers inputs crafted to cause misclassification while appearing normal to a human reviewer.
Model Extraction and Theft
Rebuilding a similar model by repeatedly querying a target, as in the GPT-2 replication exercise, connects to AI Model Inference API Access (AML.T0040).
Sensitive-Information Disclosure
LLM security programs track this closely; Extract LLM System Prompt (AML.T0056) is a representative technique.
Membership and Inference-Related Attacks
Membership-inference and model-inversion attacks, inferring or reconstructing training data, connect to the Discovery and Collection tactics.
API Abuse
Since most production AI is reached through an inference API, AI Model Inference API Access (AML.T0040) anchors many attack chains.
Retrieval and Vector-Store Manipulation
RAG systems introduce techniques like RAG Credential Harvesting (AML.T0082), where secrets exposed through retrieval become a credential-access path.
Abuse of Plugins, Tools, and Agent Permissions
AI Agent Tool Invocation (AML.T0053) is increasingly consequential, since a manipulated tool call can escalate privilege or move an attacker laterally.
Persistence in AI-Enabled Environments
LLM Prompt Self-Replication (AML.T0061) documents malicious instructions persisting across sessions or propagating through systems that reuse model output.
Credential Access
Credentials from AI Agent Configuration (AML.T0083) reflects secrets often stored in agent configuration without traditional credential-store rigor.
Discovery and Lateral Movement
Discover AI Model Family (AML.T0014) helps an adversary map access, then techniques like AI Agent Tool Invocation move them toward higher-value systems.
Collection, Staging, and Exfiltration
AI Artifact Collection (AML.T0035) and Exfiltration via AI Inference API (AML.T0024) describe how adversaries gather and remove material before impact.
Integrity, Availability, and Business Impact
The Impact tactic (AML.TA0011) closes the matrix with outcomes like Denial of AI Service (AML.T0029) and Erode AI Model Integrity (AML.T0031); financial, safety, privacy, and reputational impact sit downstream and are the layer your own risk assessment must connect back to the technique.
A Hypothetical End-to-End ATLAS Attack Scenario
The scenario below is a constructed, non-operational example illustrating how ATLAS tactics connect across an attack chain. It describes no real incident, includes no working payloads or bypass steps, and should be read as a tabletop-planning exercise only.
Picture a company that has deployed an internal AI assistant with a document-retrieval tool and an email tool, built on a third-party model and a RAG pipeline drawing from the company's shared drive.
Stage | ATLAS Tactic | Illustrative Technique | Observable Signal | Defensive Control | Responsible Team |
An outside party plants a document with hidden instructions in a shared folder | Resource Development | Obtain Capabilities (AML.T0016) | Unusual upload from an unfamiliar external account | Access review on shared drives | IT / Data Owners |
A user asks the assistant to summarize documents in that folder | Execution | LLM Prompt Injection (AML.T0051), indirect variant | Output contains instructions absent from the user's own prompt | Generative AI Guardrails (AML.M0020) | AppSec / AI Platform Team |
Hidden instructions try to get the assistant to invoke its email tool | Privilege Escalation | AI Agent Tool Invocation (AML.T0053) | Tool call triggered without a matching explicit request | Human In-the-Loop for AI Agent Actions (AML.M0029) | AI Platform Team |
The assistant's output is reviewed for anomalies | Defense Evasion | LLM Trusted Output Components Manipulation (AML.T0067) | Output formatting designed to blend in | AI Telemetry Logging (AML.M0024) | SOC / Detection Engineering |
If unnoticed, the tool attempts to send document contents externally | Exfiltration | Exfiltration via AI Inference API (AML.T0024) | Outbound email to an unrecognized recipient | Segmentation of AI Agent Components (AML.M0032) | SOC / Incident Response |
Even this simplified mapping shows why single-layer defenses fall short: a guardrail screening only the user's direct prompt would miss the indirect injection entirely, while a human-approval step on tool invocation catches the escalation regardless of how the injected instruction was worded.
MITRE ATLAS vs. MITRE ATT&CK
ATLAS and ATT&CK share the same threat-informed, behavioral philosophy: describe what adversaries actually do, organize it into tactics and techniques, and ground it in real observations. ATLAS explicitly adapts a number of ATT&CK techniques, tagged with an ATT&CK-reference field in the official data, for cases where conventional infrastructure behavior is still exactly how an adversary reaches an AI system (MITRE ATLAS Data repository, accessed August 3, 2026).
The two differ in primary scope. ATT&CK, with 14 tactic categories across Enterprise, Mobile, and ICS matrices, describes behavior against conventional IT, cloud, and OT environments. ATLAS focuses on behavior targeting the AI model, its training data, and AI-specific supporting infrastructure. Many real incidents blend both: an attacker might use phishing for initial network access, then pivot to Training Data Poisoning once inside.
Dimension | MITRE ATT&CK | MITRE ATLAS |
Main focus | Conventional IT, cloud, mobile, and OT behavior | Behavior targeting AI and ML systems specifically |
Primary assets | Networks, endpoints, identities, cloud infrastructure | Models, training data, inference APIs, AI agents |
Typical behaviors | Phishing, lateral movement, credential theft, ransomware | Prompt injection, data poisoning, extraction, agent tool abuse |
Main users | SOC, incident response, red teams | AI red teams, MLOps, AI platform teams, plus the same SOC/IR audience |
Example use case | Mapping a ransomware intrusion chain | Mapping how a poisoned model or prompt led to impact |
Organizations should use both together. A joint mapping supports fuller investigation coverage, since incidents touching AI rarely stay confined to AI-specific behavior, and fuller control coverage, since ATT&CK-informed network and identity controls remain necessary for AI-specific attack chains. Describing ATLAS simply as "ATT&CK for AI" understates it; ATLAS inherits ATT&CK's proven methodology while adding an entirely new category of behavior ATT&CK was never designed to capture.
MITRE ATLAS Compared With Other AI Security Frameworks
ATLAS is one of several frameworks organizations now reference for AI security, and they solve different problems rather than compete.
The NIST AI Risk Management Framework (AI RMF 1.0), published January 2023, is a voluntary, organization-level framework built around four functions: Govern, Map, Measure, and Manage. Its companion Generative AI Profile (NIST AI 600-1), published July 26, 2024, extends the RMF with twelve risk categories specific to generative AI, such as confabulation and information security, and more than 200 suggested actions (NIST AI Risk Management Framework, nist.gov, accessed August 3, 2026).
The OWASP Top 10 for LLM Applications, in its 2025 edition, is a prioritized list of the ten most critical risks in LLM application development, led by Prompt Injection (LLM01:2025) and Sensitive Information Disclosure (LLM02:2025). Where ATLAS catalogs adversary behavior across the full AI lifecycle, OWASP's list is scoped to application-layer risk in LLM-powered software.
Resource | Primary Purpose | Organizing Model | Best Use | Relationship to ATLAS |
MITRE ATLAS | Catalog adversary TTPs against AI systems | Tactics, techniques, mitigations, case studies | Threat modeling, red teaming, detection engineering | n/a |
MITRE ATT&CK | Catalog adversary TTPs against IT/cloud/OT | Tactics and techniques | Conventional intrusion mapping | Complementary; shared methodology, different scope |
NIST AI RMF 1.0 | Organization-level AI risk governance | Govern, Map, Measure, Manage | Program-level risk management | ATLAS techniques can populate Map and Measure |
NIST AI 600-1 (GenAI Profile) | Generative AI-specific risk categories | 12 risk categories with actions | GenAI-specific governance | Broader risk lens; ATLAS supplies adversarial detail |
OWASP Top 10 for LLM Apps (2025) | Prioritized LLM application risks | 10 numbered categories | AppSec review of LLM apps | Overlapping techniques at the application-risk layer |
None of these resources replaces another. NIST answers "what should our AI governance cover," OWASP answers "what should our AppSec review focus on," and ATLAS answers "what specific adversary behavior should our threat model and red team account for." A mature program typically references all three, with ATLAS as the behavioral backbone connecting the governance layer above it to the application checklist beside it.
Who Should Use MITRE ATLAS?
Security leadership: communicate AI risk to the board in concrete, evidence-backed terms and justify investment in AI-specific controls.
Threat intelligence: track how adversary behavior against AI is evolving using case studies and technique trends.
SOC teams: use tactic and technique names as a shared vocabulary when triaging AI-related alerts.
Incident responders: structure investigation of AI incidents using the tactic sequence, the way ATT&CK structures conventional intrusions.
Detection engineers: identify what telemetry AI systems are currently missing.
AI red teams: plan realistic, technique-grounded engagements instead of ad hoc testing.
Application-security teams: review AI Model Access and Execution exposure alongside conventional vulnerabilities.
ML and MLOps engineers: harden pipelines with mitigations like Sanitize Training Data and Validate AI Model.
AI platform teams: design agent and tool permission models using agent-focused techniques and mitigations.
GRC professionals: enrich AI risk registers with named adversary behaviors instead of generic statements.
Procurement and third-party risk: ask sharper AI-vendor questions using supply-chain techniques.
Product owners: understand what security review an AI feature actually needs before launch.
Internal audit: use ATLAS coverage as one input when assessing whether a security program operates as designed.
Researchers and educators: use the matrix and case studies as a citable teaching resource.
Practical Use Cases for MITRE ATLAS
AI threat modeling: use the matrix as a checklist of adversary behaviors during design review.
Security architecture review: check whether a proposed system leaves gaps against high-priority tactics.
Adversary emulation and red-team planning: build test plans around specific technique IDs for comparability over time.
Purple teaming: have red and blue teams work from the same technique list.
Detection and telemetry planning: decide what logs an AI system needs to emit.
Incident classification: tag incidents with ATLAS technique IDs for consistent reporting.
Tabletop exercises: walk stakeholders through a scenario like the one later in this article.
Control-gap analysis: cross-reference your control library against ATLAS mitigations.
AI vendor assessment: ask which ATLAS techniques a product is tested against.
Secure-design reviews: evaluate agent tool permissions before an agent ships.
Risk-register enrichment: replace vague "AI risk" entries with specific technique references.
Security training: use real case studies to make training concrete.
Executive communication: translate technique-level findings into business-impact language.
Mapping real incidents: tag incidents with ATLAS IDs so lessons are comparable across events.
How to Implement MITRE ATLAS Step by Step
The ten steps below give a team a concrete path from first exposure to an operational, ATLAS-informed program.
1. Inventory AI systems and dependencies
Catalog every AI model, application, and agent in production or development, including third-party and embedded features. Owners: AI platform team, application owners, procurement. Deliverable: a living inventory with owner, platform, and data sensitivity per entry. Pitfall: shadow AI deployed informally without security review.
2. Define business context and critical assets
Identify which AI systems touch sensitive data, regulated processes, or safety-critical decisions. Owners: business owners, GRC, security architecture. Deliverable: a criticality-ranked system list. Pitfall: treating every system as equally critical.
3. Classify platforms and AI capabilities
Tag each system as Predictive AI, Generative AI, Agentic AI, or a mix. Owners: AI platform team, ML engineers. Deliverable: a platform classification per system. Pitfall: missing agentic capability added after initial classification.
4. Identify threat actors and abuse cases
Note who would target each system and why. Owners: threat intelligence, security architecture. Deliverable: a short abuse-case summary per critical system. Pitfall: generic threat-actor lists never tailored to the system.
5. Select relevant tactics and techniques
Filter the matrix by platform and maturity to build a scoped technique list per system. Owners: AI red team, security architecture. Deliverable: a per-system technique worklist. Pitfall: trying to address all 178 technique-level objects equally.
6. Map existing controls and mitigations
Cross-reference current controls against mitigations linked to your selected techniques. Owners: security engineering, MLOps. Deliverable: a control-coverage matrix. Pitfall: assuming a mitigation fully closes a technique without testing it.
7. Identify telemetry and detection gaps
For uncovered techniques, determine what logging or monitoring would detect them. Owners: detection engineering, SOC. Deliverable: a prioritized telemetry backlog. Pitfall: building detections for techniques with no available signal source.
8. Develop safe test scenarios
Design tabletop or controlled red-team tests scoped to your architecture. Owners: AI red team, incident response. Deliverable: a documented, non-operational scenario mapped to technique IDs. Pitfall: testing in production without safeguards or sign-off.
9. Assign control and response ownership
Name an owner for each mitigation and detection so gaps do not fall between teams. Owners: security leadership, AI platform team. Deliverable: an ownership matrix. Pitfall: leaving AI controls without an owner distinct from general IT security.
10. Prioritize remediation and review new releases regularly
Fix the highest-priority gaps first, track coverage over time, and review each monthly ATLAS release. Owners: security leadership, AI platform team, GRC. Deliverable: a remediation roadmap and recurring review cadence. Pitfall: treating the mapping as a one-time project.
A minimal ATLAS-informed threat-model record: System: internal document-search assistant. Platform: Generative AI, Agentic AI. Selected techniques: AML.T0051, AML.T0053, AML.T0082. Mitigations in place: AML.M0020. Gaps: no human-in-the-loop control (AML.M0029), no AI telemetry logging (AML.M0024). Owner: AI Platform Team. Review date: next ATLAS release.
Mapping ATLAS to the Secure AI Development Lifecycle
ATLAS informs security requirements and testing at each stage of building or adopting an AI system; it does not replace the secure-development practices any software should already follow, such as code review and change management.
SDLC Stage | ATLAS-Informed Focus |
Planning and requirements | Identify applicable tactics based on planned platform and data sensitivity |
Data acquisition | Apply Sanitize Training Data (AML.M0007) and Maintain AI Dataset Provenance (AML.M0025) |
Model selection | For third-party models, apply Verify AI Artifacts (AML.M0014) and AI Bill of Materials (AML.M0023) |
Training and fine-tuning | Test for Training Data Poisoning (AML.T0020) susceptibility before promotion |
Evaluation and red teaming | Run AI Red Team (AML.M0035) exercises against the technique worklist |
Deployment | Apply least-privilege access and agent permissions (AML.M0019) |
Runtime monitoring | Implement AI Telemetry Logging (AML.M0024) mapped to priority techniques |
Incident response | Use the tactic sequence to structure investigation and tag findings |
Model update or retirement | Reassess technique exposure whenever architecture or permissions change |
For internally developed models, this integrates into existing SDLC gates. For third-party AI services, most stages become vendor-assessment questions instead of internal engineering tasks.
Building an ATLAS-Based AI Security Program
A lightweight operating model for an organization starting from zero needs to cover governance, execution, and feedback without requiring a large dedicated team on day one.
Governance: name an accountable owner for AI security and set a cadence for reviewing new ATLAS releases.
Roles: clarify who owns inventory, control implementation, and detection, since these often span teams.
Asset ownership: every AI system needs a named business and technical owner.
Threat-intelligence integration: fold ATLAS case-study updates into existing briefings.
Control libraries: maintain the mitigation mapping as a living document, not a one-time spreadsheet.
Detection engineering: prioritize telemetry for the highest-priority techniques.
Red-team governance: define scope and safety rules for AI-specific engagements up front.
Responsible testing: never test AI-specific attack techniques against production without authorization.
Incident playbooks: extend existing playbooks with AI-specific tactic and technique references.
Vendor risk: fold ATLAS supply-chain questions into third-party risk questionnaires.
Training: use real case studies in security-awareness and engineering training.
Reporting: report coverage and gaps in business terms tied to critical systems.
Release management: assign someone to review each monthly release for relevant new techniques.
Measuring ATLAS Coverage and Program Maturity
Coverage metrics should show where real gaps remain, not just how much activity has occurred. Useful, defensible metrics include:
Percentage of critical AI systems inventoried and classified by platform
Percentage of relevant techniques assessed per critical system
Percentage of high-priority techniques with a preventive control in place
Percentage of high-priority techniques with supporting telemetry
Number of techniques covered by a validated detection, not just a theoretical mapping
Percentage of mitigations tested rather than assumed effective
Average time to map a new AI-related incident to ATLAS technique IDs
Average age of open remediation items tied to AI-specific gaps
Review cadence: whether each monthly release is actually reviewed
Percentage of third-party AI systems with a completed vendor risk assessment
Raw coverage percentages are easy to misread. A team can map 100 percent of techniques to some control on paper while none are tested against the actual technique. Treat coverage as a starting point for a conversation about validated defenses, not proof of security on its own.
The maturity model below is an editorial framework built for this article, not an official MITRE model, and should not be presented as one.
Maturity Level | What It Looks Like |
Ad hoc | AI systems not fully inventoried; ATLAS known but not applied systematically |
Defined | Inventory and technique mapping exist for critical systems; ownership assigned |
Operational | Detections and mitigations implemented and tested against selected techniques; monthly review is routine |
Adaptive | Coverage metrics, incident learnings, and new releases actively reshape priorities |
Common Mistakes When Using MITRE ATLAS
Treating the matrix as a checklist to complete once
Better practice: Revisit it with every monthly release and every architecture change.
Attempting to cover every technique equally
Better practice: Prioritize by platform relevance and maturity, focusing effort where exposure is real.
Confusing maturity with severity
Better practice: Weigh maturity alongside business impact and exploitability specific to your systems.
Ignoring traditional cybersecurity attack paths
Better practice: Keep ATT&CK-adapted techniques and conventional controls in scope.
Focusing only on prompt injection
Better practice: Give data, model, API, identity, and supply-chain risks equal attention.
Using generic mitigations without validation
Better practice: Test that a mitigation actually blocks or detects the specific technique it maps to.
Failing to collect telemetry
Better practice: Build detection and logging in from the start rather than after an incident.
Mapping incidents too broadly
Better practice: Tag incidents with the most specific applicable technique ID, not just the parent tactic.
Ignoring model context and business impact
Better practice: Connect every mapping back to what exploitation would actually cost the business.
Letting mappings become stale
Better practice: Reassess exposure whenever a system's architecture, data sources, or permissions change.
Treating framework adoption as compliance certification
Better practice: Remember ATLAS is a taxonomy, not a certification; document risk decisions separately.
Strengths and Limitations of MITRE ATLAS
ATLAS earns adoption on several strengths: a shared vocabulary so a technique means the same thing across organizations; a behavioral focus that translates directly into detection and testing work; grounding in real-world and demonstration-based evidence; structured relationships between tactics, techniques, mitigations, and case studies; coverage across predictive, generative, agentic, and enterprise platforms; active community contribution; and machine-readable data that integrates with existing tooling.
The same qualities create real limitations. The AI threat landscape changes faster than any framework can formally track, so a static snapshot, this article's figures included, ages quickly. Evidence maturity is uneven across techniques. ATLAS supplies no automatic risk score and no complete control catalogue; organizational context still has to supply the judgment. Applying a mapped mitigation is not a guarantee it prevents or detects a given technique in your environment. ATLAS overlaps with other frameworks, which can create redundant work without coordination, and implementation takes real, sustained effort that goes stale without a review cadence.
The Future of MITRE ATLAS and AI Threat-Informed Defense
Several developments are visible in ATLAS's recent release history and are reasonable to expect to continue, though not guaranteed. Agentic AI coverage has expanded rapidly as agent frameworks became mainstream, and this shows no sign of slowing given how quickly organizations grant AI systems tool access. The monthly cadence itself reflects intent to keep pace with a fast-moving landscape. MITRE continues investing in machine-readable distribution, including STIX 2.1 export and ATT&CK Navigator layers, supporting tighter integration with security operations tooling (MITRE ATLAS Data repository, accessed August 3, 2026).
It is reasonable to expect continued growth in case studies as more organizations report AI-specific attacks, and continued refinement of maturity ratings as techniques move from Feasible toward Realized. What is not yet certain, and should be treated as informed interpretation rather than a MITRE statement, is exactly how far agentic AI coverage will expand, or whether entirely new tactic categories will emerge for multi-agent attack behavior. Treat any forward-looking claim on this topic, including these, as reasoned expectation rather than fact, and verify against the live ATLAS changelog.
Final Perspective
MITRE ATLAS matters because it gives security teams a name for behavior that, until recently, had no shared name: manipulating what a model learns, tricking it into acting against its own instructions, or abusing the tools an AI agent has been given. A technique with a stable ID like AML.T0051 can be tested for, logged, mapped to a control, and compared across incidents in a way a vague concern about "AI risk" cannot.
What ATLAS does best is give structure to adversarial AI behavior across the full lifecycle, backed by real incidents and credible demonstrations rather than speculation. What it does not replace is your own risk management program, your existing cybersecurity controls, or a governance framework like the NIST AI RMF that sets the policy context ATLAS's technical detail fits into. It is a taxonomy and an evidence base, not a certification, and no amount of technique coverage substitutes for testing whether your specific controls actually work.
A practical first step is small and achievable: inventory your AI systems, pick the single most critical one, and run it through the ten-step implementation process in this article. The technique-level detail from that one exercise will sharpen your AI security posture more than reading the entire matrix without applying it anywhere.
Frequently Asked Questions
What does MITRE ATLAS stand for?
ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems, a MITRE-maintained knowledge base documenting how adversaries attack AI and machine learning systems, organized into tactics, techniques, mitigations, and case studies, modeled on MITRE ATT&CK.
Is MITRE ATLAS free?
Yes. The matrix, technique descriptions, mitigations, and case studies are free on the official ATLAS website, and the underlying dataset is published openly on GitHub for anyone to use or integrate into their own tools.
Is MITRE ATLAS a standard or certification?
No. ATLAS is a knowledge base and taxonomy, not a certification, regulation, or product. No organization becomes "ATLAS certified," and applying it does not by itself prove a system is secure; it supports an organization's own risk decisions.
What is the difference between MITRE ATLAS and MITRE ATT&CK?
ATT&CK documents adversary behavior against conventional IT, cloud, mobile, and OT environments. ATLAS documents behavior specifically targeting AI and ML systems, such as data poisoning, prompt injection, and model extraction, and adapts some ATT&CK techniques directly. Organizations typically use both together.
Does MITRE ATLAS cover generative AI?
Yes. Generative AI is an official ATLAS platform label. Techniques like LLM Prompt Injection, LLM Jailbreak, and Extract LLM System Prompt specifically address large language models and other generative AI systems.
Does MITRE ATLAS cover agentic AI?
Yes, and it is one of the fastest-growing parts of the matrix. Agentic AI is an official platform label, with techniques like AI Agent Tool Invocation addressing systems that can call tools and take autonomous action.
Does ATLAS include prompt injection?
Yes. LLM Prompt Injection (AML.T0051) is an official technique under Execution, covering both direct injection from user input and indirect injection delivered through retrieved content a model trusts.
What are tactics and techniques in ATLAS?
A tactic is an adversary's objective at a stage of attack, such as Initial Access. A technique is a specific method used to reach that objective, such as AI Supply Chain Compromise; some techniques break down into sub-techniques.
What do ATLAS maturity levels mean?
ATLAS rates each technique Feasible (shown in research), Demonstrated (executed against a production-representative system), or Realized (observed in a real incident). Maturity reflects evidence strength, not severity or how likely it is against your systems.
How often is MITRE ATLAS updated?
ATLAS releases monthly, versioned by year and month, such as 2026.07. Because of this cadence, counts change regularly, so check the live matrix before treating any published figure as current.
How can a company start using ATLAS?
Inventory AI systems, pick the most critical one, filter the matrix by its platform, map existing controls to relevant mitigations, identify telemetry gaps, and run a safe tabletop exercise before scaling to other systems.
Does ATLAS replace the NIST AI RMF or OWASP guidance?
No. NIST's framework structures organization-level AI risk governance, OWASP's list prioritizes application-layer LLM risks, and ATLAS supplies detailed adversary-behavior evidence that can inform both; they are complementary, not substitutes.
Key Takeaways
ATLAS gives adversarial AI behavior stable, referenceable identifiers, which is what makes it usable for detection engineering and incident tagging, not just reading.
The 16 tactics run in rough attack-progression order, useful for structuring investigations the way ATT&CK structures conventional ones.
Platform and maturity tags let a team cut the matrix down to a scoped, defensible worklist instead of covering everything equally.
Case studies show how techniques chain together in real incidents and exercises, which is what makes tabletop exercises effective.
Agentic AI is where the matrix is growing fastest, reflecting how quickly organizations are granting AI systems real tool access.
ATLAS and ATT&CK are complementary; most real AI incidents touch both conventional and AI-specific behavior.
No single mitigation eliminates a technique; layered preventive, detective, limiting, and recovery controls are necessary.
Coverage percentages only mean something once mitigations and detections are actually tested against the techniques they claim to address.
Actionable Next Steps
Inventory every AI system currently in production or development, including third-party and embedded features.
Select one critical system to start with, based on data sensitivity or business impact.
Identify which ATLAS platforms apply: Predictive AI, Generative AI, Agentic AI, or a mix.
Map priority tactics and techniques using the platform and maturity filters described in this article.
Review current controls against the ATLAS mitigations linked to your selected techniques.
Define the telemetry needed to detect your highest-priority techniques.
Run a safe, non-operational tabletop or red-team exercise scoped to that one system.
Assign clear owners for each identified control and detection gap.
Record every gap and remediation plan in your existing risk register.
Establish a recurring cadence for reviewing new ATLAS releases and reassessing your inventory.
Glossary
Adversarial machine learning
The study of attacks against machine learning systems and the defenses that counter them.
AI-enabled system
Any system or process that incorporates artificial intelligence or machine learning as part of its function.
AI red teaming
Simulating realistic attacks against an AI system to find weaknesses before real adversaries do.
Agentic AI
AI systems capable of autonomous, multi-step action, often by invoking external tools, rather than only generating text or predictions.
Case study
In ATLAS, a documented incident or exercise mapping real adversary steps to tactics and techniques.
Data poisoning
Manipulating training or fine-tuning data so a model's resulting behavior serves an adversary's goals.
Evasion attack
An input crafted to cause an AI model to produce an incorrect output while appearing normal.
Generative AI
AI systems, such as large language models, designed to generate new content rather than only classify or predict.
Inference
The process of a model producing an output based on a given input.
Large language model
A generative AI model trained on large text data to understand and generate human-like language.
Machine-learning model
A system trained on data to recognize patterns or make predictions.
Mitigation
In ATLAS, a defensive control linked to one or more techniques it helps address.
Model extraction
Rebuilding a functionally similar copy of a model by repeatedly querying it and observing outputs.
Model inversion
Attempting to reconstruct approximations of a model's training data from its outputs or behavior.
Model poisoning
Directly tampering with a model artifact, such as its weights or bundled code, to introduce malicious behavior.
Platform
In ATLAS, a label for the AI system type a technique applies to: Predictive AI, Generative AI, Agentic AI, or Enterprise.
Predictive AI
AI systems designed to classify, score, or predict outcomes, as opposed to generating new content.
Prompt injection
Crafting input that causes a model to ignore its original instructions and follow the attacker's instead.
Retrieval-augmented generation
An architecture where a generative model retrieves external content to inform its response before generating it.
Sub-technique
A more specific variant of an ATLAS technique narrowing the method to a particular context.
Tactic
In ATLAS, the adversary's objective at a given stage of an attack.
Technique
In ATLAS, a specific method an adversary uses to achieve a tactic's objective.
Technique maturity
An ATLAS rating, Feasible, Demonstrated, or Realized, indicating evidence strength, not severity or likelihood.
Threat-informed defense
A security approach that prioritizes defenses based on documented adversary behavior rather than generic risk categories.
Vector database
A database optimized to store and search numerical content representations, commonly used in retrieval-augmented generation.
Sources & References
