What is MITRE ATLAS?

By Nolan Sullivan, Founding Growth Engineer

·Published October 23, 2026

Conventional threat frameworks describe attacks on networks, endpoints, and identities. They have no entry for poisoning a training dataset, extracting a model through its API, or hiding instructions in a document an agent will read. MITRE ATLAS fills that gap. MITRE describes it as “a globally accessible, living knowledge base of adversary tactics and techniques involving AI”, covering attacks against AI-enabled systems, abuse or manipulation of AI capabilities, and harmful autonomous behavior that AI makes possible.

ATLAS is most useful as a shared vocabulary. A security team can describe an AI threat with an ATLAS technique ID, and a red team, a detection engineer, and an auditor will all look up the same entry. ATLAS describes what attackers do and leaves the controls to the organization, which is why most teams pair it with a governance framework and their own defensive architecture.

All figures on this page come from the September 2026 release (v2026.09), published September 15, 2026. ATLAS ships content updates monthly, so treat every count here as a snapshot and check atlas.mitre.org for the current numbers.

Who maintains MITRE ATLAS?

MITRE, the not-for-profit that also maintains MITRE ATT&CK, maintains ATLAS. The data lives in a public GitHub repository, mitre-atlas/atlas-data, which publishes each monthly release with a changelog. Content versions follow a YYYY.MM scheme, so 2026.09 is the September 2026 release.

Industry input comes through the Center for Threat-Informed Defense, a non-profit research and development consortium operated by MITRE. Its Secure AI project works with funded research participants to accelerate ATLAS development in three areas: incident sharing, new threats to generative AI, and mitigations. Organizations can also contribute incident data to the project directly.

What is in the MITRE ATLAS matrix?

The ATLAS matrix arranges techniques under the tactics they serve, the same layout security teams know from ATT&CK. Six kinds of content sit in and around it:

1. Tactics. The adversary’s goal at a stage of an attack, such as Reconnaissance or Exfiltration. IDs take the form AML.TA####.
2. Techniques and sub-techniques. How an adversary achieves a tactic. LLM Prompt Injection is technique AML.T0051, and its Indirect variant is sub-technique AML.T0051.001.
3. Mitigations. Security concepts and classes of controls that counter one or more techniques, with IDs in the form AML.M####.
4. Case studies. Documented attacks, each broken into steps that link to the techniques used. A case study is either an Incident (a real-world attack) or an Exercise (a red team or research demonstration). IDs take the form AML.CS####.
5. Maturity ratings. Every technique is rated Feasible (shown in a research setting), Demonstrated (shown in a red team exercise or against a realistic AI system), or Realized (used by a threat actor in a real-world incident).
6. Platform tags. Each technique lists the kinds of system it applies to: Predictive AI, Generative AI, Agentic AI, or Enterprise, the last meaning the conventional IT components of an AI-enabled system. One technique can carry several tags.

The v2026.09 release notes give these headline counts:

The ATLAS homepage shows “208 techniques” because it counts techniques and sub-techniques together (120 plus 88). Both figures describe the same release. Older figures still circulate on third-party pages, including the ATLAS section of our own AI security frameworks comparison, which cites v5.1.0 from November 2025. The atlas-data repository is the source to trust for any count.

What are the MITRE ATLAS tactics?

The v2026.09 matrix has 16 tactics. Fourteen are adapted from ATT&CK, and the dataset records the ATT&CK tactic each one corresponds to. Two have no ATT&CK equivalent: AI Model Access, which covers the different levels of access an adversary can gain to a model, from full knowledge of its internals to querying it through a product, and AI Attack Adaptation, which covers turning general attack methods into attack-ready outputs for a specific target. AI Attack Adaptation was named AI Attack Staging until the v2026.08 release.

The table lists tactics in ATLAS ID order. The matrix on the ATLAS site arranges them in attack-lifecycle order instead, the way ATT&CK does.

MITRE ATLAS vs MITRE ATT&CK: what is the difference?

ATT&CK catalogs adversary behavior against conventional enterprise, mobile, and industrial control systems. ATLAS catalogs adversary behavior against AI-enabled systems. The structure is shared: tactics, techniques, sub-techniques, mitigations, and case studies, with similar ID conventions and a Navigator for both.

The two are designed to be used together. An attack on an AI system rarely stays inside the model. The Postmark case study described below starts with a malicious npm package, which is ordinary supply chain compromise, and ends with data leaving through email, which is ordinary exfiltration. ATLAS reuses ATT&CK tactics so a team can trace that whole chain in one vocabulary, adding the AI-specific techniques where ATT&CK has nothing to say.

ATT&CK is older and has more built around it, including the ATT&CK Evaluations program that tests security products against its techniques. ATLAS borrows the structure so that teams that already threat model with ATT&CK can extend the same process to AI systems instead of starting a second one.

How does MITRE ATLAS cover AI agents?

