MITRE ATLAS: From AI Attack Techniques to Compliance Controls

Key takeaways

• MITRE ATLAS is a free, living knowledge base of how attackers actually target AI systems, organised into 16 tactics and 84 techniques drawn from real incidents and red-team work.
• It extends the logic of MITRE ATT&CK to the machine-learning attack surface, covering threats such as data poisoning, model evasion and prompt injection that classic security frameworks never described.
• ATLAS, the OWASP LLM Top 10 and the NIST AI RMF are complementary layers (threats, application vulnerabilities, governance), not competing standards.
• The attack classes ATLAS catalogues are the same ones the EU AI Act obliges high-risk providers to defend against, which turns ATLAS into compliance evidence rather than a security curiosity.
• The practical win is mapping each ATLAS technique to a control and a piece of audit evidence inside your AI governance program.

What is MITRE ATLAS?

MITRE ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE describes it as a globally accessible, living knowledge base of adversary tactics and techniques against AI-enabled systems based on real-world attack observations and realistic demonstrations from AI red teams. In plain terms, it is a structured map of how people attack AI, built from incidents that have actually happened rather than from hypothetical worry. As of version 5.4.0 (February 2026), the ATLAS matrix holds 16 tactics, 84 techniques, 56 sub-techniques, 32 mitigations and 42 documented case studies. Those case studies are concrete rather than academic: deepfake-based identity-verification bypass, machine-learning model evasion, backdoored AI agents, and financial transactions hijacked through AI assistants. The framework exists because AI adds an attack surface that traditional security models were never built to describe. A model can be corrupted during training, fooled at inference time, or interrogated until it leaks the data it learned from. ATLAS gives security and governance teams one vocabulary for those failure modes, so a red-team finding, a control owner and an auditor can all point at the same technique and mean the same thing. For a regulated organisation, that shared language is the first step toward treating AI security as a governance discipline rather than a one-off project. It is also why AI Sigil treats ATLAS as a reference layer underneath its risk and control model.

MITRE ATLAS vs MITRE ATT&CK

If you have worked in security operations, ATLAS will feel familiar, and that is deliberate. It is modelled on the MITRE ATT&CK methodology: the same idea of tactics (the attacker’s goal at each stage) and techniques (how they achieve it), arranged as a matrix you read left to right across the adversary lifecycle. The difference is the target. ATT&CK describes attacks on conventional IT: endpoints, networks, identities. ATLAS describes attacks on the AI itself, the model, the training data, the inference pipeline and the agents built on top. Several ATLAS tactics are shared with ATT&CK (reconnaissance, initial access, exfiltration, impact) because attackers still phish, still move laterally, still steal credentials. What ATLAS adds is the AI-specific middle: gaining access to a model, poisoning its training data, crafting inputs that evade it, or extracting it wholesale. The takeaway for governance teams is not to choose between the two. ATT&CK covers the infrastructure around the model; ATLAS covers the model. A serious AI attack usually travels through both.

Inside the MITRE ATLAS matrix: the 16 tactics

The matrix is best read as a lifecycle. An adversary starts with reconnaissance (studying your model, its API, its public documentation), moves through resource development and initial access, then reaches the AI-specific stages: ML model access, ML attack staging, execution, persistence, exfiltration and impact. Each tactic holds techniques that describe a concrete move. Four technique families matter most for governance because they map onto named regulatory risks:

• Data poisoning. Manipulating the training data so the model learns the wrong thing, whether a hidden backdoor or a general degradation in accuracy.
• Model evasion (adversarial examples). Crafting inputs designed to make a deployed model make a mistake, for example a subtly altered image or a jailbreak prompt that defeats a safety filter.
• Model extraction and inversion. Querying a model until you can reconstruct it or recover the confidential data it was trained on, a confidentiality attack.
• Prompt injection and jailbreaks. Hijacking a language model or an AI agent through crafted instructions hidden in content it processes.

These families line up cleanly with the official US taxonomy. NIST AI 100-2 E2025, the federal taxonomy of adversarial machine learning, sorts attacks on predictive AI into evasion, poisoning and privacy, and attacks on generative AI into prompt injection, jailbreaks and supply-chain compromise. ATLAS supplies the field-tested techniques; NIST supplies the formal terminology. Using them together gives you both the what and the how.

ATLAS, the OWASP LLM Top 10 and the NIST AI RMF

One of the most common questions is how ATLAS relates to the other AI security and governance frameworks. The short answer is that they operate at different altitudes and were designed to be used together.

• MITRE ATLAS is an adversary model. It answers “how would someone attack this system?” and is built for threat modelling, red teaming and detection engineering.
• The OWASP LLM Top 10 is a vulnerability model. It answers “what tends to be wrong in LLM applications?” (prompt injection, insecure output handling, training-data poisoning and so on) and is built for secure development and code review.
• The NIST AI RMF is a governance model. Its four functions, Govern, Map, Measure and Manage, answer “how does our organisation oversee AI risk?” and are built for risk managers and compliance teams.

These are layers, not alternatives: the threat (ATLAS), the weakness it exploits (OWASP), and the oversight that decides what to do about it (NIST). The practical reason this matters is cost. According to Vectra’s analysis of the matrix, roughly 70% of ATLAS mitigations map to security controls organisations already run. You are rarely building from zero; you are connecting an AI threat to a control you already own and proving the link. AI Sigil’s governance resources treat the three frameworks as a single stack rather than competing checklists.

Why MITRE ATLAS matters for compliance, not just security

