MITRE ATLAS: mapping an attack on an AI system

If NIST AI RMF tells you how to organise AI risk work, MITRE ATLAS tells you what attackers actually do. ATLAS stands for Adversarial Threat Landscape for AI Systems, and its maintainers describe it as “a public knowledge base of adversary TTPs targeting AI systems”, where TTPs are tactics, techniques and procedures. Teams use it the way they use any threat knowledge base: to plan tests, to describe findings in a shared language and to check that defences cover realistic attack paths.

How ATLAS is organised

• Tactics are the adversary’s goals at each stage. The ATLAS matrix shows 16 columns: Reconnaissance, Resource Development, AI Attack Adaptation, Initial Access, AI Model Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration and Impact.
• Techniques are the ways a tactic is achieved, with sub-techniques for variants. In the data, tactic IDs look like AML.TA0005, techniques like AML.T0051 and sub-techniques like AML.T0051.001.
• Mitigations (AML.M####) are defensive measures linked to the techniques they reduce.
• Case studies (AML.CS####) are documented attacks, marked as either an incident or an exercise, with each step tied to a technique and a tactic.

The 2026.09 release of the ATLAS data, dated 15 September 2026, contains 16 tactics, 208 technique and sub-technique entries, 40 mitigations and 73 case studies. Releases are monthly, so cite the version you used. On the matrix you can filter by platform (predictive AI, generative AI, agentic AI, enterprise) and by maturity: feasible, demonstrated or realized. Those labels are a quick way to prioritise a test plan.

A worked example: Slack AI (AML.CS0035)

The case study “Data Exfiltration from Slack AI via Indirect Prompt Injection” is an exercise by the security firm PromptArmor, dated 20 August 2024. ATLAS summarises it this way: the attack relied on Slack AI ingesting a malicious prompt from a post in a public channel into its retrieval database, and then a victim user querying Slack AI, which caused the prompt to be retrieved and executed. The researchers targeted an API key stored in a private channel. Here is how ATLAS breaks the procedure into steps:

Notice what this mapping gives a defender. No step required breaking the model. Each depends on a design decision in the application: what the assistant may retrieve, whose content it indexes, what permissions it holds for the person asking, and how its output is rendered. That is why OWASP calls related weaknesses prompt injection, excessive agency or improper output handling: the same chain, seen from the vulnerability side. The next lesson covers that view.

Turning the map into a test plan

1. List the assets and entry points of your system: data sources the model retrieves from, tools it can call, accounts it acts through.
2. Pick the relevant platform filters, then start with the techniques at the demonstrated and realized maturity levels.
3. Write each test as a short chain of tactics, as in the table, so a finding is a path and not an isolated trick.
4. For each technique, look up its mitigations. ATLAS lists, for example, Human In-the-Loop for AI Agent Actions (AML.M0029), Restrict AI Agent Tool Invocation on Untrusted Data (AML.M0030), AI Agent Tools Permissions Configuration (AML.M0028) and AI Telemetry Logging (AML.M0024).
5. Record the ATLAS IDs in your report. ATLAS also has a mitigation named AI Red Team (AML.M0035), which describes recurring, authorised, threat-informed exercises before deployment and throughout operation.

One caution: ATLAS shows what has been demonstrated, not what is likely in your organisation. A technique rated feasible may matter more to you than a realized one, depending on what your system exposes. Use the knowledge base to widen your thinking, then let your own architecture decide priorities.