MITRE ATLAS: Extending ATT&CK to Adversarial-ML Threats

Introduction

Machine learning systems now sit in production infrastructure: they rank content, screen transactions, answer customers, and increasingly act on a user’s behalf through tools. They also fail under attack in ways conventional software does not. A deployed model can be evaded by crafted inputs, backdoored through poisoned training data, cloned through repeated queries, or subverted through language alone (Das et al., 2024; Vassilev et al., 2025). For conventional intrusions, defenders share a common behavioral map: MITRE ATT&CK, a curated knowledge base of adversary tactics and techniques grounded in observed incidents (Strom et al., 2020). Machine learning lacked such a map until MITRE released ATLAS, the Adversarial Threat Landscape for Artificial-Intelligence Systems, which applies the ATT&CK model to AI systems (MITRE, 2026).

This paper asks to what extent ATLAS, as an extension of the ATT&CK paradigm, adequately maps the adversarial threat landscape of AI systems, and what indirect prompt injection reveals about the limits of that mapping. I argue that ATLAS is necessary but not sufficient: it gives defenders a shared vocabulary without requiring a new framework, yet it remains descriptive rather than predictive, trails the attacks it catalogs by construction, and pairs a deep technique catalog with thin mitigation guidance.

Methodologically, the paper is a qualitative framework analysis: ATLAS’s primary artifacts (version 5.6.0, April 2026) are read against the peer-reviewed attack literature and adjacent taxonomies (OWASP GenAI Security Project, 2024; Vassilev et al., 2025). Section 1 examines what ATLAS inherits from ATT&CK and what it adds. Section 2 identifies three structural limits. Section 3 uses indirect prompt injection to test these limitations. The paper concludes with a discussion and a look forward.

1. Extending a Trusted Map

ATT&CK’s contribution to conventional security was a shared way of describing adversary behavior (Azyava & Kiselev, 2026). By organizing observed attacks into tactics and techniques curated against real incidents, it gave defenders, vendors, and researchers one vocabulary for describing intrusions (Strom et al., 2020). ATLAS applies the same approach to AI security. The framework reuses the ATT&CK structure wholesale: of its 16 tactics, 14 follow the familiar kill chain from reconnaissance through impact, while only 2 are new and AI-specific: AI Model Access and AI Attack Staging, covering the ways adversaries obtain and exploit access to a model itself(MITRE, 2026; Strom et al., 2020).

The techniques under these tactics cover the major attack classes against ML systems: evasion by crafted inputs, poisoning of training data, extraction of model functionality through queries, and, since 2023, prompt-based subversion of instruction-following models (Biggio & Roli, 2018; MITRE, 2026; Vassilev et al., 2025). Like ATT&CK, ATLAS gates inclusion on evidence and maintains a parallel series of documented case studies, 42 of them as of late 2025, including code execution achieved in the MathGPT application through prompt injection (MITRE, 2026). The data is machine-readable, updated on a monthly release cadence, and mirrored by third-party threat-intelligence tooling.

Reusing ATT&CK also makes ATLAS easier for security teams to adopt. A security team that already runs ATT&CK-based threat modeling, red teaming, or detection engineering can extend those processes to AI systems without learning a new conceptual scheme. It can also help security and ML teams work from the same terminology, giving security engineers and ML engineers, two groups that do not always share the same vocabulary, a common index for discussing threats. Recent research has also made some of these threats more concrete. Carlini et al. (2023) demonstrated that poisoning web-scale training datasets is already practical, and Souly et al. (2025) showed that backdoor poisoning requires a near-constant number of poisoned documents, roughly 250 across model scales from 600 million to 13 billion parameters, giving defenders a better estimate of how practical the attack is.

This is the sense in which ATLAS is necessary. Threats that previously lacked common names can now be referenced with stable identifiers across incident reports, vendor documentation, and academic work. That strength does not resolve the framework’s limitations.

2. The Limits of Description

The first limitation follows directly from ATLAS’s descriptive design. It describes what has been observed, not what is likely or what comes next. A matrix cell records that a technique exists, but assigns no probability, no ranking, and no adversary model from which novel behavior could be anticipated. ATLAS inherits this approach from ATT&CK, where it is a deliberate trade against speculation (Strom et al., 2020), but the tradeoff is more consequential in a field where new attacks can emerge within months, and it leaves risk prioritization, the step defenders actually need, outside the framework. There is a second problem with relying on observed techniques: an established structure can obscure attacks that do not fit its categories. Apruzzese et al. (2022) documented a persistent mismatch between academic adversarial ML and what real attackers do; ATLAS may therefore reproduce gaps between published adversarial-ML research and attacks seen in practice.

A second limitation is the delay that is built into evidence-gated inclusion. ATLAS ships monthly content updates, yet inclusion is evidence-gated, so techniques enter only after public demonstration. The project’s own changelog shows this delay. Prompt injection was named in September 2022 (Willison, 2022) and demonstrated against deployed applications in February 2023 (Greshake et al., 2023); ATLAS catalogued it in October 2023, in version 4.5.0. Retrieval-corpus poisoning entered in March 2025, the triggered injection variant in September 2025 (MITRE, 2026). In each case, ATLAS added the technique after it had already been publicly demonstrated. For fast-moving generative-AI threats, that delay is consequential.