Here is the part most ATLAS explainers skip. The framework is usually presented as a tool for the security operations centre. For a regulated organisation it is also a compliance instrument, because the attacks it catalogues are the attacks the law now names. The EU AI Act, Article 15, requires that high-risk AI systems achieve “an appropriate level of accuracy, robustness, and cybersecurity”. It goes further in paragraph 5: high-risk systems “shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities”. The same paragraph then names the threats by category. Technical solutions must, where appropriate, address “attacks trying to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws”. Read that list again next to the ATLAS technique families above. They are the same threats. The Act states the obligation; ATLAS provides the operational catalogue that lets you show how you meet it. When an assessor asks how you address adversarial examples or data poisoning, “we mapped the relevant ATLAS techniques to controls and tested them” is a far stronger answer than a policy statement. The same logic extends upward: the EU’s GPAI Code of Practice expects adversarial testing for general-purpose models with systemic risk, and ATLAS is a natural source for the test cases. This is the reframing that wins. ATLAS is not only a way to detect attacks. It is a way to evidence that you anticipated them.

Operationalising ATLAS inside an AI governance program

Moving ATLAS from a reference poster to a working part of governance comes down to one chain: threat to control to evidence. Threat. For each AI system in your inventory, select the ATLAS techniques that actually apply. A public-facing LLM assistant faces prompt injection and jailbreaks; a fraud model trained on third-party data faces poisoning; a model exposed through an API faces extraction. You do not need all 84 techniques, only the ones your architecture invites. Control. Map each selected technique to a system control. Because most ATLAS mitigations correspond to existing security controls, this is usually a matter of connecting an AI threat to access management, input validation, monitoring, supply-chain checks or red-team testing you can already point to. Where a genuine gap exists, you have just found a control to build. Evidence. Attach proof that the control works: a red-team report against the technique, a poisoning-detection test result, an access log, a sign-off. This is what turns a control from a claim into an audit artefact. That chain is exactly what the NIST AI RMF Measure and Manage functions ask for, and it aligns with the Annex A controls of ISO 42001, the certifiable AI management system standard. It also clarifies accountability: under the AI Act a provider owns the robustness built into the model, while a deployer owns the conditions of use, so the same ATLAS technique can generate obligations for both parties. A platform such as AI Sigil exists to hold that mapping, threats, controls, evidence and obligations, in one place so the chain is auditable rather than rebuilt from memory at assessment time.

Getting started with MITRE ATLAS

You do not need a large program to begin. A first pass looks like this:

1. Inventory your AI systems and note, for each, the model type, the data sources and how it is exposed.
2. For each system, shortlist the ATLAS techniques that are plausible given that architecture.
3. Assess your current control coverage against that shortlist and record where you are strong and where you are exposed.
4. Prioritise the gaps by impact, starting with systems that are high-risk under the AI Act or business-critical.
5. Document the evidence for the controls that already work, so nothing is lost before the next audit.
6. Review quarterly, because ATLAS is a living framework and your model estate changes.

For regulated teams, add one column to that exercise: the obligation each technique helps satisfy. That single link, from ATLAS technique to regulatory duty, is what converts a security checklist into governance.

Frequently asked questions

What is MITRE ATLAS? MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a free, living knowledge base of the tactics and techniques attackers use against AI systems, based on real-world observations and red-team demonstrations. The current matrix holds 16 tactics and 84 techniques, organised like the MITRE ATT&CK framework but focused on machine learning. What is the difference between MITRE ATLAS and MITRE ATT&CK? ATT&CK describes attacks on conventional IT systems (endpoints, networks, identities). ATLAS describes attacks on AI systems themselves: the model, its training data and its inference pipeline. ATLAS reuses the ATT&CK structure and shares some tactics, but adds AI-specific techniques such as data poisoning, model evasion and model extraction. What is the difference between MITRE ATLAS and the OWASP LLM Top 10? They solve different problems. ATLAS is an adversary model used for threat modelling and red teaming. The OWASP LLM Top 10 is a list of the most common vulnerabilities in LLM applications, used for secure development. ATLAS tells you how you might be attacked; OWASP tells you what tends to be weak. They are complementary. How many tactics does MITRE ATLAS have? As of version 5.4.0 (February 2026), the ATLAS matrix has 16 tactics, alongside 84 techniques, 56 sub-techniques, 32 mitigations and 42 case studies. Older references that cite 14 tactics predate recent updates, so always check the current matrix at atlas.mitre.org. Is MITRE ATLAS required by the EU AI Act? The AI Act does not name ATLAS, so it is not mandatory. However, Article 15 requires high-risk AI systems to be resilient against data poisoning, model poisoning, adversarial examples and confidentiality attacks, which are exactly the threats ATLAS catalogues. Using ATLAS is a practical way to organise and evidence the technical solutions the Act expects. How does MITRE ATLAS relate to the NIST AI RMF? They work at different levels. ATLAS is a threat catalogue; the NIST AI RMF is a governance framework built around Govern, Map, Measure and Manage. In practice ATLAS feeds the Measure and Manage functions: it provides the concrete threats you assess and treat, while the RMF provides the oversight structure around them.

Conclusion

Most teams meet MITRE ATLAS as a security artefact, a matrix of attacks for the red team to study. That view is correct but incomplete. For any organisation operating AI under regulation, ATLAS is the bridge between two worlds that usually talk past each other: the security team that knows how AI is attacked, and the compliance team that has to prove the system is robust. Its techniques are the AI Act’s named threats made concrete, and mapping them to controls and evidence is what an audit ultimately wants to see. Start small, with one system and its plausible techniques, and grow the map from there. If you want that mapping to live in one auditable place, see how AI Sigil connects AI threats, controls and obligations.