MITRE ATLAS is now an agent security framework

MITRE launched ATLAS in 2021 as a catalog of attacks against machine learning models. It covered adversarial examples that fool a classifier, inversion attacks that pull training data back out of a model, and poisoned datasets that change what a model learns. Those were the threats of a world where AI was something you trained and then served behind an inference API.

That catalog now runs to 120 techniques and 88 sub-techniques, and since May 2026 MITRE has tagged every one of them with the platforms an adversary operates in. In release v2026.09, published September 15, 2026, 139 of those 208 entries carry the Agentic AI tag. Generative AI carries 106, Enterprise 85, and Predictive AI 82. The framework that started as a model-security catalog is now, by its own classification, mostly about agents.

Two of the newest case studies in the knowledge base show what that shift describes. In case study AML.CS0069, a state-sponsored group jailbroke Claude Code, connected it through MCP to scanners, browser automation, and password crackers, and ran a cyber-espionage campaign against roughly 30 organizations in which the agent performed an estimated 80 to 90% of the activity. In case study AML.CS0053, an attacker published a lookalike postmark-mcp package on npm, waited for it to pass 1,000 weekly downloads, then shipped a version that BCC'd every email the tool sent to an address they controlled.

Neither incident involved a model vulnerability, and both worked entirely through what the model was wired into.

In this article:

• What is MITRE ATLAS?
• MITRE ATLAS vs MITRE ATT&CK: what's the difference?
• What does the ATLAS matrix cover in 2026?
• Which ATLAS techniques matter most for enterprise AI?
• What does a real ATLAS attack chain look like?
• Where does MITRE ATLAS stop?
• How Speakeasy maps to MITRE ATLAS coverage

What is MITRE ATLAS?

MITRE ATLAS (Adversarial Threat Landscape for AI Systems) is a living knowledge base of adversary tactics, techniques, and real-world case studies targeting AI-enabled systems. It is structured exactly like MITRE ATT&CK. Tactics are the adversary's objectives, techniques are the ways of achieving them, and case studies document incidents where those techniques were actually used.

The current release contains one matrix, 16 tactics, 120 techniques, 88 sub-techniques, 40 mitigations, and 73 case studies. ATLAS ships monthly now, so treat every count here as a snapshot of v2026.09 rather than a fixed number.

Fourteen of the 16 tactics are adapted from ATT&CK, including Reconnaissance, Initial Access, Persistence, Credential Access, Lateral Movement, Exfiltration, and Impact. Two are specific to AI systems:

• AI Model Access (AML.TA0000) covers the levels of access an adversary needs to a model, from querying a public inference API to holding the full weights.
• AI Attack Adaptation (AML.TA0001) covers turning reusable capabilities and target knowledge into attack-ready output, such as a proxy model, adversarial data, a crafted prompt, or tasking for an autonomous agent.

Every technique also carries a maturity rating, which is the level of evidence behind its use. MITRE defines the three levels as Feasible (shown to work in a research setting), Demonstrated (shown to work in a red team exercise or on a realistic AI system), and Realized (used by a threat actor in a real-world incident). Across the full matrix, 101 entries are Realized, 83 Demonstrated, and 24 Feasible.

MITRE ATLAS vs MITRE ATT&CK: what's the difference?

ATT&CK maps adversary behavior against enterprise networks, cloud, mobile, and ICS. The assets are hosts, accounts, and network paths, and the techniques assume an attacker who has to break something to make it behave differently.

ATLAS maps adversary behavior against systems whose defining property is that they can be talked into things. Poisoning training data changes what a model learns without touching a single line of code. Prompt injection redirects an agent using nothing but text the agent was designed to read. Model inversion recovers the data a model was trained on using queries the API was built to answer. In every case the system works as designed, which is why network and endpoint controls do not see the attack.

