MITRE ATLAS: Mapping Adversarial Threats to AI Systems

What MITRE ATLAS Is and Why It Exists

MITRE ATLAS is a globally accessible knowledge base of adversary tactics, techniques, and case studies documenting real-world and demonstrated attacks against AI-enabled systems. It is maintained by MITRE Corporation and grew out of an earlier project known as the Adversarial ML Threat Matrix before being expanded and rebranded as ATLAS.

The framework exists because traditional IT threat models do not adequately describe how adversaries target machine learning systems, including training pipelines, model artifacts, and inference interfaces. ATLAS gives security teams a shared vocabulary for classifying these behaviors rather than treating each AI incident as a novel, unclassified event.

For enterprises deploying AI and agentic systems without a standardized taxonomy, this matters directly: it is difficult to align threat intelligence, build detection logic, or design controls around adversarial AI behavior without a common reference structure that names and organizes those behaviors consistently.

ATLAS vs. ATT&CK: Structural Differences

Both frameworks share the same tactic-and-technique matrix structure and are maintained by MITRE, which means security teams already familiar with ATT&CK can apply their existing workflow to ATLAS without learning an entirely new methodology. The key differences are in scope and attack surface.

Dimension	MITRE ATLAS	MITRE ATT&CK
Primary scope	AI and machine learning systems	Enterprise IT infrastructure
Attack surfaces covered	Training data, model artifacts, inference APIs, agentic pipelines	Endpoints, networks, cloud, identity
Technique examples	Prompt injection, model extraction, data poisoning, evasion	Phishing, credential dumping, lateral movement
Case studies	Documented adversarial ML incidents mapped to techniques	Extensive real-world APT campaign documentation
Tooling integration	Limited; requires custom engineering	Wide native support in SIEM and detection platforms
Maturity	Actively evolving, especially for generative AI	Mature, extensively validated

Mapping ATLAS Tactics to the AI System Lifecycle

ATLAS techniques are organized around the AI system lifecycle, distinguishing attacks that target training data and model development from attacks targeting deployed inference endpoints. Because ATLAS mirrors ATT&CK's structure, security teams already using ATT&CK-based threat modeling can extend existing processes rather than adopting an entirely separate methodology.

The practical value comes from walking each stage of an AI system architecture against the matrix to identify where specific tactic categories apply.

Reconnaissance & Resource Development

Adversary preparation targeting model information and infrastructure.

ML Model Access

Techniques for reaching training data, model artifacts, or inference endpoints.

Execution & Persistence

Running adversarial inputs or maintaining access within AI pipelines.

Defense Evasion

Techniques designed to bypass detection of adversarial behavior.

Exfiltration & Impact

Data or model theft and degradation of AI system integrity.

Techniques, Case Studies, and Coverage Gaps

ATLAS technique entries include categories addressing large language model-specific adversarial behavior, such as prompt-based manipulation of model outputs, alongside longer-standing techniques like data poisoning and model extraction that document both training-time and runtime attacks. A dedicated case studies section maps documented real-world adversarial ML incidents to specific ATLAS techniques, which is useful for grounding abstract technique names in observed behavior.

However, this is a narrative technique-to-incident mapping, not a comprehensive incident database comparable to CVE-style vulnerability tracking. Technique granularity also varies: some entries map cleanly to well-documented academic adversarial ML research, while others are newer and less thoroughly connected to mitigation guidance.

Complementary Framework: NIST AI 100-2

NIST's adversarial machine learning taxonomy (NIST AI 100-2) complements ATLAS by formalizing terminology for attack classes including evasion, poisoning, privacy attacks, and abuse attacks. Referencing both frameworks together helps standardize language across security and AI governance teams.

Operationalizing ATLAS Into Runtime Controls

ATLAS itself does not prescribe implementation-level control configurations, so security teams should treat the matrix as a checklist during threat modeling exercises rather than a plug-and-play control set. Turning tactic and technique categories into concrete defenses requires separate architectural and runtime design work.

