New Update: Our new blog is updated.
Free download
Omair Manzoor is the Founder, CEO, and Chief Hacker of ioSENTRIX, a CREST-accredited cybersecurity firm. With 20+ years in offensive security, he has led penetration tests for Fortune 500 companies including engagements for Amazon, Bank of America, VISA, and the London Underground. His exploits are part of the Metasploit Framework and Immunity Canvas. Omair is a published researcher, conference keynote speaker (DOD, CISA, BSides), and technical reviewer for academic security textbooks.
MITRE ATLAS appears in a lot of AI security slide decks. It appears in very few test plans.
The matrix gets screenshotted, the tactics get listed, the deck moves on to AI-specific threat modeling, and then the engagement goes ahead testing whatever the tester was going to test anyway. The reason is not laziness. It is that a knowledge base of adversary behavior is not a test plan, and nobody publishes the step in between.
This post is that step. Pick a technique, state the test, state what the test proves. Thirteen times.
MITRE ATLAS is a knowledge base of adversary tactics and techniques against AI-enabled systems, structured like MITRE ATT&CK and populated from observed attacks and documented red-team demonstrations. It gives each behavior an identifier in the form `AML.T####`, groups them under tactics in the form `AML.TA####`, and maps mitigations to them as `AML.M####`.
The current content release is version 2026.09. MITRE's own changelog for that release states it "contains 1 matrix, 16 tactics, 120 techniques, 88 sub-techniques, 40 mitigations, and 73 case studies."
Two notes on version numbers, because this is where published writing about ATLAS most often goes wrong. ATLAS splits its versioning deliberately: from release 2026.05, MITRE records that "monthly ATLAS content releases will follow a YYYY.MM.N versioning scheme with the version stored in the Collection object. ATLAS data format changes will follow semantic versioning." So a semantic version string you find in the repository is the data format, not the content — and the older combined file in the repository is marked deprecated. If a page cites ATLAS with a semver-style number, or quotes a parent-technique count in the eighties, it predates the current release.
ATLAS is modeled on ATT&CK and reuses most of its tactics with AI-expanded definitions, while adding tactics that have no enterprise equivalent. MITRE's own glossary says ATLAS tactics "represent new adversary goals particular to artificial intelligence systems, as well as tactics adapted from the MITRE ATT&CK® Enterprise Matrix. In those cases, ATT&CK tactic definitions are expanded to include AI concepts."
The structure bears that out. Of the 16 tactics in release 2026.09, 14 carry an explicit reference to an ATT&CK Enterprise tactic. The two that do not are the AI-native ones: AML.TA0000 AI Model Access and AML.TA0001 AI Attack Adaptation.
That second name is worth noting. AML.TA0001 was called "AI Attack Staging" until release 2026.08. Most existing writing about ATLAS still uses the old name.
The practical consequence of the ATT&CK lineage is that your existing threat-modelling vocabulary mostly transfers. Reconnaissance, initial access, persistence, privilege escalation, discovery, lateral movement, collection, command and control, exfiltration, impact — all present, all meaning roughly what they mean in ATT&CK, with the AI system as the target instead of the host. One caution for ATT&CK-literate readers: ATLAS still names AML.TA0007 “Defense Evasion,” which is the name ATT&CK Enterprise used when the mapping was made. ATT&CK has since renamed that tactic, so the two matrices no longer agree on the label.
Each entry below gives the ATLAS identifier and MITRE's official technique name, the test, and what the result proves. Technique IDs and names are from release 2026.09.
AML.T0069 Discover LLM System Information — including its sub-techniques for special character sets, system instruction keywords, and the system prompt. Test: attempt to recover the system prompt, the tool definitions, and the policy text through direct questioning, partial-completion tricks, encoding, and error messages. Proves: how much of your enforcement logic an attacker can read before attacking it. Everything downstream is cheaper for them if this succeeds.
AML.T0084 Discover AI Agent Configuration — with sub-techniques for embedded knowledge, tool definitions, activation triggers, and call chains. Test: ask the agent what it can do, what tools it holds, what triggers it, and what it calls next. Proves: whether your agent will enumerate its own attack surface on request. Most will.
AML.T0006.003 Active Scanning: Probe AI Agent Trigger Channels. Test: enumerate every path that can start the agent — webhook, inbox, queue, file drop, scheduled job, another agent — and try to trigger it from each as an unauthorized party. Proves: whether the agent's entry points are authenticated at the same standard as your API endpoints. This technique is new in the 2026 releases and is routinely out of scope in older AI assessments.
AML.T0051.000 LLM Prompt Injection: Direct. Test: supply instructions in user input that contradict the system prompt, and measure whether they are followed. Proves: the baseline. Fast, and almost never the interesting result on its own.
AML.T0051.001 LLM Prompt Injection: Indirect. Test: plant instructions in content the model will consume but the user did not write — a retrieved document, a web page, a ticket body, a file, an email. Proves: whether your trust boundary is drawn where you think it is. Our prompt injection explainer covers the attack itself; this is the test for it. This is where real incidents live, and it is the test most often skipped because it needs the content pipeline in scope, not just the chat box.
AML.T0051.002 LLM Prompt Injection: Triggered. Test: plant a payload that activates only on a condition — a keyword, a date, a particular user, a specific retrieval. Proves: whether a clean test run means anything. A system that passes direct and indirect injection can still carry a dormant payload, and a point-in-time test will not see it.
AML.T0068 LLM Prompt Obfuscation. Test: re-run your successful injections through homoglyphs, zero-width characters, bidirectional text, emoji and Unicode tag smuggling, full-width characters, and a second language. Proves: whether your detection matches meaning or matches strings. MITRE's own text for this technique says it "may bypass LLM guardrails that identify malicious content."
AML.T0054 LLM Jailbreak. Test: the strategies MITRE names in the technique itself — instruction override, roleplay, multi-turn escalation, data-structure injection, obfuscation, and appending affirmations such as “sure” to the end of a prompt. Proves: whether refusal behavior survives a conversation rather than a single message. Multi-turn is the one that tends to work.
AML.T0053 AI Agent Tool Invocation. Note the tactics MITRE assigns it: Execution, Privilege Escalation, and Lateral Movement. Test: for each tool the agent holds, establish whether a successful injection can invoke it, with what arguments, under whose authority, and what it reaches. Proves: the blast radius. This is the single most valuable test on the list, because it converts "the model said something bad" into "the system did something bad," which is the only version that matters to an incident responder.
AML.T0110 AI Agent Tool Poisoning — with sub-techniques for the tool's definition and instructions, its implementation, and its runtime response. Test: control a tool's response and see whether the agent treats it as instruction — the trust problem we set out in MCP security; and read your tool descriptions as an attacker would, because the description is itself input to the model. Proves: whether your tool chain is a trust boundary or a trusted input. Worth knowing: in release 2026.09 this technique and its sub-techniques have no mapped mitigations at all. ATLAS is telling you there is no cataloged control, which makes the test result the only information available.
AML.T0024.002 Exfiltration via AI Inference API: Extract AI Model, and AML.T0024.000 Exfiltration via AI Inference API: Infer Training Data Membership. Test: query-volume-bounded extraction and membership inference against your inference endpoint. Proves: whether your API's rate and volume limits are set where they need to be. Mapped mitigations here include AML.M0004 Limit AI Service Query Volume and Rate — a control you can actually verify.
AML.T0056 Extract LLM System Prompt. Test: a dedicated attempt to recover the system prompt verbatim, separate from the general discovery above. Proves: whether your prompt can be treated as a secret. If it can be extracted, it is configuration, not a control, and anything you were enforcing in it needs enforcing somewhere else.
AML.T0034.002 Cost Harvesting: Agentic Resource Consumption. Test: drive the agent into long tool-call chains, recursive delegation, and expensive retrievals, and measure spend and latency. Proves: whether an availability and cost attack is possible without any security control failing at all. Mapped mitigations include AML.M0036 Limit AI Workload Resource Consumption.
Two scoping notes that make this list usable. First, since release 2026.05 every ATLAS technique carries a `platforms` value, which lets you filter the matrix by system type before you plan anything: in 2026.09, counting parent techniques and sub-techniques together, 139 technique objects are tagged `Agentic AI`, 106 `Generative AI`, 85 `Enterprise`, and 82 `Predictive AI` (a technique can carry more than one tag). If you are testing a predictive model rather than an agent, a different 82 objects apply, led by AML.T0015 Evade AI Model and AML.T0043 Craft Adversarial Data, which is the ground covered in adversarial machine learning. Second, AML.T0029 Denial of AI Service and AML.T0015 Evade AI Model are the current official names — MITRE renamed its "ML" techniques to "AI" in an earlier release, and the old names are still widely quoted.
Partly, and the gap is the point.
MITRE does publish an adversary-emulation plugin, Arsenal, described in MITRE's own words as a plugin that "will help store and create adversarial TTPs defined in ATLAS to interface with CALDERA." There is also Almanac, a CALDERA plugin for exploring ATLAS using the ATLAS Navigator, and an ATLAS Navigator fork of the ATT&CK Navigator that lets you overlay a case study's techniques on the matrix. ATLAS data is downloadable as YAML, STIX 2.1 and Excel, including a combined ATLAS-plus-ATT&CK-Enterprise STIX bundle.
So it would be wrong to say no tooling exists. It is accurate to say that Arsenal's published ability set is headed with a June 2023 date and targets predictive-ML infrastructure, and that as of October 2026 no official MITRE toolkit executes the 2026-era agentic techniques — the injection sub-techniques, tool invocation, tool poisoning, agent response biasing, runtime capability discovery. Those you run with your own harness, or someone does it for you.
That is the honest state of the ecosystem, and it is why "we align to MITRE ATLAS" and "we have tested against MITRE ATLAS" are different sentences. Alignment to a framework is not compliance with anything and is not evidence that a control held. The matrix tells you what to try. It does not try it — which is also the practical difference between AI red teaming and AI penetration testing.
This is the detail most write-ups get wrong, and it is worth getting right before you cite a case study to a board.
MITRE describes case studies as documents that "describe real-world attacks on AI systems and the impacts of these attacks," and each carries a `Type` field recording "whether this case study describes a real-world incident or exercise under a realistic threat model and representative Target system."
Of the 73 case studies in release 2026.09, 50 are exercises and 23 are incidents. The majority are red-team demonstrations rather than confirmed breaches.
That is not a weakness of ATLAS. It is ATLAS being precise about its own evidence, and it maps exactly onto the distinction this blog keeps making: a demonstrated attack is evidence that something is possible, and a documented incident is evidence that it happened. Both are useful. Treating the first as the second is how AI security reporting loses its audience.
A test plan derived from ATLAS, not a slide citing it.
Concretely: filter the matrix to your platform type. Pick the techniques that correspond to a capability your system genuinely has — an agent with no tools does not need the tool-poisoning tests, and a predictive model does not need the jailbreak tests. For each one, write the test, run it, and record the result against the technique ID with a date. Then pair each result with the mapped mitigation and ask what that mitigation would have to prove to close the finding.
The pairing is where this stops being a checklist. ATLAS maps AML.T0051 LLM Prompt Injection to seven mitigations, among them AML.M0024 AI Telemetry Logging, AML.M0033 Input and Output Validation for AI Agent Components, and AML.M0035 AI Red Team. One of ATLAS's own answers to prompt injection is, literally, a red team. And where ATLAS maps no mitigation at all, there is no cataloged control to point at, so the test result is the only thing you have. That is not a rare corner: twenty-one agentic parent techniques in release 2026.09 carry no mapped mitigation, AML.T0110 among them.
A worked illustration, which is a synthetic composite and not a client: an agent that triages support tickets, with tools for reading the knowledge base, updating the ticket, and issuing a refund below a threshold. Direct injection fails — the system prompt holds. Indirect injection through the ticket body succeeds, because a customer writes the ticket. The agent then invokes the refund tool with attacker-chosen arguments, under a service identity shared with the whole triage fleet — the non-human identity problem in miniature. Three ATLAS techniques, one chain, and the finding is not "the model is jailbreakable." The finding is that an unauthenticated third party can move money, and the fix is in the authorization model rather than the prompt.
That is what the matrix is for.
No. It is a knowledge base of adversary behavior. Nothing certifies against it, and mapping your testing to ATLAS technique IDs is a way to describe coverage, not a claim of compliance with any standard.
The content version, which is date-based. At the time of writing that is 2026.09. Semantic version strings in the ATLAS repository refer to the data format, and releases before 2026.05 carry a combined SemVer number that conflated content and format — citing either as the content release is a common error.
ATLAS catalogs adversary techniques and maps mitigations to them; the OWASP GenAI lists rank risk categories for application builders. They answer different questions and are complementary, and we have written separately on the OWASP LLM Top 10 — ATLAS is better for building a test plan, OWASP is better for prioritizing design decisions.
No, and you should not try. Filter by the `platforms` value and by what your system can actually do. A focused set of a dozen or so techniques with recorded results beats a spreadsheet claiming 120. Knowing which systems you have at all is a prerequisite — see AI inventory discovery.
Heavily. In release 2026.09, 139 technique objects carry the `Agentic AI` platform tag, including tool invocation, tool poisoning, agent configuration discovery, inter-agent communication, and exfiltration via tool invocation.
ioSENTRIX is a CREST-accredited, ISO/IEC 27001 certified penetration testing firm. We scope AI and ML penetration testing against ATLAS technique IDs so the report says which techniques were attempted, which succeeded, and what each result proves — rather than a framework logo on the cover. We assure the stack you have chosen and sell no competing platform, which is what independence means in practice. If you have an agent in production and a slide that mentions ATLAS, the gap between those two things is worth an hour of conversation.
