Mature security teams already speak ATT&CK. Detections are written against techniques, red team reports are mapped to tactics, and coverage is measured on a matrix. When AI goes into production, the natural question is: where does that fit?
The short answer: partly it fits, partly it does not — and the real incident happens exactly at the seam.
Two matrices, two domains
MITRE ATT&CK catalogues adversary behavior against traditional systems. The tactics are familiar: initial access, execution, persistence, defense evasion, lateral movement, exfiltration. The assumption is a boundary between code and data, and exploitation happens when the attacker crosses that boundary.
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) catalogues adversary behavior against machine learning systems. It reuses ATT&CK's tactical structure but adds what does not exist in the traditional world: model reconnaissance, ML artifact access, training data poisoning, model evasion, membership inference, model extraction.
The difference is not vocabulary. It is surface. ATT&CK describes what the adversary does to the infrastructure. ATLAS describes what they do to the model.
Where the matrices overlap — and where they do not
Some tactics map almost directly. Reconnaissance is reconnaissance; exfiltration is exfiltration. The channel changes, the intent does not.
Others have no counterpart:
- Training data poisoning has no equivalent in ATT&CK. The classic mental model has no room for an attack that changes a system's future behavior by modifying the material it learns from.
- Model evasion — crafting an input the classifier reads differently than a human does — is a class of its own.
- Model extraction through querying is exfiltration with no file movement. No content-based DLP detects it.
And there is the inverse asymmetry: ATLAS does not cover well what happens after the model is compromised. An AI agent running commands on a developer's machine is firmly in ATT&CK territory — Execution, T1059. The technique is classic; only the entry point is new.
The real attack crosses both
That is why mapping an AI incident to a single matrix always leaves gaps. Consider the pattern observed in 2025–2026 incidents involving coding assistants:
- ATLAS — the adversary plants instructions in content the assistant will consume. Indirect prompt injection: no credential, no exploit, just text in the right place.
- ATLAS — the instructions manipulate the model's behavior, bypassing the restrictions defined in the system prompt.
- Seam — the model emits a tool call. Here the attack leaves the ML domain and enters the infrastructure domain. Neither matrix describes that transition well.
- ATT&CK — the tool executes. Command execution, file write, network request. Known techniques, known detections.
- ATT&CK + ATLAS — persistence. If the payload sits in a configuration file, it is ATT&CK. If it sits in the agent's memory or in the vector store, it is ATLAS territory, and there is no standard detection.
CVE-2025-53773 (GitHub Copilot) and CurXecute (Cursor IDE) follow this shape: natural language in, command execution out. GeminiJack showed the zero-click variant with lateral movement across an entire corporate environment. Of the 21 promptware incidents we catalogued between 2025 and 2026, 15 exhibited four or more chained stages — none of them fits entirely inside a single matrix.
The seam is where detection fails
Combine the coverage of both matrices in a typical environment and the detection map looks like this:
- The ATT&CK side — reasonably instrumented. EDR at execution, network logs at exfiltration, identity management at lateral movement.
- The ATLAS side — almost uninstrumented. Few organizations record what entered the context window, what was written to the agent's memory, or what was indexed in the vector store.
- The seam — invisible. A tool call emitted by the model shows up in the log as a legitimate application request. The log records what was done; it does not record which input caused it.
That last line explains why 57% of the catalogued incidents kept persistence active after the initial detection. The organization detected the effect at the ATT&CK layer, remediated there, and the payload stayed at the ATLAS layer — in memory, in the index, in the document.
How to use both in practice
1. Map findings to both matrices, not one. An AI red team report that cites only ATLAS does not speak to the SOC. One that cites only ATT&CK loses the origin of the attack. Every finding should state: ATLAS technique for entry, ATT&CK technique for impact.
2. Instrument the seam first. The highest-return control is not malicious prompt detection — it is correlation. Every tool call initiated by a model must be logged with the identifier of the input that triggered it. Without that, no AI incident investigation reaches root cause.
3. Extend the coverage matrix you already have. If the team already measures ATT&CK coverage, add the ATLAS columns to the same dashboard. Two matrices in two separate reports guarantee nobody looks at the intersection.
4. Treat ATLAS persistence as real persistence. Agent memory, embeddings, and project rules are persistence mechanisms with every relevant property: they survive the session, they influence future execution, they are not inspected. They deserve review, expiration, and logging — the same controls you would apply to a scheduled task.
The role of each framework
Neither matrix is a testing program. They are taxonomies — they exist to name, communicate, and measure coverage, not to tell you what to execute.
That is why our exercises use the Promptware Kill Chain as the operational sequence and map each stage back to ATLAS and ATT&CK. The kill chain defines the path; the matrices provide the common language with the SOC.
Together, the three answer the question the board cares about: not "how many techniques do we cover," but "if the adversary comes in through the model, how far do they get — and at what point do we see it."
To map your AI systems against ATLAS and ATT&CK, take a look at our AI Red Team or talk to the team.