MITRE's ATLAS 2026.09 release tags 76 top-level techniques with the platform Agentic AI. We took that list — MITRE's tag, applied mechanically, not our own selection — and read what 19 AI-security vendors have published against it. Every credit below rests on the vendor's own page and a sentence quoted from it verbatim.
The interesting result is not the ranking. It is the shape of the map: coverage is piled onto four techniques, twelve techniques are claimed by exactly one vendor each, and a third of the framework is claimed by no one at all.
How a technique was credited
This is a documentation review. A vendor is credited for a technique only where its own published material describes doing the thing the technique describes. Three rules did most of the work:
- Explaining an attack is not covering it. A blog post defining prompt injection is education. A page saying the product detects or blocks it is a claim. Only the second counts.
- Governing usage of AI is not defending against an adversary. Shadow-AI discovery, DLP and app-control applied to AI traffic are real capabilities, but they are not coverage of an ATLAS adversary technique.
- Third-party prose does not count. Analyst copy republished on a vendor's newsroom is not the vendor's claim, even when it is the strongest sentence on the site.
An empty cell means we found nothing published, not that a product lacks the capability. Vendors document selectively, and plenty of real engineering never reaches a marketing page. Nothing here says a named company is exposed to anything.
Where everyone is standing
Four techniques carry most of the industry's published coverage. They are the ones with obvious product shape — something leaves, something gets injected, a tool gets called.
| Technique | Vendors documenting it |
|---|---|
| AML.T0086 Exfiltration via AI Agent Tool Invocation | 17 / 19 |
| AML.T0051 LLM Prompt Injection | 14 / 19 |
| AML.T0053 AI Agent Tool Invocation | 14 / 19 |
| AML.T0057 LLM Data Leakage | 13 / 19 |
| AML.T0132 Misconfigured or Publicly Exposed AI Services | 10 / 19 |
| AML.T0133 Discover AI Agent Runtime Capabilities | 10 / 19 |
| AML.T0083 Credentials from AI Agent Configuration | 10 / 19 |
Counts in this table are out of the 19 vendors, and so is the scale on the chart above. MoorAI sits on its own reserved row along the foot of that chart — filled where we document the technique, left deliberately empty where we do not, so the row reads as a floor with holes in it rather than quietly closing up. There are 17 holes in it. If you are buying, this is the part of the market where you have genuine choice and can compare on quality rather than existence.
A third of published coverage comes with a limit attached
Counting cells hides something. Of the 249 credits in this review, 75 are what the data calls bounded — coverage the vendor documents together with a limit it states itself. In the chart those blocks are drawn hollow and dashed. Treating them as equal to a flat claim would overstate almost a third of the market.
The qualification clusters where you would least expect it, on the crowded techniques rather than the thin ones:
| Technique | Blocks | Of which bounded |
|---|---|---|
| AML.T0053 AI Agent Tool Invocation | 15 | 9 |
| AML.T0086 Exfiltration via AI Agent Tool Invocation | 18 | 7 |
| AML.T0051 LLM Prompt Injection | 15 | 2 |
| AML.T0057 LLM Data Leakage | 14 | 1 |
Tool invocation is the most-qualified technique in the framework — nine of its fifteen claims arrive with a stated limit. That is the cell most likely to be read as solved and least likely to be.
By product, the share varies enormously: dope.security 2 of 2, MIND 3 of 4, Endor Labs 11 of 18, Lakera 10 of 21, MoorAI 4 of 27. Read a high proportion as candour, not weakness. A bounded cell exists because a vendor wrote down where its coverage stops; a vendor that never qualifies anything is not necessarily covering more ground, it may simply be writing less carefully. Every product here has at least one bounded cell except Ent, which has no cells at all.
Why nobody can count their agents
Four of the techniques above are the same job from different angles: AML.T0132 exposed AI services (10 of 19), AML.T0084 discover agent configuration (9), AML.T0103 deploy AI agent (7) and AML.T0007 discover AI artifacts (5). Inventory, posture and discovery — knowing what exists before defending it.
Even the best-covered of those has barely half the market publishing on it, which lines up with what practitioners report. In research IDC ran for GuidePoint Security this month, every participant said some version of “I cannot see or count my agents.” That study interviewed thirteen security and identity leaders, so treat the percentages reported alongside it with care — a proportion quoted off a base of thirteen carries far less precision than it appears to, and the work was commissioned by a vendor selling into the problem. The unanimity is the part worth keeping.
A researcher quoted in that coverage put the underlying difficulty better than a scoreboard can: some products count agents, some map their permissions, some watch what they actually do, and buyers assume one implies the others. ATLAS agrees — it keeps those as separate techniques, and AML.T0133 is defined as learning an agent’s capabilities without access to its configuration, which is exactly what makes it a different technique from AML.T0084. Three columns in this chart, not one.
The thirty-two nobody documents
Thirty-two of the 76 techniques are documented by nobody at all — not by any of the 19 vendors, and not by us either. Counting vendors alone it is 34, because two techniques are held by MoorAI and no one else: AML.T0131 Crafted AI Assistant Links and AML.T0134 AI Targeted Cloaking. Thirty-two is the honest headline, and it is easy to misread, so we split it.
Seventeen describe the adversary's own preparation — acquiring public AI artifacts, developing capabilities, crafting a prompt, verifying an attack works, discovering a model family, reconnaissance. No defensive product claims these, and none should. They are on the map because ATLAS models the attacker's whole path, not because they are a product gap.
The remaining fifteen are a different matter. These are defence-side techniques that a security product could plausibly address, and nobody in this set has published that they do.
| Tactic | Technique |
|---|---|
| Defense Evasion | AML.T0067 LLM Trusted Output Components Manipulation |
| AML.T0071 False RAG Entry Injection | |
| AML.T0076 Corrupt AI Model | |
| AML.T0092 Manipulate User LLM Chat History | |
| AML.T0094 Delay Execution of LLM Instructions | |
| AML.T0111 AI Supply Chain Reputation Inflation | |
| Impact | AML.T0031 Erode AI Model Integrity |
| AML.T0046 Spamming AI System with Chaff Data | |
| AML.T0059 Erode Dataset Integrity | |
| AML.T0130 AI Agent Response Biasing | |
| Command and Control | AML.T0096 AI Service API |
| AML.T0120 AI Artifact Repository | |
| Persistence | AML.T0061 LLM Prompt Self-Replication |
| Initial Access / Persistence | AML.T0093 Prompt Infiltration via Public-Facing Application |
| Collection | AML.T0035 AI Artifact Collection |
Two patterns stand out. Defense Evasion is the emptiest tactic in the framework — six techniques, no published coverage. Every one of them is about an attack that has already landed and is hiding: chat history rewritten, a false entry planted in the index, instructions set to fire later. The industry has published a great deal about stopping the injection and almost nothing about detecting one that already worked.
And Impact is empty. Erode model integrity, erode dataset integrity, bias an agent's responses, flood a system with chaff. These are the outcomes an attacker actually wants, and no vendor here documents defending them.
Twelve techniques with exactly one vendor
Twelve more are documented by a single vendor. A monoculture is worth knowing about when you are building a stack.
| Technique | The only vendor documenting it |
|---|---|
| AML.T0018 Manipulate AI Model | Endor Labs |
| AML.T0060 Publish Hallucinated Entities | Endor Labs |
| AML.T0115 Publish Poisoned AI Artifacts | Endor Labs |
| AML.T0062 Discover LLM Hallucinations | Lakera |
| AML.T0082 RAG Credential Harvesting | Lakera |
| AML.T0100 AI Agent Clickbait | Straiker |
| AML.T0129 Triggers in Multimodal Inputs | Straiker |
| AML.T0040 AI Model Inference API Access | Harmonic Security |
| AML.T0006 Active Scanning | Salt Security |
| AML.T0024 Exfiltration via AI Inference API | Operant AI |
| AML.T0077 LLM Response Rendering | Bifrost Edge |
| AML.T0108 AI Agent | Zenity |
A low count is usually a category, not a weakness
The vendors at the bottom of this map are mostly data-loss-prevention and insider-risk platforms. That is not a verdict on them. ATLAS agentic techniques describe an adversary acting against a model or an agent; a DLP platform is built to stop sensitive data leaving regardless of which technique moved it. Most of this framework is simply not its subject.
Two vendors say so themselves, and we took their word over their own marketing. MIND, on a post about an autonomous-agent breach:
“MIND doesn’t patch template-injection flaws or contain a sandbox escape. No data loss prevention platform does.”
And dope.security, which publicly assigns MCP security, prompt injection and model security to others. Where a vendor draws its own boundary, the boundary wins — we removed credits on the strength of those statements.
Corpus size is not the explanation either. MIND publishes 184 pages and roughly 174,000 words, a body of material comparable to vendors scoring four times higher. It writes a great deal; it writes about something else.
We ran the method against ourselves
MoorAI's own bar on our comparison page is counted differently from everyone else's: from a rule base that carries explicit ATLAS ids, where a technique counts when a shipped rule is tagged with it. Every vendor bar is a prose review. For a long time our page said this meant our number should be discounted.
We tested that, by scoring MoorAI the way we score vendors — published prose only, no access to the rule base. It came out at 31, against the 27 the rule base gives. Discarding every credit traceable to one README bullet that names ATLAS ids outright, it is still 26.
So the prose method is the more generous of the two, and our disclosure had been pointing the wrong way. Eight of those 31 are techniques our own rule base does not claim — inventory, posture and visibility sentences that a reviewer credits because that is what Operant and Lakera were credited for, and that a rule base has no rule for.
Our documentation is written in this framework's language, in units about the size of one ATLAS technique. A prose review rewards that shape. A vendor whose documentation is written for buyers gets credited only where its wording happens to coincide with a technique name, and is undercounted for it. That is the bias in this map, and it favours us. Read the whole thing as a map of what each vendor has written down, not as a measurement of what each product does.
What this is and is not
- It is a reproducible record of published claims: 76 techniques, 19 vendors, every credit with a source URL and a verbatim quote, read on a single date.
- It is not a product test. Nothing here was installed or run. Every credit is a claim, including ours.
- An empty cell is not a gap in a product. It is an absence of published material, which is a different thing and sometimes a much smaller one.
- The denominator is MITRE's, not ours. Techniques are in scope because MITRE tagged them Agentic AI. One technique our own rules map to falls outside that tag and is therefore absent — the rule costs us a cell rather than buying us one.
The full per-technique matrix, including which vendor holds which cell and the quote behind it, is on the comparison page. The underlying data is in the site repository, so you can check any cell against the vendor's page yourself — and tell us where we read it wrong.