If you have ever worked with MITRE ATT&CK, you already know the shape of the thing: a structured, community-maintained catalog of how real attackers behave, organized so that defenders can talk about threats with a common vocabulary. MITRE ATLAS is the same idea pointed at AI systems. And as of its early-2026 updates, it now describes attacks that specifically target autonomous agents — the tools they call, and the supply chains they pull those tools from.
What ATLAS actually is
ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It is a knowledge base of adversary tactics, techniques, and procedures aimed at AI and machine-learning systems, structured the same way ATT&CK structures threats to traditional IT.
The hierarchy is worth internalizing because it tells you how to read the thing:
- Tactics are the attacker's goals — why they are doing something (Initial Access, Resource Development, Exfiltration, and so on).
-
Techniques are the how — the specific methods used to achieve a tactic. Each gets a stable ID like
AML.T0010. - Mitigations are defensive countermeasures mapped to techniques.
- Case studies are real, documented incidents mapped back to the techniques they used.
That last part matters. ATLAS is not a list of hypotheticals someone brainstormed. The techniques are grounded in observed attacks, and many link to case studies of incidents that actually happened.
One thing to be clear about: ATLAS is an attacker model. It describes what adversaries do, not which controls you should build. It is the threat-modeling half of the work, not the controls half. (It bridges toward defense through its mitigation mappings, but its center of gravity is the adversary.)
The new agentic techniques
The interesting recent additions describe attacks that only make sense once an LLM is calling tools and acting on the world. Three are worth knowing by ID:
AI Supply Chain Compromise (
AML.T0010) — a Initial Access technique. An adversary gets a foothold by compromising part of the AI supply chain: the model, the data and its annotations, the software stack, or the hardware. It has sub-techniques, including AI Software (AML.T0010.001). The canonical example is a malicious model uploaded to a public hub with malware embedded in it — you pull the model, you run the attacker's code.Publish Poisoned AI Agent Tool (
AML.T0104) — a Resource Development technique, added in the early-2026 agentic update. An adversary builds and publishes a poisoned agent tool — for example, a tool or skill in a public registry — so that anyone whose agent installs it is compromised. The poison is often a prompt injection baked into the tool, so invoking it steers the agent toward the attacker's goal.AI Agent Tool Poisoning (
AML.T0110) — the closely related case of modifying an agent's tools so that future invocations execute attacker-controlled behavior. A tool that looked and behaved legitimately becomes a foothold the next time the agent reaches for it.
Read together, these describe a clean, realistic attack arc: poison a tool, get it published or substituted into a registry an agent trusts, and let the agent install and invoke it. The Postmark MCP server email-exfiltration incident is exactly this pattern in the wild — a trusted tool turned into an exfiltration channel through the agent that called it.
Why this matters
The value here is the same value ATT&CK delivered years ago: a shared vocabulary. When threat modeling for agents is ad hoc, every team names the same risks differently and nobody can compare notes. A stable ID like AML.T0104 lets a red-teamer, a SOC analyst, and an architect point at the same thing and mean the same thing. It also lets vendors and detection tools map their coverage to a common reference instead of a marketing taxonomy.
What ATLAS deliberately does not do is hand you the fix. It tells you tool poisoning is a real, observed technique; it does not implement the provenance checks, the registry pinning, the tool allowlisting, or the runtime monitoring that contain it. That is by design — and it is why ATLAS pairs naturally with a control framework rather than replacing one.
The practitioner takeaway
Use ATLAS to answer "what can happen," then map each relevant technique to a control you actually have.
Concretely: walk the agentic techniques against your own system. If your agent installs tools or skills from a registry, AML.T0104 and AML.T0010 are pointed straight at you — so what verifies a tool before your agent trusts it? If your agent reaches for the same set of tools across sessions, AML.T0110 is asking whether anything would notice if one of them quietly changed. Some techniques will not apply; the ones that do will usually surface a control you have not built yet.
The mapping itself is the work. ATLAS gives you the named threat with a real incident behind it. Your job is to put a concrete control next to each one and check that the control is actually there.
MITRE ATLAS is one of the sources behind *BRACE*, an open, vendor-neutral framework for securing autonomous AI agents — BRACE maps these agentic techniques to the controls that contain them, covered in its run-time guide. It's built by reading the incidents and the research and asking, each time: what concrete control would have prevented or contained this?
Top comments (0)