MITRE ATLAS explained: tactics, techniques and tests.

What is MITRE ATLAS?

MITRE ATLAS, the Adversarial Threat Landscape for AI Systems, is a public knowledge base of how adversaries attack systems that include machine learning or generative AI. It records what attackers try to achieve, the techniques they use to get there, and the documented cases where those techniques were shown to work.

MITRE publishes it twice over: as a browsable matrix on atlas.mitre.org,1 and as versioned data in a public repository, where it describes ATLAS as a knowledge base of adversary tactics, techniques and procedures targeting AI systems.2 This piece uses release 2026.09, dated 15 September 2026.3

If you know MITRE ATT&CK, the shape is familiar on purpose. Fourteen of the sixteen ATLAS tactics point to an ATT&CK tactic, from Reconnaissance to Impact. Two exist only in ATLAS, because they only make sense against AI: AI Model Access and AI Attack Adaptation.4

How is ATLAS organised?

Three layers do the work. A tactic is the adversary’s goal at a step, such as Initial Access or Exfiltration. A technique is how they reach it, such as LLM Prompt Injection, AML.T0051. A sub-technique is a variant, such as AML.T0051.001, the indirect form. Release 2026.09 holds 16 tactics, 120 techniques and 88 sub-techniques, with 40 mitigations and 73 case studies alongside (Fig. 1).5

Every technique carries two tags that make the knowledge base practical. Platforms say which kind of system it applies to: predictive AI, generative AI, agentic AI or the enterprise around them. In this release Agentic AI is the most common tag, on 139 of 208 technique and sub-technique entries. A maturity level, from feasible to realized, says how far the technique has been taken.6

The mitigations sit on the other side of the same links. Each one is tagged as a policy measure, an AI-specific technical control or a conventional cyber control, and each points at the techniques it addresses. That makes the matrix usable in both directions: from a technique to the controls that blunt it, and from a control you already have to the techniques it leaves uncovered.

The case studies are what keep it honest. Of the 73, 50 are exercises, red team and research demonstrations, and 23 are incidents. Each one is written as a sequence of techniques, which is exactly the form a test plan needs.5

How does ATLAS compare with the OWASP Top 10?

They look at the same systems from opposite ends. The OWASP Top 10 for LLM Applications ranks what can go wrong in an application; ATLAS describes what an attacker does to make it go wrong. The 2026 OWASP edition maps its risks to ATLAS, so the two meet in the ids.7

In a report we use both. Each finding gets its OWASP id, so a reader knows which risk it is, and its ATLAS technique, so a defender knows what the attacker did and what to watch for. Our guide to the OWASP Top 10 for LLM Applications 2026 covers the other side.

How do ATLAS ids become a test plan?

We start from our own catalogue of 54 test categories, the things we check in an AI or stack engagement. Every AI category lists the ATLAS techniques it exercises. Rolled up to parent techniques, that is 32 of the 120 in this release, and the count is recomputed whenever the catalogue or the release changes.

We track sub-techniques where the difference changes the test, such as direct and indirect prompt injection, and count parents where it does not. Releases add and retire ids, so the site’s own build checks every ATLAS id in the plan against the pinned release and refuses to publish a plan that cites an id the release no longer has. The same rule applies to a report: it names the release it was mapped to.

Fig. 1 shows where the plan sits. It is dense in Execution, Persistence, Defense Evasion, Exfiltration and Impact, the steps that happen inside your system. It is empty in Reconnaissance, Resource Development, AI Model Access, AI Attack Adaptation and Command and Control. Those describe what an attacker does on their own side, before and around the attack, and an authorized test of your application has no reason to reproduce them.

How should defenders use ATLAS?

Use it to ask better questions of your own system. Walk the rows of Fig. 1 that apply to you and, for each technique, ask three things: could an attacker do this here, would we notice, and what would stop it? The second question is the easiest to skip. A feature that logs only the user’s message and the final answer misses the retrieved passages, the tool calls and the arguments the model chose, which is where most of these techniques leave their traces.

For the third question, ATLAS links each technique to mitigations. LLM Prompt Injection alone has seven, among them AI Red Team, AI Telemetry Logging and input and output validation for agent components.8

For agents, start where the agent acts. Prompt injection steers it; AI Agent Tool Invocation turns that into actions; AI Agent Context Poisoning keeps it steered; Exfiltration via AI Agent Tool Invocation carries data out in an action that looks legitimate.9 Our prompt injection explainer follows that chain end to end.

The defensive takeaway: a technique id in a report should point to a test that actually ran, and to a control that would have stopped it. An id on its own is a label, not a finding.