ATLAS agentic-technique coverage, vendor by vendor

MITRE's ATLAS 2026.09 release tags 76 top-level techniques with the platform Agentic AI. That list — MITRE's tag, applied mechanically, not our own selection — is read here against what 43 AI-security vendors have published. Every credit 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: a handful of techniques draw most vendors, nine are claimed by exactly one vendor each, and 27 of the 76 are claimed by no product we read.

Where everyone is standing

The most-documented techniques are the ones with obvious product shape — something leaves, something gets injected, a tool gets called. Twenty-five are documented by ten or more of the 43 vendors.

Coverage is less concentrated than the top of that table suggests. The four most-documented techniques hold 134 of the 517 vendor credits, 26%, and it takes the eleven most-documented to account for half. The other half is spread across the remaining 33 techniques that any vendor documents.

Counts in this table are out of the 43 vendors, and so is the length of every row in the chart above. MoorAI has its own column at the left of those rows — filled where our rule base maps the technique, left deliberately empty where it does not, so the column reads as a floor with holes in it rather than quietly closing up. There are 18 holes in it. If you are buying, the top of this table is the part of the market where you have genuine choice and can compare on quality rather than existence.

Coverage by product

The same 548 credits, read the other way: one row per product instead of one row per technique. No vendor documents more than 26 of the 76 techniques, 34% of the set. The median vendor documents 11, and 18 of the 43 document fewer than ten. The scale is the whole 76, not the leader, so the empty length to the right of every bar is the part of the framework where we found nothing published for that product.

MoorAI's row is counted from its rule base, as its column is in the chart above, not by the prose method the vendor rows use. It is not like-for-like with the rows around it; the note under the table gives the figures the prose method produces.

Two in five published credits come with a limit attached

Counting cells hides something. Of the 548 credits in this review, 220 are what the data calls bounded — coverage the product 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 two fifths of the market.

The qualification is uneven, and it does not simply follow the crowd:

Tool invocation ties with deploying an agent for the most bounded claims — eighteen of its thirty-seven arrive with a stated limit, and eighteen of deploying an agent’s twenty-one. Tool invocation is the cell most likely to be read as solved and least likely to be. But crowding is not the pattern: prompt injection and data leakage are nearly all flat claims. The highest shares sit on techniques about an agent’s configuration and credentials — deploying an agent, harvesting tool credentials, modifying agent configuration, credentials in agent configuration, discovering agent configuration — and on discovering AI artifacts, where vendors often say themselves that they find things rather than stop them.

By product, the share varies enormously: dope.security 2 of 2, MIND 3 of 4, Permiso 6 of 9, Endor Labs 11 of 18, Lakera 10 of 21, MoorAI 16 of 31. 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 techniques on the map are the same job from different angles: AML.T0132 exposed AI services (16 of 43), AML.T0084 discover agent configuration (19), AML.T0103 deploy AI agent (21) and AML.T0007 discover AI artifacts (12). Inventory, posture and discovery — knowing what exists before defending it.

Even the best-covered of those has only about half the vendors here publishing on it.

The underlying difficulty is that 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 rows in this chart, not one.

The 27 no product here documents

27 of the 76 techniques are documented by none of the 43 vendors, and no MoorAI rule carries their ids. Counting vendors alone it is 32, because five techniques are held by MoorAI’s rule base and no one else: AML.T0131 Crafted AI Assistant Links and AML.T0134 AI Targeted Cloaking, and three whose rules shipped in agent v0.96.0 after this study and because of it, AML.T0092, AML.T0067 and AML.T0035 (see the update). A fourth rule from that release, for AML.T0061 LLM Prompt Self-Replication, has company: Cranium, added on 1 October, documents a static check for it in agent configuration files. The chart lists all 27 by id and name under “No row at all”.

“Nobody” needs two qualifications. It means nobody in this sample. Forty-three vendors plus MoorAI is not the market, and products outside it publish material on some of these techniques: Microsoft on AI recommendation poisoning (AML.T0130) and on a backdoor that uses an AI service API for command and control (AML.T0096), Cisco’s open-source skill scanner on instructions deferred to a later turn (AML.T0094), and ReversingLabs on corrupted model files (AML.T0076). Those vendors were not read against the whole framework, so they are not in the chart. And MoorAI’s own prose describes two of the 27, AML.T0094 and AML.T0117, which the prose review below credits; no shipped rule is mapped to them, so the chart’s MoorAI column, which counts rules, leaves them empty.

The 27 split three ways by ATLAS’s own tactic definitions.

11 are adversary preparation, in Reconnaissance, Resource Development and AI Attack Adaptation: acquiring public AI artifacts, developing capabilities, crafting a prompt or retrieval content, verifying an attack works, reconnaissance. They are on the map because ATLAS models the attacker’s whole path, not because they are a product gap. It is not true, though, that defensive products never claim this ground: vendors document nine techniques whose tactics all sit in these three or the two below, four of them in the preparation tactics themselves, led by autonomous AI agent communication (AML.T0118, twelve vendors).

6 sit in Discovery or AI Model Access: discovering a model family, its outputs or the LLM’s system information, and three kinds of model access. ATLAS does not call these preparation; it describes Discovery as post-compromise. They are listed apart rather than set aside. Neighbouring Discovery techniques are among the most documented in the review, and system-information discovery overlaps system-prompt extraction (AML.T0056), which thirteen vendors document; under the one-mechanism rule those sentences earn the extraction cell only.

The remaining 10 are defence-side techniques that a security product could plausibly address, and nobody in this set has published that they do. By tactic, the uncovered techniques fall like this:

By count, Defense Evasion and Impact tie for the most undocumented defence-side techniques, four of Defense Evasion’s eleven and four of Impact’s nine. By share, Command and Control is emptier, two of three. Defense Evasion is not empty: jailbreaks, prompt obfuscation, supply-chain rug pulls and triggers in multimodal inputs all have vendor coverage, and AI-targeted cloaking has a MoorAI rule. Two of the four that have nothing are about an attack that has already landed and is hiding — a false entry nested in the index, instructions set to fire later. The other two are about getting past a check: a model file corrupted to slip past a scanner, reputation inflated in a supply chain. Chat history rewritten and output dressed to look trustworthy each have a bounded MoorAI rule, written after the study.

Four of Impact’s nine techniques have nothing either: eroding model integrity, eroding dataset integrity, biasing an agent’s responses, flooding a system with chaff. These are outcomes an attacker actually wants, and no vendor here documents defending against them.

Nine techniques with exactly one vendor

Nine more are documented by a single vendor. A monoculture is worth knowing about when you are building a stack.

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 their word is taken 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 — credits were removed 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 column is counted differently from every vendor’s row: from a rule base that carries explicit ATLAS ids, where a technique counts when a shipped rule is tagged with it. Every vendor row is a prose review.

To find out what that difference is worth, MoorAI was scored the way vendors are — published prose only, no access to the rule base. It came out at 31, against the 27 the rule base gave on the read date. Discarding every credit traceable to one README bullet that names ATLAS ids outright, it is still 26.

So on the read date the prose method was the more generous of the two. 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.

The rule base now gives 31, level with the prose count, and the two are no longer like-for-like in time. MoorAI agent v0.96.0, released on 26 September, added rules for AML.T0061, AML.T0092, AML.T0067 and AML.T0035, the last three bounded to local transcript files, links, and model files moved in one command. They were written after this study, because of the gaps it found; they did not exist when the prose was read, and the prose review has not been re-run since. The current release, agent v1.1.0, carries the same ATLAS mapping, and it is the rule base the chart’s MoorAI column is drawn from.