The third limit is the asymmetry between naming attacks and enabling defense. Against roughly one hundred techniques, ATLAS lists on the order of 30 mitigations, and those addressed to generative AI (Guardrails, AML.M0020; Guidelines, AML.M0021; Model Alignment, AML.M0022) can reduce risk but cannot guarantee that an attack fails: filters, rules, classifiers, alignment training (MITRE, 2026). None is an eliminative control, and the framework offers no account of which mitigations suffice against which techniques under what assumptions. The result, then, is a threat model without a security model. ATLAS tells an organization which attacks to consider, but provides much less guidance on designing systems that resist them.

3. The Hard Case: Indirect Prompt Injection

Prompt injection provides a useful test of ATLAS’s limits because its root cause is architectural. A language model does not reliably enforce a security boundary between trusted instructions and untrusted data in its context; role hierarchies can privilege developer instructions, but they do not prevent instructions embedded in untrusted content from influencing model behavior. OWASP ranks the resulting vulnerability class first among risks to LLM applications (OWASP GenAI Security Project, 2024), and ATLAS catalogs it as technique AML.T0051 with direct, indirect, and triggered variants (MITRE, 2026).

The direct form is the familiar one: the attacker is the user, supplying input crafted to override the application’s instructions. Perez & Ribeiro (2022) showed that simple handcrafted prompts sufficed to goal-hijack a production model or leak its system prompt. Direct injection is serious, but partially traceable, because the adversarial channel is known: input can be filtered, privileges can be limited, and the interacting user can be held accountable.

Indirect injection removes even that clear adversarial channel. The adversary never touches the system; the payload waits in content the model will later ingest: a web page, a document, an email, a retrieved passage (Greshake et al., 2023). The party harmed is the legitimate user, who never sees the injected instructions. Greshake et al. (2023) demonstrated the class against real LLM-integrated applications, achieving data theft, remote control, and persistence through poisoned content. Connected to tools and live data, the model’s attack surface becomes everything it reads. Willison (2025) states the resulting condition precisely: an agent that combines access to private data, exposure to untrusted content, and an outbound communication channel gives any successfully injected instruction the user’s read privileges and the agent’s reach. Retrieval pipelines can deliver the same attack at scale; ATLAS’s RAG Poisoning entry (AML.T0070) records corpus seeding as a route to injection at scale (MITRE, 2026).

Existing evaluations suggest that the problem remains unresolved. AgentDojo, an evaluation environment for agents executing tools over untrusted data, pairs 97 realistic tasks with 629 security test cases; its authors report that state-of-the-art models fail many tasks even without attacks, and that existing injection attacks break some security properties but not all (Debenedetti et al., 2024). One of the strongest architectural defenses evaluated on that benchmark, CaMeL, separates control flow from data flow outside the model and still secures only about two thirds of tasks (Debenedetti et al., 2025). No approach evaluated in these studies fully eliminates the vulnerability.

Indirect injection therefore exposes a limitation that the technique catalog alone cannot address. ATLAS catalogs indirect injection promptly and accurately, but the taxonomy does not capture the architectural condition that makes the attack possible. The guardrail-class mitigations it lists sit on the wrong side of that interface, filtering a channel the attack is designed to blend into. A framework whose unit of description is the technique has no obvious place to represent a vulnerability whose effective defense may require architectural change.

4. Discussion

The research question asked to what extent ATLAS, an extension of ATT&CK, adequately maps the adversarial threat landscape of AI systems, and what indirect prompt injection reveals about the limits of that mapping. The analysis supports a two-part answer: ATLAS works well as a common map of known adversarial behavior, but it is incomplete as a basis for defensive design.

The limitation is partly a consequence of what ATLAS was designed to do. Its evidence requirements make the catalog useful as a record of known adversary behavior, while also limiting its ability to anticipate emerging attacks. That tradeoff is manageable when ATLAS is used as a common vocabulary or coverage checklist. It becomes more consequential when organizations rely on it for prospective threat modeling or control selection. Indirect prompt injection makes the distinction especially clear because cataloguing the attack does not resolve the architectural condition that permits it.

For practitioners, this suggests a narrower role for ATLAS. It is useful as a common vocabulary and coverage checklist, particularly across security and ML teams. It should not be treated as a substitute for architectural threat modeling.

5. Future Directions

The limitations identified in this paper are likely to become more important as AI systems become more agentic. First, agentic systems are likely to widen the indirect-injection surface faster than evidence-gated catalogs can document new techniques: as models gain browsing, tool execution, and inter-agent communication, everything they read becomes input, and the conditions identified by the “lethal trifecta” become increasingly common in deployed systems (Willison, 2025). Second, greater cross-mapping between existing frameworks is likely: ATLAS, the OWASP LLM Top 10, and NIST’s taxonomy already describe overlapping territory, and cross-mapping them could reduce duplication and make the frameworks easier to use together (OWASP GenAI Security Project, 2024; Vassilev et al., 2025). Third, recent work such as CaMeL also points toward architectural approaches that constrain what injected instructions can cause (Debenedetti et al., 2025). If these approaches continue to improve, system design and standardized evaluation may therefore become more important parts of AI security assurance. ATLAS could then remain useful as the common vocabulary linking attacks to those evaluations. This leaves at least two directions for further research: systematic audits of ATLAS coverage against incident corpora, and a predictive layer, however coarse, over its descriptive base.