MITRE ATLAS: The AI Threat Framework Every Security Leader Needs to Know
In March 2016, Microsoft launched Tay, a Twitter-based chatbot designed to learn from conversations with users and respond in kind. Within 24 hours, some Twitter users began trolling it, tweeting, among other things, politically incorrect phrases and sending it inflammatory messages until it began producing them on its own. Microsoft pulled the plug the next day.
The attack wasn’t sophisticated in any traditional sense. No CVE was exploited. No credentials were stolen. No network was breached. It was simply provided inputs through the interface the system was designed to accept, and the model’s own learning mechanism turned those inputs into a weapon against itself. If you tried to map that attack to MITRE ATT&CK at the time, you’d come up empty. The attack surface wasn’t an endpoint or a network. It was the model’s relationship with its training data.
That gap, the space between what ATT&CK covers and what AI systems actually expose, is exactly what MITRE ATLAS was built to fill.
ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It’s a structured knowledge base of adversary tactics, techniques, and real-world case studies specifically targeting AI and machine learning systems. Think of it as ATT&CK’s purpose-built extension into territory that traditional threat frameworks never modeled: data pipelines, model architectures, inference APIs, and training processes. As of today, ATLAS documents 16 tactics and 167 techniques across 57 case studies, with 35 mapped mitigations, and the framework is actively growing.
Where This Started
ATLAS began in late 2020 as a collaboration between MITRE and Microsoft, with twelve industry and academic partners, under the blunter name Adversarial ML Threat Matrix. The original repository still lives at github.com/mitre/advmlthreatmatrix.
The project was justified by a pattern of high-profile ML failures. Google’s image recognition system was fooled by adversarial stickers. Amazon’s Alexa was triggered by ultrasonic commands embedded in bird chirps. Tesla’s Autopilot was steered into oncoming traffic by three small road stickers, at roughly $0 cost and without exploiting any software vulnerability. And then there was Tay. Four incidents, four companies, four different attack mechanisms, united only by the fact that the target in each case was the AI system’s behavior, not its infrastructure. A survey of 28 organizations conducted around the same time found that 25 of them didn’t know how to secure their ML systems. Industry wasn’t behind on patches. It was behind on the vocabulary needed to think about the problem systematically.
MITRE’s AI Security 101 resource at atlas.mitre.org/resources/ai-security-101 frames why AI attacks require a different analytical lens through three dimensions:
AI Access Time refers to whether an attack occurs during training, when the model is still being shaped by data, or during inference, when it’s responding to live queries.
AI Access Points covers whether the adversary reaches the model digitally via an API or physically by modifying real-world inputs, such as a sticker on a road sign or a sound pattern near a microphone.
System Knowledge covers whether the adversary has white-box access to the model architecture and weights or operates in a black-box manner, probing only the inputs and outputs via an API. Most real-world attacks are black-box, and adversaries have learned to do significant damage without ever seeing model weights.
These three dimensions explain why AI attacks don’t map cleanly onto ATT&CK. An adversary targeting an ML system doesn’t necessarily need a foothold on a server. API access and a few thousand queries may be enough.
How ATLAS Builds on ATT&CK
ATLAS was consciously modeled on ATT&CK: the same tactic-technique matrix structure, the same case-study grounding, and the same community contribution model. Security teams already know how to use ATT&CK, and ATLAS doesn’t ask them to learn a new mental model, just extend an existing one.
ATT&CK Enterprise has 14 tactics. ATLAS has 16. Most overlap directly and are adapted to describe how familiar attack phases look when the target is an AI system. Two new tactics have no ATT&CK equivalent.
AI Model Access covers how adversaries reach the target model itself, through an inference API, a stolen artifact, or an offline copy built through iterative querying. You can’t run AI-specific attacks without first getting to the model in some form, and traditional attack chains have no equivalent requirement. Every technique under this tactic is ATLAS-native.
AI Attack Staging is the most technically distinctive column in the matrix. It describes the preparation phase unique to AI attacks: crafting adversarial data, building proxy models for offline testing, and verifying that an attack works before deploying it against production. An adversary poisoning a production model doesn’t just submit corrupted data and hope. They build a local approximation, test inputs against it, refine until the attack reliably produces the desired output, then execute. Like AI Model Access, every one of AI Attack Staging’s entries is ATLAS-native. No equivalent exists in ATT&CK because this class of preparation didn’t exist as a documented threat category before AI systems became production infrastructure.
Beyond the 167 ATLAS-native techniques, the matrix incorporates 98 ATT&CK-adapted techniques that MITRE doesn’t count in its headline figure. Those inherited techniques carry a clear signal: when traditional TTPs appear in AI system attacks, adversaries are usually targeting the underlying infrastructure, API keys, data servers, and GPU compute, rather than the model itself. ATLAS doesn’t pretend that the threat disappears just because the target system has a neural network.
Sixteen Tactics and a Prioritization Tool
The 16 ATLAS tactics run left to right in rough attack-progression order, which can be read in four groups, which I’ll call preparation, establishment, exploitation, and objectives.
Preparation covers Reconnaissance, Resource Development, Initial Access, and AI Model Access. Reconnaissance in an AI attack might mean querying a public API to map model behavior or scraping job postings to identify what ML frameworks a target uses. Resource Development covers building attack inputs, including poisoned datasets, crafted prompt libraries, and hallucinated entities published to contaminate retrieval systems. Initial Access includes an AI supply chain compromise, prompt injection via public-facing applications, and phishing targeting engineers with access to the training infrastructure.
Establishment covers Execution, Persistence, and Privilege Escalation. Persistence in an AI system looks different from traditional IT. An adversary might poison a RAG (Retrieval-Augmented Generation) knowledge base so that malicious content survives model updates. Or they embed a backdoor trigger in a fine-tuned model that stays dormant until a specific input activates it. For Privilege Escalation, the two ATLAS-native techniques are AI Agent Tool Invocation and LLM Jailbreak. Both reflect the same underlying risk: an agentic AI system that can take actions on behalf of users becomes a potential bridge between a sandboxed AI environment and the resources beneath it.
Exploitation covers Defense Evasion, Credential Access, Discovery, Lateral Movement, and Collection. Defense Evasion is the most populated tactic in the matrix: 15 ATLAS-native techniques plus 26 ATT&CK-adapted entries in that column, covering everything from AI supply chain reputation inflation to manipulating a user’s LLM chat history to cover attack traces.
Objectives cover AI Attack Staging, Command and Control, Exfiltration, and Impact. Exfiltration under ATLAS includes techniques specific to AI systems: extracting an LLM’s system prompt, inducing data leakage through crafted queries, or using model response rendering to exfiltrate information. Impact includes Cost Harvesting and resource exhaustion attacks that inflate inference bills on a victim’s API account, alongside data destruction and service denial.
MITRE also publishes an ATLAS Knowledge Graph that's worth bookmarking alongside the matrix. Where the matrix shows tactics and techniques in column-row format, the graph shows the relationships between them: how a technique connects to its mitigations, which case studies demonstrate it in practice, and how tactics link to one another across an attack chain. You can filter by entity type to focus on tactics and techniques or mitigations; search by ID when working with specific techniques; and enter focus mode on any node to expand its immediate network. For threat modeling, it's a faster way to answer "what mitigates this specific technique" than to navigate the matrix column by column. The graph was added in Website v4.12.0, alongside the Data v5.5.0 update in March 2026, and reflects the same 167 techniques, 35 mitigations, and 57 case studies cited throughout this article.
The Maturity Slider: A Practical Prioritization Tool
The live matrix includes a filter that deserves more attention than it typically gets. The maturity slider lets you filter techniques by evidence level across three tiers. Feasible means the technique works in a research setting. Demonstrated means it’s been proven in a red-team exercise or against a realistic AI system. Realized means a threat actor has used it in a confirmed real-world incident.
Of 167 ATLAS-native techniques, 121 carry a maturity rating. The remaining 46, mostly newer agentic AI additions, haven’t been assessed yet. Of the 121 rated techniques, 50 appear in the Realized tier.
Fifty techniques confirmed in actual threat-actor operations against AI systems. This isn’t theoretical anymore.
The distribution is instructive. Resource Development has 9 of 13 rated techniques Realized, indicating that adversaries are actively building poisoned datasets, hallucinated entities, and compromised models as part of their operational tradecraft. AI Attack Staging has 4 Realized out of 6, a high ratio for a tactic that describes specialized preparation work. Discovery and Credential Access each show only 1 Realized technique despite having 9 and 6 rated, respectively, suggesting that the reconnaissance and credential-theft phases of AI attacks remain more theoretical than operational in documented incidents. That gap is worth noting when prioritizing defensive investments.
The Realized filter is a built-in prioritization shortcut. With 167 techniques in the full matrix, knowing which 50 are confirmed adversary behavior gives you a defensible, evidence-based starting point for threat modeling.
What the Case Studies Tell Us
ATLAS launched with 13 case studies drawn from real incidents. Four that hold up well as illustrations: VirusTotal Poisoning, where adversaries submitted adversarial samples to corrupt a shared malware detection service; Bypassing Cylance's AI Malware Detector, where researchers studied the product's public API behavior to craft evasion inputs; Tay poisoning; and GPT-2 model replication through iterative API querying. The full case study library now documents 57 incidents and exercises. Two recent additions stand out. The iProov deepfake case documents adversaries using face-swap tools and virtual camera injection to defeat liveness detection in banking KYC (Know Your Customer) systems. SesameOp documents adversaries turning a legitimate AI service API into a covert command-and-control channel, hiding malicious traffic inside normal AI workflow activity.
Each case study is labeled either “Incident” for confirmed real-world attacks or “Exercise” for red-team and research demonstrations. That distinction is visible on each case study page and is worth checking before treating any entry as evidence of active adversarial use. Not all 57 carry equal operational weight, but the labeled distinction makes it straightforward to tell them apart.
What This Means for CISSP Holders
ATLAS isn’t just for ML engineers. Two domains make it directly relevant to security leaders.
Domain 1, Security and Risk Management. Most risk registers in use today don’t include entries for AI Attack Staging, Functional Extraction, or Inversion Attacks. ATLAS gives practitioners the vocabulary to translate “our AI system might be vulnerable” into specific, structured threat scenarios that map to controls and drive prioritized remediation.
Domain 8, Software Development Security. On the ATLAS mitigations page, each of the 35 mitigations is tagged to the phase of AI development it applies to, from initial data collection through model deployment and ongoing monitoring. If you've spent time mapping security controls to software development phases, this is the same idea applied to AI systems. It tells the team building or buying an AI system, where in the process, each defense needs to go, not just what the defense is.
On the regulatory side, the EU AI Act's obligations for general-purpose AI models became active in August 2025, with the broader high-risk AI system framework following in August 2026. For the largest frontier GPAI models (those deemed to carry systemic risk), Article 55 of the Act already requires providers to conduct and document adversarial testing. For organizations deploying high-risk AI systems, the compliance deadline arrives in August 2026.
For ecosystem fit: ATLAS works alongside other frameworks rather than replacing them. Pair it with the NIST AI RMF's Measure function for risk quantification, the OWASP LLM Top 10 for application-level vulnerability coverage, and ISO/IEC 42001 for governance structure. ATLAS covers the adversarial tactics and techniques layer, which is what attackers actually do, a piece that the others largely leave undefined.
Two limitations worth naming. First, ATLAS is still catching up to agentic AI. The late 2025 and early 2026 updates added significant new coverage of AI agent techniques, but Realized technique counts in that area remain low. The framework is reacting to, not predicting, how attackers use autonomous AI systems. Second, ATLAS explicitly does not yet cover what MITRE calls "Malicious Use of AI," meaning AI as a weapon rather than as a target. AI-enhanced phishing, AI-powered reconnaissance, AI-automated attack development against conventional infrastructure: none of that fits the current TTP structure, and MITRE says so directly. The framework tells you how to defend your AI systems. It doesn’t yet systematically address how AI is changing attacks against your non-AI systems.
ATLAS is the shared language AI security has needed. The framework at atlas.mitre.org is free, open, and actively maintained. The only barrier to using it is not knowing it exists.