Use the ATLAS matrix during threat modeling to confirm relevant tactic categories are considered for each AI system component, including agentic and generative elements not exhaustively pre-mapped by ATLAS.
Distinguish training-time attack surfaces from runtime attack surfaces so controls are enforced at the correct architectural layer rather than applied uniformly.
Enforce model access boundaries, such as API gateway authentication on inference endpoints, to address techniques ATLAS classifies under ML Model Access and Exfiltration.
Deploy runtime enforcement controls including input validation, output filtering, and rate limiting on inference endpoints, designed specifically for the techniques they are intended to mitigate.
Establish logging and observability at the inference layer, since detecting ATLAS-classified techniques such as prompt injection or extraction attempts in production traffic depends on this visibility existing beforehand.
Map ATLAS techniques to SOC detection rules or SIEM use cases through custom engineering, since ATLAS does not natively integrate with most commercial detection tooling.

Governance Considerations for Using ATLAS

Adopting ATLAS as an organizational reference involves clarifying its role in governance documentation and keeping pace with its evolution as generative AI attack surfaces expand.

Use ATLAS as a common taxonomy for documenting AI-specific risks in enterprise risk registers to align security and AI governance functions.
Reference ATLAS techniques alongside NIST's adversarial ML taxonomy to standardize terminology in internal risk assessments and audit documentation.
Clarify in governance documentation that ATLAS is a threat and technique reference framework, not a compliance standard or certification scheme.
Do not assume ATLAS provides exhaustive coverage of generative AI and agentic system risks, since this area of the framework is still evolving.
Review ATLAS updates periodically and incorporate new techniques into existing risk assessments rather than treating the matrix as static.

Frequently Asked Questions

Is MITRE ATLAS a compliance framework or a threat reference?

ATLAS is a threat reference framework, not a compliance standard or certification scheme. It provides a taxonomy for naming and organizing adversarial AI behaviors, but it does not specify required controls or define compliance obligations. Organizations use it to inform threat modeling, risk registers, and control design, not to satisfy a regulatory requirement directly.

How does ATLAS relate to MITRE ATT&CK?

ATLAS uses the same tactic-and-technique matrix structure as ATT&CK and is maintained by the same organization. The key difference is scope: ATT&CK covers enterprise IT infrastructure, while ATLAS focuses specifically on AI and machine learning attack surfaces including training pipelines, model artifacts, and inference endpoints. Security teams already using ATT&CK can extend existing threat modeling workflows to incorporate ATLAS without adopting an entirely separate methodology.

Does ATLAS cover generative AI and agentic system threats?

ATLAS includes technique categories for large language model-specific adversarial behavior such as prompt injection. However, coverage of generative AI and agentic system threats is still evolving. Organizations deploying these systems should not assume ATLAS provides exhaustive coverage and should supplement the matrix with their own threat modeling for novel agentic architectures.

How do security teams operationalize ATLAS in practice?

The most practical approach is to use the ATLAS matrix as a structured checklist during threat modeling sessions, walking each AI system component against relevant tactic categories. Because ATLAS does not natively integrate with most commercial SIEM or detection platforms, translating technique categories into detection rules requires custom engineering. Runtime controls such as input validation, output filtering, and inference-layer observability then need to be designed and deployed separately based on identified threats.

What is the relationship between ATLAS and NIST AI 100-2?

NIST AI 100-2 is an adversarial machine learning taxonomy that formalizes terminology for attack classes including evasion, poisoning, privacy attacks, and abuse attacks. It complements ATLAS by providing more rigorous definitional structure for attack categories. Referencing both frameworks together is useful for standardizing terminology across security and AI governance teams and for producing audit documentation that aligns with multiple reference points.

Turn Threat Mappings Into Enforced Controls

Understanding ATLAS tactics and techniques is the first step. Applying them to agent permissions, tool approvals, and inference-layer enforcement in production is where runtime governance becomes necessary.

Explore Runtime Governance