MITRE ATLAS: The Complete Guide to the Adversarial Threat Landscape for AI Systems

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a free, open knowledge base of the real-world tactics and techniques attackers use against AI and machine learning systems. Built and maintained by MITRE, it is modeled directly on the widely adopted MITRE ATT&CK framework. Where ATT&CK maps attacks on conventional IT systems, ATLAS maps attacks on the models, the data, and now the autonomous agents that increasingly run on top of them. As of the current release (v5.x, late 2025), ATLAS documents more than a dozen adversarial tactics and over a hundred techniques, each grounded in observed attacks and reproducible research, all published on the official MITRE ATLAS knowledge base.

This guide is written for security leaders, AI and ML security engineers, and AI red teams who already understand classic threat modeling but want a clear, current picture of how AI systems get attacked. It explains what ATLAS is, why it exists, how it is structured, what its tactics and techniques cover, how it compares to ATT&CK, and how the framework has expanded to cover large language models (LLMs) and AI agents. Then it goes one step further than most explainers. It maps the agent-relevant threats ATLAS documents to the controls that actually reduce them. The through-line is simple. ATLAS is the map of how AI gets attacked, and as agents gain autonomy and tool access, the highest-leverage defense shifts toward identity and authorization: controlling what an agent is, what it can act as, and what it is allowed to do.

What is MITRE ATLAS?