The two frameworks are complements rather than alternatives. A modern intrusion crosses both. In the espionage campaign above, the agent's reconnaissance, credential harvesting, and lateral movement are all ATT&CK behavior, and MITRE tracks the campaign in ATT&CK as C0062. What ATT&CK has no vocabulary for is the part where the attacker's capability was a commercial coding agent, talked past its safeguards with a false defensive-security persona and pointed at targets through MCP.

What does the ATLAS matrix cover in 2026?

The platform tags MITRE added in content release v2026.05 are the clearest picture of where AI attacks now happen, because they are MITRE's own classification of its own catalog rather than an outside reading of it. The chart below breaks the 208 entries down by platform, and splits the agentic set by the evidence behind each entry.

Of the 139 agentic-tagged entries, 66 were added in the last twelve months, which is where nearly all of the framework's new content has gone. Much of it came from a Zenity Labs collaboration that contributed agent-focused techniques covering context poisoning and exfiltration through tool invocation.

The maturity ratings on those entries matter as much as the count. Of the 139, 57 are rated Realized, meaning a threat actor has used them in a real incident against a real system, and 62 more have worked on realistic systems in red team conditions. Agent-layer attacks stopped being a research finding at some point in the last year, and the evidence ratings are where that shows up.

Which ATLAS techniques matter most for enterprise AI?

Four clusters account for most of the exposure in a typical enterprise deployment, and each one has a different enforcement answer.

How does ATLAS classify prompt injection?

LLM Prompt Injection (AML.T0051) is the technique for an adversary introducing instructions that the model treats as authoritative. Direct injection (AML.T0051.000), rated Realized, is an instruction typed into the prompt. Indirect (AML.T0051.001) hides the instruction in content the model reads on its own, such as a document, a web page, a calendar invite, or an API response. Triggered (AML.T0051.002) leaves a payload dormant until a specific condition fires.

Injection matters more in an agent than in a chatbot because the output is an action rather than a sentence. ATLAS captures that escalation in separate techniques for what the injected instruction then does, including AI Agent Tool Invocation (AML.T0053), Exfiltration via AI Agent Tool Invocation (AML.T0086), and Data Destruction via AI Agent Tool Invocation (AML.T0101).

Where it is enforced: the tool-call boundary. MITRE's own mitigation, Restrict AI Agent Tool Invocation on Untrusted Data (AML.M0030), is explicit that once untrusted content enters the model's context, the right control is to restrict what the agent is allowed to invoke next.

What are the three kinds of poisoning in ATLAS?

Poisoning is three separate problems on three separate timescales. Training Data Poisoning (AML.T0020) corrupts a model before it ships. RAG Poisoning (AML.T0070) corrupts the retrieval index an agent queries at runtime. AI Agent Context Poisoning (AML.T0080) corrupts the agent's working state, with sub-techniques for persistent Memory (AML.T0080.000, rated Realized) and for the current Thread (AML.T0080.001).

The memory variant is the one to check if you are rolling out assistants with persistent memory. An attacker who gets one instruction stored in a user's memory has changed the agent's behavior for every future session, and MITRE notes that a poisoned thread in a shared surface such as a Slack channel affects every participant, not just the person who triggered it.

Where it is enforced: write controls on the memory and retrieval stores, plus Memory Hardening (AML.M0031) on durable agent state.

How does ATLAS cover AI supply chain and tool poisoning?

ATLAS now carries a full set of techniques for attacks delivered through the tools an agent connects to. AI Supply Chain Compromise has a dedicated AI Agent Tool sub-technique (AML.T0010.005). AI Agent Tool Poisoning (AML.T0110) covers malicious behavior in the tool itself, split into definition-level and implementation-level variants. AI Supply Chain Rug Pull (AML.T0109) is the pattern of publishing something legitimate, waiting for adoption, and then shipping the malicious version.

All three are rated Realized, and the Postmark incident is the reason.

Where it is enforced: an MCP gateway with a curated registry, schema validation on tool definitions, and egress control on what a tool can reach.

What are model extraction and model inversion?