Agentic AI is now the most common platform tag in ATLAS. In v2026.09, 139 of the 208 technique and sub-technique entries carry it, compared with 106 for Generative AI, 85 for Enterprise, and 82 for Predictive AI. ATLAS defines the tag as covering attacks on AI components that can autonomously plan, decide, and execute multi-step actions, including their memory, tool use, and workflow orchestration. Of the entries tagged Agentic AI, 57 are rated Realized.

Three entries show how this looks in practice:

• Prompt injection. LLM Prompt Injection (AML.T0051) has three sub-techniques: Direct, Indirect, and Triggered. The parent technique is rated Realized. For the attack itself, see what is prompt injection.
• Tool poisoning. ATLAS lists AI Agent Tool Poisoning (AML.T0110) alongside related entries for poisoned agent tools and tool data. The same class of attack against Model Context Protocol (MCP) servers is covered in MCP tool poisoning.
• An agent supply chain incident. Case study Poisoned Postmark MCP Server Email Exfiltration (AML.CS0053) records an attacker who registered the postmark-mcp package name on npm, published legitimate versions until the package passed 1,000 downloads a week, and then shipped a version that added the attacker’s address to the BCC line of every email the tool sent.

The mitigations side has agent-specific entries too, such as Human In-the-Loop for AI Agent Actions (AML.M0029) and Restrict AI Agent Tool Invocation on Untrusted Data (AML.M0030). For a deeper walk through the agent techniques, including a step-by-step reading of the Postmark attack chain, read MITRE ATLAS is now an agent security framework.

Is MITRE ATLAS a compliance framework?

ATLAS is a reference knowledge base. It has no requirements to meet, no audit, and no certification, and an organization cannot be “ATLAS compliant”. It also does not prescribe a security architecture. Its mitigations name classes of control, such as restricting tool invocation on untrusted data, without specifying how to build them into identity, network, or application design.

Teams pair ATLAS with frameworks that do set requirements or rank risks:

• NIST AI Risk Management Framework. A voluntary governance process for identifying and managing AI risk across an organization. ATLAS supplies the threat detail a NIST AI RMF risk assessment needs.
• ISO/IEC 42001. A certifiable management-system standard for AI. ATLAS can inform the risk assessment it requires, but certification is against the standard, not against ATLAS. See ISO 42001 for agentic AI.
• OWASP Top 10 lists. Ranked vulnerability lists for LLM applications, agentic applications, and MCP. They answer “what is most likely to go wrong in my application”, where ATLAS answers “what has an adversary done, and how”.

A side-by-side comparison of NIST AI RMF, ATLAS, and the OWASP lists is in AI security frameworks compared.

How do security teams use MITRE ATLAS?

There are four common uses, listed here from least to most effort:

1. Communicating AI risk. ATLAS IDs and tactic names give a security team a way to report AI threats to executives and auditors in a structure they already recognize from ATT&CK. It needs no tooling, so it is the cheapest place to start.
2. Threat modeling. Walk an AI system through the 16 tactics and mark which techniques apply, using the platform tags to filter. An internal support agent with tool access would start from the Agentic AI and Generative AI entries.
3. Red team planning. Scope an AI red team exercise around specific techniques and case studies, then record results against the same IDs. The case studies double as test scenarios.
4. Detection and prioritization. Use the maturity ratings to decide what to detect first. A Realized technique has been used in a real incident; a Feasible one has only been shown in research. The 24 Feasible entries in v2026.09 matter for long-range planning, but rarely belong at the top of a detection backlog.

The ATLAS Navigator, based on the ATT&CK Navigator, is the usual tool for the middle two. It lets a team color and annotate techniques, save the result as a layer, and share it. Each atlas-data release also publishes Navigator layers for every case study and a frequency layer showing how often each technique appears across case studies, along with the full dataset as YAML, STIX, and Excel. The data is published under the Apache License 2.0.

Where does MITRE ATLAS fall short?

ATLAS is stronger on attacks than on defenses. Release v2026.09 has 40 mitigations for 208 technique entries, so many techniques share the same broad mitigation, and turning that guidance into specific controls is left to each team. ATLAS also has no view of a particular organization: it cannot say which techniques an organization is exposed to, or whether its controls work.

The monthly release cadence is useful for keeping up with new attacks, but it means a threat model built against one version drifts as entries are added, renamed, and re-rated. The September 2026 release alone added six techniques and five sub-techniques, and the release before it renamed a tactic. Record the ATLAS version a threat model was built against, and review it when a release touches the techniques it relies on.

A note on Speakeasy

An ATLAS threat model for AI agents usually ends with questions about runtime: which tools agents call, who can reach which servers, and what gets flagged or blocked. The Speakeasy AI Control Plane is a managed platform that answers some of those questions. Its MCP gateway can limit which servers and tools each team can connect to, Tool Logs record the tool calls it observes, audit logs track administrative changes, and Guardrails can flag or block secrets, sensitive data, and prompt injection in agent traffic, with shadow AI discovery available to every organization.

These are controls a team can choose after its threat model, and they cover only the traffic that passes through the gateway. If you are threat modeling your agents with ATLAS, we’d be interested to hear how you’re approaching it.