MITRE ATLAS is a structured, living knowledge base that catalogs how adversaries attack artificial-intelligence systems across the full lifecycle, from reconnaissance and model access through to impact. ATLAS stands for the Adversarial Threat Landscape for Artificial-Intelligence Systems. Like ATT&CK, it organizes attacker behavior into tactics (the adversary's goal at each stage) and techniques (the specific methods used to achieve that goal), and it backs them with real-world case studies and recommended mitigations.

What makes the MITRE ATLAS framework distinct is its focus on the parts of an AI system that traditional security tooling was never designed to protect: training data, model files, inference APIs, prompts, retrieval pipelines, and the agentic logic that lets a model take actions in the world. These are the assets adversarial machine learning targets, and they don't behave like ordinary software. A poisoned dataset or a manipulated prompt isn't a buffer overflow, and you can't patch it the same way.

Who created and maintains ATLAS?

ATLAS is created and maintained by MITRE, the same not-for-profit organization behind MITRE ATT&CK, working with a community of contributors from industry, academia, and government. It began as the Adversarial ML Threat Matrix, an open collaboration MITRE published on GitHub, and was later renamed and expanded into ATLAS as a standalone, ATT&CK-styled knowledge base. Because it is community-driven, the catalog evolves as new attack research and real incidents emerge. That is why tactic and technique counts should always be read against the current release rather than treated as fixed.

Is MITRE ATLAS free and open?

Yes. MITRE ATLAS is free and openly available. The full matrix, tactic and technique pages, mitigations, and case studies are published on the official ATLAS website, and supporting artifacts and data are available on MITRE's GitHub. There is no license fee and no gated content. That openness is part of why it has been adopted as a common reference vocabulary for AI security teams, much as ATT&CK became the shared language for enterprise threat detection.

Why MITRE ATLAS exists

AI and ML systems, and the autonomous agents now built on them, are a distinct attack surface that classic ATT&CK-style threat modeling does not fully cover. A model can be attacked through its training data before it is ever deployed. It can be fooled at inference time by inputs crafted to evade it. Its parameters or training data can be stolen by querying it. And once a model is wired into an agent that can call tools, browse, and act, an attacker who manipulates the model's inputs can manipulate the agent's actions.

None of these map cleanly onto the techniques ATT&CK was built to describe. Security teams needed a shared, evidence-based way to reason about AI-specific threats, communicate them across red and blue teams, and check their defenses for gaps. That's where ATLAS comes in. It is a common framework that names AI attacks precisely, ties each to documented evidence, and gives defenders a structure to map their own controls against. The honest framing is that ATLAS does not make AI systems secure on its own. It is a map. Its value is in helping teams see the terrain clearly enough to decide where to invest, and as systems become more agentic, that investment increasingly points at identity and authorization.

How MITRE ATLAS is structured

ATLAS borrows ATT&CK's structure so teams already fluent in ATT&CK can read it quickly. The framework is organized as a layered hierarchy:

• Matrix - the top-level view that arranges tactics as columns and the techniques under each.
• Tactics (AML.TA####) - the adversary's objective at a given stage, such as reconnaissance, initial access, or exfiltration.
• Techniques (AML.T####) - the specific methods used to achieve a tactic, for example evading an ML model or poisoning training data.
• Sub-techniques - more granular variants of a technique.
• Mitigations (AML.M####) - recommended defensive measures mapped to the techniques they address.
• Case studies (AML.CS####) - documented real-world incidents and research demonstrations that show the techniques in action.

Every technique page links to the tactics it serves, the sub-techniques beneath it, the mitigations that reduce it, and the case studies where it appeared. That cross-referencing is what makes ATLAS usable as a working tool rather than a glossary. You can start from a threat and walk to a control, or start from an incident and walk to the techniques it used, all from the MITRE ATLAS knowledge base.

The ATLAS matrix: tactics at a glance

The MITRE ATLAS matrix is the framework's headline view. Reading left to right, it follows the rough arc of an attack on an AI system, from learning about the target to causing impact. The tactics below summarize that arc. Exact IDs, the full technique list under each tactic, and any tactics added in newer releases live on the canonical ATLAS matrix maintained by MITRE, which is the authoritative reference.

Tactic	Adversary goal
Reconnaissance	Gather information about the target AI system, its models, data, and ML supply chain.
Resource Development	Build or acquire the capabilities needed to attack, such as adversarial datasets, proxy models, or tooling.
Initial Access	Get a foothold into the AI system or its development pipeline, including via the ML supply chain.
ML Model Access	Obtain access to the model itself, whether through an inference API, a downloaded artifact, or the physical environment.
Execution	Run adversary-controlled code or instructions, including malicious prompts that drive model or agent behavior.
Persistence	Maintain a foothold, for example through poisoned data, a backdoored model, or poisoned long-term memory.
Privilege Escalation	Gain higher-level permissions, including coaxing an agent into actions beyond its intended scope.
Defense Evasion	Avoid detection by guardrails, filters, or monitoring.
Credential Access	Steal credentials, tokens, or keys the model or agent can reach.
Discovery	Explore the AI environment, its tools, and its connected systems.
Collection	Gather data of interest, such as training data, prompts, or model outputs.
ML Attack Staging	Prepare the actual model attack, for example crafting adversarial examples or a poisoning payload.
Exfiltration	Extract data, model parameters, or other assets from the system.
Impact	Degrade, manipulate, or destroy the AI system or the decisions it drives.

Techniques and sub-techniques

Under each tactic, ATLAS lists the techniques and sub-techniques that achieve it, each with an AML.T#### identifier. Together the MITRE ATLAS tactics and techniques cover the recognizable adversarial-ML methods (evading a model, poisoning training data, extracting a model by querying it) and a growing set of GenAI-specific additions. Recent releases have added techniques for prompt injection, retrieval-augmented generation (RAG) poisoning, and abuse of LLM and agent capabilities. That reflects how the threat landscape has shifted from classic ML toward generative and agentic systems, a shift also catalogued in NIST's taxonomy of adversarial machine learning (NIST AI 100-2e2025).

Mitigations (AML.M)

ATLAS pairs techniques with mitigations identified by AML.M#### IDs. These describe defensive measures such as limiting public model access, validating and sanitizing inputs, controlling the ML supply chain, monitoring model behavior, and restricting the permissions of the systems that act on model output. Mitigations are deliberately framed as guidance rather than products, so teams can map them onto whatever controls they already run.

Case studies (AML.CS)

The MITRE ATLAS case studies (AML.CS####) are what keep the framework grounded. Each is a documented incident or research demonstration showing the techniques used against a real or realistic AI system, from evasion of production classifiers to data exfiltration and model theft. For defenders, the case studies are the fastest way to understand a technique, because they show the attack as a sequence of tactics rather than a single abstract method.

Adversarial machine learning attack classes: a primer

Adversarial machine learning is the study of attacks that target ML models and the systems around them, and the defenses against those attacks. Because many readers know ATT&CK but not the AI-specific threats, here is a plain-English primer on the main classes ATLAS catalogs. Each of these deserves a deeper treatment than a pillar-level primer can give, so use this as orientation and follow the cluster resources for the full attack-by-attack breakdown.

• Evasion - crafting inputs that cause a model to make a wrong prediction at inference time, such as a slightly perturbed image that a classifier misreads, without changing the model itself.
• Data poisoning - corrupting the training data so the resulting model behaves incorrectly or contains a hidden backdoor that the attacker can later trigger.
• Model extraction - repeatedly querying a model to reconstruct a functional copy of it, stealing the intellectual property and effort embedded in the original.
• Model inversion - using model access to recover sensitive information about the data it was trained on, a privacy attack against the training set.
• Prompt injection - embedding adversarial instructions in the text an LLM processes so the model follows the attacker's instructions instead of the developer's, the defining attack against generative systems and the top entry in the OWASP GenAI Security Project's risk lists for LLM applications.
• RAG poisoning - planting malicious content in the documents or knowledge sources a retrieval-augmented system pulls from, so the model is fed attacker-controlled context at answer time.
• Supply-chain attacks - compromising a pre-trained model, dataset, or ML dependency before it ever reaches the victim's pipeline.

For teams securing LLM-based applications, several of these line up directly with the application-level risks in the OWASP Top 10 for LLM applications, which is worth reading alongside ATLAS as the prioritized companion to ATLAS's GenAI techniques.

MITRE ATLAS vs MITRE ATT&CK

The most common question from security teams is how ATLAS relates to ATT&CK. The short answer: ATLAS is purpose-built for AI systems and deliberately modeled on ATT&CK, but it is a separate knowledge base, not a sub-section of it. MITRE ATT&CK describes adversary behavior against enterprise IT, cloud, mobile, and industrial control systems. ATLAS describes adversary behavior against ML models, the data and pipelines that produce them, and the AI applications and agents built on them. Many ATLAS engagements also touch traditional ATT&CK techniques, because attacking an AI system often still involves attacking the infrastructure around it.

Dimension	MITRE ATT&CK	MITRE ATLAS
Primary attack surface	Enterprise IT, cloud, endpoints, mobile, OT/ICS	ML models, training data, ML pipelines, LLMs, and AI agents
Structure	Tactics, techniques, sub-techniques, mitigations	Same structure, plus case studies, with AML-prefixed IDs
Signature threats	Phishing, lateral movement, credential theft, ransomware	Evasion, data poisoning, model extraction, prompt injection, RAG poisoning
Maturity	Long-established, broad industry adoption	Newer and fast-evolving, especially around GenAI and agents
Relationship	The model ATLAS is built on	An AI-specific complement that reuses ATT&CK's conventions

This section is a summary. A side-by-side breakdown of how the two frameworks map onto each other technique by technique, and when to use which, will live on our dedicated MITRE ATLAS vs MITRE ATT&CK comparison guide.

MITRE ATLAS for LLMs and AI agents

ATLAS started in the world of classic ML, but its most active growth is in generative AI and agents. As organizations moved from predictive models to LLM-powered applications, and then to autonomous agents that call tools, browse, and execute multi-step plans, ATLAS expanded to document the new behaviors attackers use against them. This is where the framework becomes most relevant to teams shipping AI products today.

The agent and LLM threats ATLAS and the broader community track include:

• Prompt injection and jailbreaking - overriding the model's instructions through crafted input, directly or indirectly via content the model ingests.
• RAG and memory poisoning - corrupting the documents an agent retrieves or the long-term memory it persists, so attacker context shapes future actions.
• Tool misuse - manipulating an agent into calling its connected tools and APIs in harmful ways, including over connectors such as the Model Context Protocol. The standardized way agents reach tools and data brings its own attack surface, covered in our guide to MCP security risks.
• Excessive agency - exploiting an agent that has been granted more autonomy or permission than its task requires.
• Agent goal hijack - redirecting an agent's objective so it pursues the attacker's goal while appearing to do its job.
• Identity, credential, and tool-API abuse - using the agent's own identity, tokens, and tool access to reach systems and data it should not.

These agent threats are now codified directly in the OWASP Top 10 risks for agentic AI security, which names tool misuse, memory and context poisoning, and agent identity and privilege abuse among the leading risks. They are the heart of agentic AI security, and they connect ATLAS to the practical question every team deploying agents now faces: how do you keep an autonomous, tool-using system from being turned against you? For the architecture and governance view of bringing those controls together in production, see our guide to building a secure enterprise AI platform. The answer, as the mitigation section argues, leans heavily on identity and authorization.

How defenders use MITRE ATLAS

ATLAS is most valuable as a working tool, not a reading list. Security teams use it in three main ways:

• Threat modeling - walk the matrix against your own AI system and ask, for each tactic, whether an adversary could achieve that objective and what would stop them. The result is a structured, AI-specific threat model instead of an ad-hoc list.
• AI red teaming - use ATLAS techniques and case studies as a test plan, attempting evasion, poisoning, prompt injection, and tool abuse against your models and agents to find what actually works before an adversary does. Our guide to AI red teaming walks through adversarial testing for AI and LLMs end to end.
• Control-gap mapping - map your existing detections and mitigations to ATLAS techniques to see which threats you cover, which you only partially cover, and which you miss entirely.

A practical way to start: pick one production AI system, list the tactics that are realistic against it, mark the techniques you have evidence you can detect or block, and treat the blanks as your backlog. The framework turns "are we secure?" into a set of specific, answerable questions.

Tools that support ATLAS

Several tools make ATLAS easier to operationalize. The MITRE ATLAS Navigator lets teams visualize the matrix and annotate it with their own coverage, much like the ATT&CK Navigator. ATLAS also publishes adversary emulation resources, and the community has built plugins that extend the CALDERA automated adversary-emulation platform with ATLAS techniques, alongside efforts to share real AI incidents. These resources are published on the MITRE ATLAS site and let teams move from reading the matrix to exercising it.

Mitigating ATLAS threats, including agent identity and authorization

Most ATLAS explainers stop at "use it for threat modeling." That leaves the most important question unanswered. Once you know how AI gets attacked, what do you actually do about it? The table below maps agent-relevant ATLAS-style threats to the concrete controls that reduce them. It is not exhaustive, but it shows the shape of a real defense program.

ATLAS-relevant threat	Concrete controls that reduce it
Data poisoning and supply-chain compromise	Provenance and integrity checks on datasets and models, vetted model sources, signed artifacts, pipeline access control.
Evasion and model extraction	Rate limiting and abuse monitoring on inference APIs, output throttling, anomaly detection on query patterns.
Prompt injection and jailbreaking	Input and output validation, content guardrails, separation of trusted instructions from untrusted content, monitoring of model behavior.
RAG and memory poisoning	Source vetting and integrity checks on retrieval corpora and persisted memory, provenance tracking on retrieved context.
Tool misuse and excessive agency	Least-privilege scoping of every tool and API an agent can call, human-in-the-loop approval for high-impact actions, action logging.
Agent goal hijack and identity/credential abuse	Strong agent identity, scoped and short-lived credentials, per-action authorization, and full audit trails.

Agent identity and least-privilege authorization as a first-class mitigation

Look closely at the bottom rows of that table and a pattern emerges. The most dangerous agent threats ATLAS and the agentic-security community document (tool misuse, excessive agency, agent goal hijack, and identity, credential, and tool-API abuse) all share a root cause: an agent that can act with more identity and more privilege than its task requires. When an autonomous agent holds broad, long-lived credentials and unrestricted tool access, a single successful prompt injection or hijack converts directly into real-world action. The model is the entry point, but identity and authorization are what turn a manipulated model into damage.

This is why, as agents gain autonomy, the highest-leverage defense moves from filtering inputs to constraining what the agent is allowed to be and do. Treating agent identity and least-privilege authorization as a first-class mitigation means giving each agent its own verifiable identity rather than a shared service account, scoping its permissions to exactly the tools and data its task needs, issuing short-lived and narrowly scoped credentials instead of standing secrets, authorizing actions individually rather than trusting the agent wholesale, and logging every action for audit. Done well, an agent that is hijacked can still only do the small set of things it was ever permitted to do.

This is the discipline Frontegg treats as core to agentic AI security: agents are non-human identities that need authentication, authorization, and lifecycle management just like users do, and least-privilege agent authorization (where an agent inherits scoped roles and permissions rather than blanket access) is what contains the blast radius when something upstream goes wrong. The principles behind treating agents as non-human identities that need authentication, authorization, and lifecycle management map directly onto the agent threats ATLAS documents. Frontegg's Agent IAM applies this model directly, letting agents act under least-privilege authorization tied to human roles and permissions, so an agent never holds access beyond what its operator could grant. If your team is moving from experimenting with agents to deploying them against real systems and data, an end-to-end identity and authorization layer built for AI agents is the control that maps most directly onto the agent threats ATLAS documents. For how this fits into the wider stack, see how identity and authorization come together on an enterprise AI platform.

MITRE ATLAS alongside NIST and OWASP frameworks

ATLAS does not live in isolation. It sits in a landscape of AI-security and AI-risk frameworks that overlap and complement each other, and orienting among them is part of using ATLAS well. The table below is a quick map.

Framework	What it is	How it relates to ATLAS
MITRE ATLAS	Knowledge base of adversary tactics and techniques against AI systems	The "how AI gets attacked" map; the others reference or complement it
NIST AI 100-2	NIST's taxonomy of adversarial machine learning attacks and mitigations	A standards-grade taxonomy of adversarial machine learning (NIST AI 100-2e2025) covering the same attack classes ATLAS catalogs (evasion, poisoning, privacy, prompt injection, agent threats)
NIST AI RMF	The NIST AI Risk Management Framework: Govern, Map, Measure, Manage	The NIST AI Risk Management Framework (Govern, Map, Measure, Manage) is the governance baseline that tells you how to manage AI risk; ATLAS feeds the "Map" and "Measure" functions with concrete threats
OWASP LLM and Agentic Top 10	OWASP's prioritized lists of top risks for LLM applications and agentic AI	The OWASP Top 10 risks for agentic AI (prompt injection, tool misuse, agent identity and privilege abuse, memory poisoning) overlap heavily with ATLAS's GenAI and agent techniques

In practice, teams use the NIST AI RMF to set governance, ATLAS and NIST AI 100-2 to enumerate threats, and the OWASP lists to prioritize application-level risks. For LLM applications specifically, the OWASP Top 10 for LLMs is the most direct companion to this guide.

Frequently asked questions

What is MITRE ATLAS?

MITRE ATLAS is a free, open knowledge base that documents the real-world tactics and techniques adversaries use to attack AI and machine learning systems, including LLMs and AI agents. It is maintained by MITRE and structured like the MITRE ATT&CK framework, with tactics, techniques, mitigations, and case studies.

What does ATLAS stand for?

ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems.

Who created and maintains MITRE ATLAS?

ATLAS is created and maintained by MITRE, the not-for-profit organization behind MITRE ATT&CK, with contributions from a community across industry, academia, and government. It began as the Adversarial ML Threat Matrix before being expanded into ATLAS.

Is MITRE ATLAS free and open source?

Yes. The full matrix, tactics, techniques, mitigations, and case studies are published openly on the official ATLAS website, and supporting data and artifacts are available on MITRE's GitHub. There is no license fee.

What is the difference between MITRE ATLAS and MITRE ATT&CK?

ATT&CK maps adversary behavior against conventional IT, cloud, and similar systems. ATLAS maps adversary behavior against AI and ML systems, including models, training data, pipelines, LLMs, and agents. ATLAS reuses ATT&CK's structure and conventions but is a separate, AI-specific knowledge base, not a part of ATT&CK.

How many tactics and techniques does MITRE ATLAS have?

As of the current release (v5.x, late 2025), ATLAS includes more than a dozen tactics and over a hundred techniques and sub-techniques, with the catalog growing as new GenAI and agent threats are documented. Because ATLAS is a living framework, check the canonical ATLAS matrix for exact, current counts.

What is the MITRE ATLAS matrix?

The ATLAS matrix is the top-level view of the framework, arranging tactics as columns and the techniques under each. It lets defenders see the full landscape of AI attack behavior at a glance and is the starting point for threat modeling and control-gap mapping.

What is adversarial machine learning?

Adversarial machine learning is the study of attacks that target ML models and the systems around them, such as evasion, data poisoning, model extraction, model inversion, and prompt injection, along with the defenses against those attacks. ATLAS catalogs these attack classes as techniques.

Does MITRE ATLAS cover LLMs and AI agents?

Yes. ATLAS has expanded well beyond classic ML to document GenAI and agentic threats, including prompt injection, RAG and memory poisoning, tool misuse, excessive agency, agent goal hijack, and identity and credential abuse.

How do you use MITRE ATLAS for threat modeling and red teaming?

For threat modeling, walk the matrix against your AI system and identify which tactics and techniques are realistic and what would stop them. For red teaming, use ATLAS techniques and case studies as a test plan to attempt those attacks against your models and agents. Tools like the ATLAS Navigator and CALDERA plugins help operationalize both.

How does MITRE ATLAS relate to the NIST AI RMF and OWASP LLM Top 10?

They are complementary. The NIST AI RMF provides governance (Govern, Map, Measure, Manage), NIST AI 100-2 provides a standards-grade adversarial-ML taxonomy, and the OWASP LLM and Agentic Top 10 prioritize application-level risks. ATLAS supplies the detailed, evidence-based catalog of attacker techniques that feeds the threat-mapping and measurement work in those frameworks.

How does agent identity and authorization reduce ATLAS-documented risks?

Many of the most damaging agent threats ATLAS documents (tool misuse, excessive agency, goal hijack, and identity or credential abuse) stem from agents that hold more identity and privilege than their task needs. Giving each agent a distinct identity, scoping its permissions to least privilege, issuing short-lived credentials, and authorizing actions individually limits what a hijacked or manipulated agent can do, containing the blast radius. This is the discipline behind treating AI agents as non-human identities with managed authentication and authorization.

Related resources

MITRE ATLAS is the hub of a broader AI Agent Security topic. To go deeper, explore the related guides in the cluster:

• OWASP Top 10 for LLMs - the application-level risk list that pairs directly with ATLAS's GenAI techniques.
• Enterprise AI platform - how identity, authorization, and security controls come together for AI agents in production.
• MCP security risks - the risks of connecting agents to tools and data via the Model Context Protocol.
• AI red teaming - a hands-on guide to adversarial testing for AI and LLMs, including testing against the ATLAS matrix.
• MITRE ATLAS vs MITRE ATT&CK - a deeper, technique-by-technique comparison of the two frameworks. (Cluster page to be created.)
• Adversarial ML attacks explained - a deep dive on poisoning, evasion, extraction, and model manipulation. (Cluster page to be created.)