The original ATLAS threats have not gone away. Exfiltration via AI Inference API (AML.T0024) covers inferring whether a record was in the training set (AML.T0024.000), reconstructing training data from the model (Invert AI Model, AML.T0024.001), and cloning the model itself through systematic querying (Extract AI Model, AML.T0024.002). Extraction is rated Realized, and the case studies include distillation campaigns run against commercial model providers.

Where it is enforced: the model-call boundary, through query rate and volume limits (AML.M0004) and access control on models in production (AML.M0019).

What does a real ATLAS attack chain look like?

The Postmark case study is the clearest short example of how ATLAS reads in practice, because the entire chain runs through agent infrastructure and nothing in it requires a model vulnerability.

MITRE maps the incident to nine techniques across six tactics. The attacker developed a malicious MCP server (AML.T0017), published it under a name impersonating the vendor (AML.T0115.002, AML.T0073), let it reach more than 1,000 weekly downloads, and then rug-pulled it (AML.T0109). Engineers installed the update (AML.T0010.005, AML.T0011.002), the poisoned implementation added a hidden BCC to every send (AML.T0110.001), and the agent exfiltrated mail through ordinary tool calls (AML.T0086) with real business consequences (AML.T0048).

The diagram below traces that chain from the attacker's first move through to the exfiltration, and marks the points where infrastructure breaks it.

Four of those steps are visible to infrastructure that most organizations have not deployed:

• A curated server registry stops the install.
• Schema and definition validation catches a tool that changed behavior between versions.
• Egress policy on the tool call catches mail going to an address outside the org.
• A tool-call audit log makes the exfiltration reconstructable afterward instead of invisible.

That is four independent chances to break one chain, all of them at the same layer.

Where does MITRE ATLAS stop?

ATLAS is the best available description of how adversaries attack AI systems, and it is honest about being a description. Three limits matter when you try to operationalize it.

It is an attacker model, not a defender architecture. ATLAS tells you an adversary can exfiltrate data through tool invocation. It does not tell you who is authorized to call which tool, how credentials reach the agent, or what a complete audit trail contains. The 40 mitigations name the control (segment agent components, validate tool inputs, log agentic steps) without specifying the system that implements it.

Coverage moves monthly. The framework added six techniques and four sub-techniques in September 2026 alone. A one-time mapping exercise against a fixed version goes stale in a quarter, which makes ATLAS coverage a program rather than a project.

There is no regulatory mapping. ATLAS does not map to NIST AI RMF functions, EU AI Act risk tiers, ISO 42001 controls, or SOC 2. Compliance teams that want to use it as evidence of due diligence have to build that crosswalk themselves. The OWASP lists have the same gap, which is why most mature programs run ATLAS for threat modeling and detection, NIST or ISO for governance, and OWASP for engineering requirements, rather than choosing one.

How Speakeasy maps to MITRE ATLAS coverage

The agentic half of ATLAS converges on a small number of enforcement points, because almost every agent technique has to pass through a tool call, a credential, or a model call to do damage. The Speakeasy AI control plane is built around those points.

The middle column of that table collapses into one layer. Ten of the 40 ATLAS mitigations (M0026 through M0033, M0037, and M0038) are specifically about AI agents, and all ten describe permissions, segmentation, validation, human approval, authority limits, or drift detection at the agent-to-tool boundary. An organization with no enforcement there has no answer to most of the agentic matrix, no matter how thoroughly it has mapped the threats.

Further reading

• AI security frameworks compared: NIST AI RMF, MITRE ATLAS, and the three OWASP lists side by side, with enforcement-layer mapping.
• The OWASP Agentic Top 10, explained: the engineering-requirements view of the same agent threats.
• What is the NSA MCP security baseline?: four operational requirements for MCP deployments from a national security agency.
• MCP gateway architecture and governance: the enforcement layer for tool-call authorization and supply chain control.
• What is prompt injection?: the technique underneath most of the agentic matrix.
• What is an AI control plane?: the architecture that spans hooks, gateway, identity, and audit.