MITRE ATLAS
MITRE ATLAS: The ATT&CK Matrix for AI Systems
At a glance (v5.4.0, Feb 2026)
- 15 tactics
- 84 techniques
- 56 sub-techniques
- 32 mitigations
- 42 real-world case studies
- 2 tactics that exist nowhere else
If you already work with MITRE ATT&CK, you have the mental model. ATLAS is the same idea applied to the part of your estate that ATT&CK never covered: the model, the training data, the prompt, the retrieval store and the agent’s tools.
First, the name
There is no framework called “ATT&CK for AI”. The MITRE matrix for AI is ATLAS - Adversarial Threat Landscape for Artificial-Intelligence Systems. It is built deliberately in the shape of ATT&CK, uses the same tactic-and-technique grammar and the same ID scheme (AML.TA for tactics, AML.T for techniques), and is meant to sit beside ATT&CK rather than replace it. If someone hands you a requirement that says “map our AI systems to ATT&CK”, ATLAS is what they need.
ATT&CK itself did change in 2026 - version 19 split Defense Evasion into Stealth and Defense Impairment - but it gained no AI domain. The AI coverage lives in ATLAS, and ATLAS is where the fast-moving work is happening.
How the matrix is built
Fifteen tactics, in the order an attacker moves through them. Thirteen are borrowed straight from ATT&CK and re-interpreted for AI. Two exist only here, and they are the reason the framework needed to exist at all.
ML Model Access (AML.TA0004) has no equivalent in enterprise ATT&CK. It describes the degrees of access an attacker can have to a model, which is what determines every attack that follows: full white-box access to weights, access to the inference API only, access through a product that embeds the model, or physical access to the environment. An attacker with query-only API access can still extract training data or replicate the model - just more slowly and more noisily.
ML Attack Staging (AML.TA0012) covers the preparation nobody sees: training a proxy model to craft transferable adversarial examples, backdooring a model, verifying an attack offline before firing it at the real system. This is the AI equivalent of building tooling in a lab, and it happens entirely outside your network.
Command and Control (AML.TA0015) arrived in November 2025, and its arrival says something. C2 in an AI matrix only makes sense once the AI system can act - once it is an agent with tools rather than a model that answers questions. The documented case study, SesameOp (AML.CS0042), used an AI assistant API itself as a covert C2 channel.
What changed in 2025 and 2026
ATLAS was, for its first years, a matrix about machine learning models: poison the training set, evade the classifier, steal the weights. Between October 2025 and February 2026 it became a matrix about agents.
The October 2025 release added fourteen agent-focused techniques in one go. November 2025 (v5.1.0) took the technique count from 66 to 84 and added the Command and Control tactic. February 2026 (v5.4.0) added “Publish Poisoned AI Agent Tool” and “Escape to Host”, plus further Model Context Protocol techniques.
The ones worth knowing by ID, because they will appear in supplier questionnaires and pentest reports:
AML.T0058 AI Agent Context Poisoning - planting content that the agent will read and treat as instruction. The technique that makes indirect prompt injection a documented, mappable adversary behaviour rather than a research curiosity.
AML.T0059 Activation Triggers - a payload that stays dormant until a specific condition appears. The reason agent memory belongs in your forensic scope.
AML.T0061 AI Agent Tools - abusing the tools the agent legitimately holds. Nothing is exploited; the capability is simply pointed somewhere else.
AML.T0062 Exfiltration via AI Agent Tool Invocation - data leaving through the agent’s own HTTP or file tool, in traffic that looks like the agent doing its job.
AML.T0096 AI Service API - added in 2026, covering the hosted model API as an access path in its own right.
The case studies are the useful part
Forty-two documented real-world incidents, each mapped to the techniques it used. This is what separates ATLAS from a threat taxonomy: you can take an incident chain that actually happened and check whether your controls would have caught it at any step.
The 2025-2026 additions are pointed. The iProov case (November 2025) shows a mobile KYC liveness check defeated with a deepfake fed through a virtual camera - relevant to any financial entity doing remote onboarding. Three MCP server compromise studies landed in January 2026. The Hugging Face repository cases cover supply-chain compromise through model misidentification: the attacker does not break your model, they get you to download theirs.
Using it without turning it into a paper exercise
The failure mode with any MITRE matrix is the heat map - a coloured grid produced once, shown to a steering committee, never acted on. Three things make ATLAS actually earn its keep.
Scope it to the systems you have. Most organisations are not training models. If you consume hosted models and build agents on top, the tactics that matter are ML Model Access (you have API-level access, so does an attacker), Initial Access, Execution, Command and Control, Exfiltration and Impact. Half the matrix is irrelevant to you, and saying so in writing is a legitimate scoping decision.
Pick three case studies and walk them. Not all forty-two. Choose the ones that resemble your setup, and for each step ask what control would have stopped it and whether you have it. This produces findings; a full-matrix coverage assessment produces a colour chart.
Write the mitigation IDs into your existing framework. ATLAS ships 32 mitigations. They map onto controls you probably already have under ISO 27001 or your DORA framework - access control, logging, supplier management, input validation. Referencing AML.M identifiers in your existing control set is cheaper and more durable than running a parallel AI security programme.
Where it fits with everything else
ATLAS tells you what the adversary does. It does not tell you what to build - that is D3FEND on the defensive side and ISO/IEC 42001 on the governance side. And it is not a compliance framework: nothing in the EU AI Act requires ATLAS. It is, however, the most credible way to answer the question an auditor or a customer will eventually ask, which is how you know your AI systems are being attacked and how you would find out.
One caveat worth stating plainly: the counts above are the February 2026 release. ATLAS has shipped several versions a year and the agentic section is where most of the movement is, so check atlas.mitre.org before quoting numbers in a document that will be read six months from now.
Related
Agentic security - prompt injection and agent privileges
MITRE D3FEND - the defensive counterpart
The EU AI Act - deadlines and obligations
ISO/IEC 42001 - the AI management system standard
There is no framework called “ATT&CK for AI”. The MITRE matrix for AI is ATLAS - Adversarial Threat Landscape for Artificial-Intelligence Systems. It is built deliberately in the shape of ATT&CK, uses the same tactic-and-technique grammar and the same ID scheme (AML.TA for tactics, AML.T for techniques), and is meant to sit beside ATT&CK rather than replace it. If someone hands you a requirement that says “map our AI systems to ATT&CK”, ATLAS is what they need.
ATT&CK itself did change in 2026 - version 19 split Defense Evasion into Stealth and Defense Impairment - but it gained no AI domain. The AI coverage lives in ATLAS, and ATLAS is where the fast-moving work is happening.
How the matrix is built
Fifteen tactics, in the order an attacker moves through them. Thirteen are borrowed straight from ATT&CK and re-interpreted for AI. Two exist only here, and they are the reason the framework needed to exist at all.
ML Model Access (AML.TA0004) has no equivalent in enterprise ATT&CK. It describes the degrees of access an attacker can have to a model, which is what determines every attack that follows: full white-box access to weights, access to the inference API only, access through a product that embeds the model, or physical access to the environment. An attacker with query-only API access can still extract training data or replicate the model - just more slowly and more noisily.
ML Attack Staging (AML.TA0012) covers the preparation nobody sees: training a proxy model to craft transferable adversarial examples, backdooring a model, verifying an attack offline before firing it at the real system. This is the AI equivalent of building tooling in a lab, and it happens entirely outside your network.
Command and Control (AML.TA0015) arrived in November 2025, and its arrival says something. C2 in an AI matrix only makes sense once the AI system can act - once it is an agent with tools rather than a model that answers questions. The documented case study, SesameOp (AML.CS0042), used an AI assistant API itself as a covert C2 channel.
What changed in 2025 and 2026
ATLAS was, for its first years, a matrix about machine learning models: poison the training set, evade the classifier, steal the weights. Between October 2025 and February 2026 it became a matrix about agents.
The October 2025 release added fourteen agent-focused techniques in one go. November 2025 (v5.1.0) took the technique count from 66 to 84 and added the Command and Control tactic. February 2026 (v5.4.0) added “Publish Poisoned AI Agent Tool” and “Escape to Host”, plus further Model Context Protocol techniques.
The ones worth knowing by ID, because they will appear in supplier questionnaires and pentest reports:
AML.T0058 AI Agent Context Poisoning - planting content that the agent will read and treat as instruction. The technique that makes indirect prompt injection a documented, mappable adversary behaviour rather than a research curiosity.
AML.T0059 Activation Triggers - a payload that stays dormant until a specific condition appears. The reason agent memory belongs in your forensic scope.
AML.T0061 AI Agent Tools - abusing the tools the agent legitimately holds. Nothing is exploited; the capability is simply pointed somewhere else.
AML.T0062 Exfiltration via AI Agent Tool Invocation - data leaving through the agent’s own HTTP or file tool, in traffic that looks like the agent doing its job.
AML.T0096 AI Service API - added in 2026, covering the hosted model API as an access path in its own right.
The case studies are the useful part
Forty-two documented real-world incidents, each mapped to the techniques it used. This is what separates ATLAS from a threat taxonomy: you can take an incident chain that actually happened and check whether your controls would have caught it at any step.
The 2025-2026 additions are pointed. The iProov case (November 2025) shows a mobile KYC liveness check defeated with a deepfake fed through a virtual camera - relevant to any financial entity doing remote onboarding. Three MCP server compromise studies landed in January 2026. The Hugging Face repository cases cover supply-chain compromise through model misidentification: the attacker does not break your model, they get you to download theirs.
Using it without turning it into a paper exercise
The failure mode with any MITRE matrix is the heat map - a coloured grid produced once, shown to a steering committee, never acted on. Three things make ATLAS actually earn its keep.
Scope it to the systems you have. Most organisations are not training models. If you consume hosted models and build agents on top, the tactics that matter are ML Model Access (you have API-level access, so does an attacker), Initial Access, Execution, Command and Control, Exfiltration and Impact. Half the matrix is irrelevant to you, and saying so in writing is a legitimate scoping decision.
Pick three case studies and walk them. Not all forty-two. Choose the ones that resemble your setup, and for each step ask what control would have stopped it and whether you have it. This produces findings; a full-matrix coverage assessment produces a colour chart.
Write the mitigation IDs into your existing framework. ATLAS ships 32 mitigations. They map onto controls you probably already have under ISO 27001 or your DORA framework - access control, logging, supplier management, input validation. Referencing AML.M identifiers in your existing control set is cheaper and more durable than running a parallel AI security programme.
Where it fits with everything else
ATLAS tells you what the adversary does. It does not tell you what to build - that is D3FEND on the defensive side and ISO/IEC 42001 on the governance side. And it is not a compliance framework: nothing in the EU AI Act requires ATLAS. It is, however, the most credible way to answer the question an auditor or a customer will eventually ask, which is how you know your AI systems are being attacked and how you would find out.
One caveat worth stating plainly: the counts above are the February 2026 release. ATLAS has shipped several versions a year and the agentic section is where most of the movement is, so check atlas.mitre.org before quoting numbers in a document that will be read six months from now.
Related
Agentic security - prompt injection and agent privileges
MITRE D3FEND - the defensive counterpart
The EU AI Act - deadlines and obligations
ISO/IEC 42001 - the AI management system standard
DORA
Awareness
Get in touch
Email us
info (a) CyberSchild (.) com
Call us
+423 793 7175
Follow us
-
Twitter
-
Linkedin
Erstellt mit
