Original framework · Needs validation · 3/5

The ATLAS Wall

Every mitigation in MITRE ATLAS, which is MITRE's ATT&CK-style catalog of attacks on AI systems, runs across the top, every ATLAS technique runs down the side, and a cell is filled where MITRE maps that mitigation to that technique. When I drew this in July the story was how much of the map was blank. Three weeks later MITRE shipped a release that filled a large part of it in, and the October release took the mapping layer to twice what it was in June, which moves the useful question from what is missing to what a defender should actually do first, and to the point where buying one more control stops buying anything.

What changed under the map

ATLAS has shipped two substantial releases since I first drew this map. v2026.07 landed on 31 July 2026, one month after v2026.06, and took the mapping layer from 247 mitigation-to-technique edges to 338 and the number of techniques carrying at least one mapped mitigation from 76 to 119, so the blank share of the matrix fell from 56% to 33% in a single release. v2026.10, released on 28 October, went further again. The framework grew to 221 techniques and 44 mitigations, and the mapping layer reached 494 edges, exactly twice what it was in June, so 168 techniques now carry at least one mapped mitigation and the blank share is down to 24%. That is a large enough move that the versions of this page I published in July and August are describing frameworks which no longer exist, and it seems better to say that plainly than to quietly restate the numbers and move on.

v2026.07 added two mitigations: AI Red Team, which asks for recurring, authorized, threat-informed exercises against AI-enabled systems before deployment and throughout operation, and Limit AI Workload Resource Consumption, which puts bounds on input size, batch size, execution time, memory, compute and output size for a request or an agent workflow. It also retired three techniques covering poisoned datasets, poisoned models and poisoned agent tools into a single AML.T0115 Publish Poisoned AI Artifacts family with sub-techniques, which is exactly the kind of consolidation that silently drops rows out of any analysis still pinned to the old identifiers. It dropped two technique rows out of my wall, and they only came back because the build asserts that every identifier it maps still resolves in the release it claims to be reading.

Across v2026.08, v2026.09 and v2026.10 ATLAS added seven more mitigations, four of them in the October release, and three of the seven are aimed squarely at AI agents:

AI Agent Authority Expansion Controls
AI Agent Scope Drift Detection
AI Honeypots
Adaptive AI Response Degradation
Privacy-Preserving AI Training and Inference
Threat Intelligence Program
AI Agent External Resource Lifecycle Management

It also renamed five existing mitigations without removing any. AI Bill of Materials became Maintain an AI Bill of Materials and AI Telemetry Logging became AI Telemetry Logging and Monitoring, while the three agent-permission controls were recast around what they manage, so they now read Manage AI Agent Service Access, Manage User-Delegated AI Agent Access and Enforce Access Controls for AI Agent Tools. The technique layer moved too, since AI Supply Chain Compromise is now plain Supply Chain Compromise and five more technique identifiers were retired, which makes eight retired since June counting the three from July. Seven rows of my research corpus carried one of those eight and the same assertion caught them, though for one of them, the old Extract AI Model sub-technique retired in October, the successor is inferred rather than stated in the release, so that row stays flagged in the build instead of being remapped quietly.

The change I find most useful is a naming one. Six mitigations now carry Predictive AI in the identifier itself:

Predictive AI Output Obfuscation
Predictive AI Model Hardening
Predictive AI Ensembles
Predictive AI Multi-Sensor Fusion
Predictive AI Input Restoration
Predictive AI Adversarial Input Detection

v2026.07 rewrote both the name and the description of all six to scope them to predictive models, where v2026.06 had stated them generically, and v2026.10 keeps that scoping. The practical effect is that six of the forty-four controls in the framework are explicitly out of scope for generative and agentic systems, so anyone carrying a control catalog built against the older names is carrying six entries that no longer mean what they used to mean. Putting the limit in the identifier was the right call, because the shortened name is what gets copied into a control catalog, and the scope limit needs to travel with it.

Two technique matrices side by side. On the left, MITRE ATT&CK Enterprise v20, 15 tactics and 227 parent techniques, mostly light gray, with the techniques ATLAS also links to marked in orange. On the right, MITRE ATLAS v2026.10, 16 tactics and 129 parent techniques, where 36 are orange because ATLAS declares an ATT&CK link for them and 93 are red because it declares none. A box between the panels reads 36 shared, and a callout reads 93 of 129 have no MITRE-declared ATT&CK link, was 73 of 101 on ATLAS 2026.07, and notes that ATT&CK v20 added five AI items that ATLAS does not link to. — Parent techniques only, ATT&CK on the left and ATLAS on the right, with each technique drawn in every tactic it belongs to. Orange marks the 36 ATLAS techniques that MITRE links to an ATT&CK technique, red marks the 93 it does not link, and gray is ATT&CK ground with no ATLAS counterpart. Counting sub-techniques as well, 150 of ATLAS's 221 techniques have no link of their own or through a parent. MITRE ATLAS v2026.10 against MITRE ATT&CK Enterprise v20.1 STIX, which carries the same technique set as v20.0, built from the pinned releases by `build_attack_surface_figure.py`. Click to open at full resolution.

How much of ATLAS a security team already knows

A team that already works from ATT&CK will reasonably ask how much of this framework is new to it, and ATLAS answers that itself, because a technique can carry a reference to the ATT&CK technique it borrows. Counting those links, 93 of the 129 parent techniques in v2026.10 have no MITRE-declared ATT&CK link, up from 73 of 101 on v2026.07, so the new share has held at roughly seven in ten while the parent count grew from 101 to 129. The familiar ground sits at the front of the chain, in Reconnaissance, Resource Development, Initial Access and Lateral Movement, and six tactics are entirely net new on that count:

AI Attack Adaptation
Impact
Discovery
Command and Control
Exfiltration
AI Model Access

The technique count overstates how new a real attack is, though. Of the 290 steps in ATLAS's 27 Incident case studies, 146 (50.3%) use ATLAS-native techniques and 144 use ATT&CK techniques or their children, while in the 50 Exercises 373 of 469 steps (79.5%) are native, so the red-team record is far more AI-specific than what attackers have actually done. I think the incident split is the more useful number for a team deciding how much of its existing program carries over, and it is roughly half.

Two cautions pull the other way. ATLAS's own linkage is conservative, since two native techniques, User Execution and Stage Capabilities, carry exactly the name of an ATT&CK technique without a link, so I read 93 as an upper bound on what is genuinely new. And ATT&CK v20, published on 13 October, added five AI items of its own, including direct and indirect prompt injection and AI-enabled exfiltration, none of which ATLAS v2026.10 links to yet, which means a few techniques counted as native here already have an ATT&CK home by concept and the gap between the two frameworks is starting to close from MITRE's enterprise side.

The full MITRE ATLAS technique matrix, sixteen tactic columns and 221 techniques, with every technique block colored by maturity and real-world incident frequency: dark gray for Feasible techniques never seen in any case study, light gray for Demonstrated techniques seen only in red-team exercises, and a pink-to-red ramp for Realized techniques scaled by the number of ATLAS Incident case studies that employ them. — MITRE ATLAS v2026.10, all 221 techniques across 16 tactics, colored by maturity and by how often the technique turns up in a case study MITRE types as an *Incident* rather than an Exercise. Gray means never seen in a real incident, dark for Feasible and light for Demonstrated. Red intensity runs from one incident up to eleven. Click to open at full resolution.

What the maturity labels actually measure

ATLAS stamps every technique with a maturity value of Feasible, Demonstrated or Realized, and it publishes a case-study catalog separately, so it is natural to read those as two independent signals about how real a technique is. They are not independent, and the check that shows it is simple: I compared all 221 techniques in v2026.10 against the whole case-study catalog, and the separation came out very nearly exact. Of the 117 techniques ATLAS grades Realized, 116 appear, directly or through a sub-technique, in at least one case study typed as an Incident, while none of the 78 it grades Demonstrated appears in an Incident at all, and none of the 26 it grades Feasible appears in any case study of either type. So maturity turns out to be, with one exception, the case-study record restated as a label, and not an independent judgment layered on top of it.

That matters because the catalog is mostly not incidents. Of the 77 case studies, 50 are Exercises, meaning red-team or research results, and 27 are Incidents. So counting how often a technique shows up across all case studies answers a different question from counting how often it shows up in a real attack, and the first count will rank a lab result above a breach. The matrix above is colored on incidents alone for that reason, and the wall's row order uses the same measure.

When I ran this check against v2026.06 in July, one technique broke the rule: AML.T0024.002 Extract AI Model was stamped Feasible while being employed by AML.CS0056, an Incident, and v2026.07 regraded it, and its parent, to Realized (v2026.10 has since retired that sub-technique). v2026.10 breaks the rule once, and in the other direction, because AML.T0052.001 Deepfake-Assisted Phishing, which was Feasible and employed by no case study in v2026.06 or v2026.07, is now graded Realized with no case study of either type behind it. I read that as MITRE grading on evidence outside its own catalog, which is the argument of the next section made from MITRE's side. The build names it as the one known exception and still fails on any new one, so a future release cannot quietly add another.

The catalog trails the attacks.

ATLAS added five case studies in v2026.07 and every one of them was an Exercise, so the Incident count sat at 18 from June until the end of October. I do not read that as a failure of curation, because writing an incident up to a standard where it can be technique-mapped is slow and careful work and the alternative is a catalog nobody can lean on, but it did mean that a defender reading maturity labels in August 2026 was reading a judgment formed against an incident record that had not moved since June. v2026.10 then added nine case studies, AML.CS0068 through CS0076, and all nine are Incidents, which takes the count to 27.

So I ran a separate research pass across the same window, collecting publicly documented real-world AI security incidents that were not yet in the ATLAS catalog and technique-mapping each one against the release current at the time. It returned 29, and v2026.10 turned out to be a better check on that pass than anything I could have designed, because six of the nine Incidents ATLAS added were already among the 29, as eight entries (three of mine describe one event that ATLAS catalogs as a single case study). Those eight now count once, under ATLAS's version, so the incident corpus behind this page is 27 ATLAS Incidents plus the 21 researched incidents ATLAS has not yet cataloged, 48 in all, and the count of distinct techniques with real-incident evidence goes from 116 in ATLAS alone to 129 merged. Two exercises the pass surfaced have also appeared in ATLAS since, as CS0064 and CS0067.

Widening the corpus changes the maturity picture in one specific way, and I want to be careful about what that does and does not show. Measured against ATLAS's own catalog the labels match the catalog for every Realized technique except Deepfake-Assisted Phishing. Measured against the wider record, 13 techniques that ATLAS grades below Realized turn up in an independently documented real attack, down from 22 on v2026.07, and the clearest case of the catalog catching up is Command and Scripting Interpreter, which I flagged here in August as Demonstrated while it appeared in nine of my 29, and which v2026.10 now grades Realized on three ATLAS incidents, with seven more from the research pass behind it. The sharpest case left is Credentials from AI Agent Configuration, graded Demonstrated, which appears in three of the researched incidents. That is a statement about how quickly a curated catalog can move, not a claim that anything was graded wrongly, and the two are worth keeping apart. The practical reading is that Realized means the evidence is already cataloged, and Demonstrated means it is not cataloged yet, which is a considerably weaker statement than not real.

Which techniques actually turn up in attacks

This is the count the wall's row order is built from. The first column is what ATLAS has cataloged, the second is what the research pass added, and the last is how many mitigations ATLAS maps to that technique. The pattern that jumps out is in the last column, because three of the seven techniques appearing in the most real incidents have no mapped mitigation at all.

Technique	Maturity	In ATLAS	Also found	Total	Mitigations
External Harms T0048	Realized	11	9	20	none
Exfiltration via Cyber Means T0025	Realized	8	10	18	1
Unsecured Credentials T0055	Realized	8	10	18	none
Supply Chain Compromise T0010	Realized	9	8	17	4
Valid Accounts T0012	Realized	11	4	15	3
Financial Harm T0048.000	Realized	6	9	15	none
Exploit Public-Facing Application T0049	Realized	7	8	15	2
User Execution T0011	Realized	5	9	14	4
LLM Prompt Injection T0051	Realized	5	5	10	8
Command and Scripting Interpreter T0050	Realized	3	7	10	1
Establish Accounts T0021	Realized	7	2	9	3
LLM Prompt Crafting T0065	Realized	5	3	8	none
Develop Capabilities T0017	Realized	8	0	8	none
Stage Capabilities T0079	Realized	4	4	8	1
Acquire Infrastructure T0008	Realized	7	1	8	1
Masquerading T0074	Realized	2	6	8	2
Supply Chain: Software T0010.001	Realized	3	5	8	5
Data from Local System T0037	Realized	5	3	8	none
Evade AI Model T0015	Realized	5	2	7	8
Obtain Capabilities T0016	Realized	7	0	7	1
Active Scanning T0006	Realized	5	2	7	3

Every technique appearing in seven or more of the merged corpus's 48 real incidents, 21 of 221. Ordered on the realized count, then realized plus demonstrated, the same rule the wall's rows use, and cut at a full tie group rather than a round number. Sub-technique use rolls up to the parent, which is the right treatment for a coverage question and the wrong one for a grading question, so the maturity column is read from ATLAS directly and never inferred from this count.

External Harms and Financial Harm sit near the top with nothing mapped to them, and I read that as defensible on MITRE's part, because those are outcomes rather than actions and you mitigate the thing that causes an outcome instead of the outcome itself. Unsecured Credentials is a different case. It is an ordinary intrusion technique imported from ATT&CK, it shows up in 18 real AI incidents against 10 for LLM Prompt Injection, and it still carries no ATLAS mitigation, so a defender working only from this framework would not be pointed at the credential hygiene the incident record says is doing a good share of the damage. Exploit Public-Facing Application sat beside it in August with nothing mapped, and v2026.10 gave it two mitigations, which is the kind of movement I would like to see reach Unsecured Credentials next.

How to read the wall

Rows are the 168 techniques that carry at least one mapped mitigation, because a row with nothing in it tells you nothing about which control to buy and those techniques get their own treatment further down. That filter is why the bands read 85 Realized, 61 Demonstrated and 22 Feasible instead of the 117, 78 and 26 in the full matrix. The rows band by maturity with Realized at the top, and inside a band they sort on the realized count alone, falling back to realized plus demonstrated only when two techniques tie. That ordering rule matters more than it sounds: an earlier version sorted on the two together, which let a technique with a lot of red-team attention outrank one that had actually hurt somebody, and once you are sorting a risk axis that is the wrong way round.

Columns are the 44 mitigations, split into a high-risk and a lower-risk group. Risk here is the number ofdistinct real incidents a mitigation is mapped into, cut at twelve, and distinct is the word doing the work. On v2026.10 that puts 20 of the 44 mitigations in the high-risk group, up from 13 of 37 on v2026.07, and the group grew because the mapping layer did, with at least three of October's new controls clearing the cut on arrival and each incident now carrying more mapped techniques (474 incident-technique pairs against 360), while the corpus itself only went from 47 incidents to 48, so I left the cut at twelve rather than re-tuning it after seeing the new data, which does mean the cut separates the two groups less sharply than it did. An earlier version of this page counted differently: it summed incident counts across every technique a control touched, so a control mapped to five techniques that all appeared in one single incident scored five. That inflates exactly the controls which are mapped most enthusiastically, because breadth of mapping and breadth of exposure are different quantities. AI Telemetry Logging (now AI Telemetry Logging and Monitoring) was the cautionary case, since in that version the old arithmetic gave it 14 where the incident record gave it nine.

Within each group the columns band by category, Policy then Technical-AI then Technical-Cyber, and inside a band they order as a burndown against the rows, so the leftmost column is the one covering the highest-risk technique, the next covers the highest-risk technique the first one missed, and so on down. The effect is that you read the top-left corner and get controls in the order the incident record says to care about them. I tried ordering columns to maximize mass in the top-left corner instead, which scored better on that metric and read worse, because the metric was measuring a shape while the picture is meant to be read as a sequence.

The bar beside each technique name stacks the two classes of evidence behind it, realized in dark red and exercise-only evidence in amber, and both counts merge ATLAS's own case studies with the research pass, so a technique that has only ever been exercised shows no red at all and a long amber tail. Bands and bars measure different things on purpose, and it is worth saying so before the picture confuses you: a band is ATLAS's own maturity label, a bar is the merged evidence record. Where a row carries red inside the Demonstrated band, you are looking at the catalog trailing the attacks, which is the finding rather than a mistake in the drawing. LLM Prompt Injection shows why the sort uses the red segment alone, because it carries a long exercise record against ten real incidents, and sorting on red keeps that exercise record from lifting it over Supply Chain Compromise, which has seventeen. An asterisk on a column marks a mitigation renamed to Predictive AI in v2026.07.

The full MITRE ATLAS technique matrix, 221 techniques, colored by mitigation context: each technique block carries a left-anchored stacked bar whose length is the number of mitigations mapped to it and whose segments are split by mitigation category, Policy, Technical-AI and Technical-Cyber, while the block's border encodes technique maturity independently of the fill, dashed for Feasible, thin and light for Demonstrated, solid black for Realized. — The same matrix, colored by mitigation context instead. Bar length is the mitigation count against a corpus maximum of 13, split into segments by category, and an empty block is one of the 53 techniques with nothing mapped to it. The border carries maturity separately, dashed for Feasible, thin and light for Demonstrated, solid black for Realized, so how real a technique is and what covers it can be read independently. 93 of the 168 covered techniques (55%) draw on more than one category, which is why the fill is a segmented bar rather than a single category color. Counts are direct edges only, so a parent technique gets no credit for what is mapped to its sub-techniques. Click to open at full resolution.

Where the coverage stops

53 of the 221 techniques in v2026.10, roughly a quarter of the framework, carry no mapped mitigation. The July version of this page reported that as a straight gap and I now think that was overclaiming, because a fair chunk of it is ground a defender has no control surface on in the first place. 23 of those 53 sit only in Resource Development or Impact, meaning adversary-side preparation like acquiring infrastructure or developing capabilities, and outcomes like Financial Harm and Societal Harm. A defender has no control surface over an adversary's decision to rent a server, and an outcome is mitigated by addressing whatever produced it. The grouping is rougher than it sounds, though, because the line itself moves between releases: LLM Prompt Crafting, which turns up in eight real incidents, sat in Resource Development in v2026.07 and is filed under AI Attack Adaptation in v2026.10, so it crossed onto the defender's side without anything about the technique changing, and I suspect some of that 23 is the same kind of filing decision rather than ground that is genuinely out of reach.

That leaves 30 techniques on ground a defender does own, 18 of them Realized, and those are the ones worth being annoyed about. They concentrate in Defense Evasion with eight, Reconnaissance with four, and Credential Access and Discovery with three each. Nine of the eighteen ATLAS itself grades Realized:

AI Agent Tool Poisoning, and its Implementation sub-technique
Poisoned AI Agent Tool
Corrupt AI Model
Escape to Host
Virtualization/Sandbox Evasion
Exfiltration via AI User Interface
Crafted AI Assistant Links
Unsecured Credentials

That is a list heavily weighted toward the agentic deployments people are shipping right now.

The thinness shows up in the covered half too. Across all 117 Realized techniques the median number of mapped mitigations is two, up from one on v2026.07, and 32 of them have none, so even where the map is filled in it is often filled in with only a suggestion or two. That is the honest shape of what a defender has to work with: a framework that names the attacks well and, so far, points at a fairly narrow set of answers.

What to deploy first, and where it stops paying

Coverage counted per control is not much use, because the second control you buy is worth what it adds rather than what it covers on its own. So I ran a greedy set cover over the 48-incident corpus, taking the control that reaches the most still-unreached ground, removing that ground, and repeating. The unit is the pair of an incident and a technique employed in it, 474 of them in total, because measuring on whole incidents saturates almost immediately: three controls are relevant to all 48, since touching one technique in a fifteen-technique intrusion counts the whole intrusion. That saturation is itself worth reporting, because it is why the unit below is the incident-technique pair instead of the whole incident.

#	Mitigation	Category	Adds	Cumulative	Efficacy evidence
1	Threat Intelligence Program	Policy	+84	17.7%	no independent assessment
2	Control Access to AI Models and Data in Production	Policy	+61	30.6%	no independent assessment
3	Restrict Library Loading	Technical-Cyber	+41	39.2%	no independent assessment
4	AI Red Team	Policy	+34	46.4%	no independent assessment
5	Control Access to AI Models and Data at Rest	Policy	+27	52.1%	Supported as hygiene; miscoped
6	AI Agent External Resource Lifecycle Management	Policy	+26	57.6%	no independent assessment
7	AI Honeypots	Technical-AI	+10	59.7%	no independent assessment
8	AI Telemetry Logging and Monitoring	Technical-Cyber	+10	61.8%	Detection supported, conditionally
9	Limit Model Artifact Release	Policy	+9	63.7%	no independent assessment
10	Generative AI Guardrails	Technical-AI	+8	65.4%	Partially supported, by sub-type
11	Deepfake Detection	Technical-AI	+6	66.7%	Effective narrowly
12	AI Agent Scope Drift Detection	Technical-AI	+4	67.5%	no independent assessment
13	Predictive AI Model Hardening	Technical-AI	+4	68.4%	Partially supported
14	Verify AI Artifacts	Technical-Cyber	+3	69.0%	Partially supported, narrowly
15	Adaptive AI Response Degradation	Technical-AI	+3	69.6%	no independent assessment
16	Code Signing	Technical-Cyber	+2	70.0%	no independent assessment
17	Limit Public Release of Information	Policy	+2	70.5%	no independent assessment
18	Vulnerability Scanning	Technical-Cyber	+1	70.7%	no independent assessment

Every row asserts relevance, never interdiction: no control in this table has been shown to stop an attack, and the one direct test of that gap, run on ATLAS v2026.06, returned zero of seventeen. Marginal coverage of 474 incident-technique pairs across 48 real incidents. "Adds" is the pairs that control contributes that nothing above it already covers.

Three things fall out of that table, and the first is that the curve is steep at the start and flat by the end, so three controls reach 39.2% of the observed attack surface, five reach 52.1%, and twelve reach 67.5%. Then it stops: 70.7% is the ceiling for the whole framework, because all 44 mitigations together map to 335 of the 474 observed technique-instances and the other 29.3% of what actually happened has no mapped mitigation anywhere in ATLAS. And only eighteen of the 44 contribute anything at all, since after the eighteenth pick every remaining control is a subset of ground already covered, which means a defender working down the framework by name rather than by marginal coverage will spend a long stretch adding nothing.

The order at the top changed in a way worth reading carefully. On v2026.07 AI Red Team led the curve, and on v2026.10 the first pick is Threat Intelligence Program, one of the seven mitigations added in October, which is relevant to 36 of the 48 incidents. AI Red Team falls to fourth because of overlap, since on its own it touches 82 of the pairs, but by the time it is picked the first three controls have already taken most of that ground and it adds 34. Two more of October's additions sit in the top seven, AI Agent External Resource Lifecycle Management at sixth and AI Honeypots at seventh, so the head of this curve is now led by controls that have been in the framework only since 28 October 2026, and none of the three had a published efficacy assessment when I rebuilt this page on 2 November.

None of that is a criticism of the controls further down. Several of them carry better efficacy evidence than the ones at the top, which is the whole difficulty with reading this table as a shopping list.

A three-part figure titled Where the catalogues stop: 31 AI attack steps no control reaches. At the top, a burn-down chart of the share of 290 incident steps from 27 ATLAS Incident case studies not yet reached, as ATLAS mitigations are added in greedy order and then ATT&CK mitigations on the familiar steps ATLAS leaves to general cyber controls. Each bar stacks familiar steps in orange over new steps in red, labelled 19.3%, 50.7%, 64.5% and 71.7% reached after one, four, seven and ten ATLAS controls, falling to a floor of 31 steps, 30 new and 1 familiar. A black line shows the incident-weighted curve, a dashed amber line the 469 exercise steps, and a gray band the 90% range of 1000 degree-preserving shuffles. A side panel shows each category alone: Policy 63.8%, Tech-Cyber 60.3%, Tech-AI 56.2%, all ATLAS 75.5%, ATT&CK 98.6% of familiar steps. Below, a matrix of the 107 techniques seen in incidents against the controls in the same order, colored by category, and on the right the 31 unreached steps grouped by technique with their incident identifiers. — The unit is one employs-step of an ATLAS Incident case study, 290 steps across 27 incidents, from the ATLAS public record only, so the 21 researched incidents behind the table above are left out. Columns are controls in greedy order, ATLAS mitigations first and then ATT&CK mitigations applied only to the familiar steps, and each catalog stays its own layer instead of feeding a combined score. A step counts as reached when a control is mapped to it, which is relevance rather than interdiction. The dashed amber line is the 469 steps of the 50 Exercises, drawn separately because 79.5% of exercise steps are ATLAS-native against 50.3% of incident steps. MITRE ATLAS v2026.10 and MITRE ATT&CK Enterprise v20.1 STIX, built by`build_control_burndown.py` on 9 November 2026 and reproduced by an independent re-implementation. Click to open at full resolution.

Where the catalogs stop

The table above ranks controls on incident-technique pairs across the 48-incident corpus, and this figure asks a narrower question of a stricter record, taking every step of every ATLAS Incident case study and watching what is left as controls are added. ATLAS's own mitigations reach 19.3% of the 290 steps with one control, 50.7% with four, 64.5% with seven and 71.7% with ten, and then stop at 75.5% (219 of 290), with only 17 of the 44 mitigations adding a step at all. Much of what ATLAS leaves is deliberate, because it defers the techniques it borrows from ATT&CK to general cyber controls, and of the 41 familiar steps it leaves unmitigated, ATT&CK's own mitigations reach 40. On its own, ATT&CK reaches 142 of the 144 familiar steps (98.6%). That leaves 31 steps, 30 new and 1 familiar, across 13 techniques in 18 of the 27 incidents, that no mitigation in either catalog reaches, and Financial Harm, LLM Prompt Crafting and two enterprise discovery techniques account for 20 of them.

The same split puts the Unsecured Credentials complaint above in context. Its incident steps carry no ATLAS mitigation, but ATT&CK maps eleven mitigations to them, so a team already running an ATT&CK-based program is pointed at the credential hygiene, and the gap is in reading ATLAS on its own.

The order differs from the table above, which is expected once both the unit and the corpus change. Threat Intelligence Program and Control Access to AI Models and Data in Production still lead, but AI Honeypots falls from seventh in the table to sixteenth on this unit and corpus, and AI Red Team, fourth in the table, adds no step here at all, even though it and Control Access to AI Models and Data in Production are the two controls that between them touch all 27 incidents, because every step it touches is already reached by the seventeen controls that do add one. That sensitivity is what the null model tests. I shuffled each catalog's mitigation mapping 1,000 times, keeping every control's technique count and every technique's control count, and reran the same greedy selection, and the real ATLAS curve sums to 5.41 over its first ten controls against a shuffle band of 4.66 to 5.57, with 16.1% of shuffles doing at least as well. So the order is not distinguishable from the shuffles. The 75.5% ceiling and the 31-step floor are a different matter, since a shuffle that keeps every technique's control count cannot change which techniques carry a mapping, so those are facts about the map rather than statistical results.

What I take from that is that the category ceilings say more than the order does. The ten Policy controls alone reach 63.8% of the steps, Technical-Cyber 60.3% and Technical-AI 56.2%, so governance and conventional controls each carry more of the real incident record than the AI-specific controls do, and inside the first ten the order mostly reflects how broadly each control is mapped, which is exactly what the shuffles keep. I have not run the same null against the 474-pair table above, and my guess is that it would come out much the same, which is a reason to read that table as where to look first rather than as a ranked sequence. Everything in this figure is relevance rather than interdiction, and the zero of seventeen further down is still the only interdiction test I have, run on v2026.06.

Coverage and efficacy are different columns.

I deliberately did not multiply the two together. Folding a judgment-derived efficacy weight into a coverage count produces a single tidy number with a precision neither input has, and the resulting ranking would look authoritative while being mostly an artifact of how I chose the weights. So efficacy rides alongside coverage in that last column, and you read both.

The first thing to notice is how little there is to read. Of the eighteen controls carrying the coverage curve, twelve have no independent efficacy assessment at all, including the top four, so the honest statement about Threat Intelligence Program, Control Access to AI Models and Data in Production, Restrict Library Loading and AI Red Team is that I could find no published measurement either way, which is not the same as saying they work. Five of those twelve are new in v2026.10, so for them the gap is mostly a matter of age. An absent assessment is a different finding from a control being tested and failing, and the two get used differently: the first is a reason to deploy and measure, the second is a reason not to lean on the thing.

Where evidence does exist it splits two ways, with a third group that is a coverage shape rather than a verdict. Some controls carry broad coverage and no measured outcome, so Control Access to AI Models and Data at Rest rests on a mature body of conventional access-control evidence with no measured effect on breach incidence in an AI setting, and its real-world failure mode is misconfiguration, which the control text does not address. And some carry broad coverage with published evidence of no effect in the sub-claim a buyer probably means. The third group is not an evidence category at all but a shape worth noticing: a few controls reach a lot of ground from a small mapped footprint, and Restrict Library Loading is the clearest of them, relevant to 25 distinct incidents from eight mappings, with Vulnerability Scanning and Code Signing in the same family of conventional controls pointed at AI-stack intrusions. All three are also among the unassessed twelve, so what recommends them is a long track record outside the AI setting and a low deployment cost, and I should not dress that up as measured efficacy here.

Generative AI Guardrails is the case worth spelling out, because the single ATLAS entry enumerates eight distinct implementations in its own description. The deterministic and architectural forms have positive published numbers: in AgentDojo(Debenedetti and colleagues, NeurIPS 2024) a pre-execution tool filter cut GPT-4o's targeted attack success from 57.7% to under 8% while benign utility rose from 69% to 73%, against a static rather than adaptive attacker. The statistical filtering forms do not. A systematic 2025 attack study, The Attacker Moves Second (Nasr, Carlini, Sitawarin and colleagues), tuned general optimization techniques against twelve recent defenses, including Spotlighting, Prompt Sandwiching, Circuit Breakers, PromptGuard and Model Armor, and pushed attack success above 90% on most of them, where the majority had originally reported near-zero. That study is a preprint rather than a peer-reviewed result and should be weighted accordingly, but the direction is consistent across the independent evaluations I found. Buying "guardrails" without naming the sub-type is how a defender ends up with the half that broke.

Guardrails is also, of the controls that already existed, the one whose mapping moved most in v2026.10. MITRE dropped its edges to Supply Chain Compromise and four other techniques and added seventeen LLM- and agent-side ones, so its mappings rose from 23 to 35 while the distinct real incidents it reaches fell from 30 to 20, which took it from sixth on the coverage curve to tenth. I think the new mapping is the more accurate one, because the supply-chain incidents it used to collect were mostly not ones a prompt filter would plausibly have touched, and the narrower mapping points the control at the prompt surface where the evidence above actually applies.

Deepfake Detection is the mirror image of Guardrails, a control whose evidence is strong and whose scope is narrower than its name. NIST's 2023 evaluation of 82 passive presentation-attack detection algorithms, IR 8491, put the best performers at an APCER of 0.0 for photo print, replay and silicone-mask attacks while rejecting 1% of genuine users, which is a standards-body measurement at a usable operating point and should be stated without hedging. It is also explicitly not a measurement of the thing most people mean, because NIST records that digital injection attacks, where synthetic media is introduced electronically rather than presented to a camera, were not evaluated. The control works against someone holding a printed face up to a camera and says nothing about a video stream substituted upstream of it.

What a mapping actually claims

This is the caveat the whole artifact rests on, so it belongs here instead of in a footnote. A mapping says a mitigation is relevant to a technique, but it does not say the mitigation would have stopped the attack, and ATLAS carries no efficacy measurement to support the stronger reading. I tested that gap directly, though on an older release than this one: across nine recent agentic and generative-AI case studies in ATLAS v2026.06, 17 mapped pairs of mitigation and case looked like they might plausibly interdict a step, and under an adversarial refuter instructed to default to skepticism, zero of the 17 survived. That test ran against the 247 mapping edges v2026.06 carried, and the mapping layer has doubled since, to 494 edges in v2026.10, so read zero of seventeen as a dated measurement taken on a much smaller map. It is the last measurement I have, and I have not re-run it against the current release.

So read a filled cell as "mapped to a real, recent technique" and never as "this would have worked". Everything above answers where attention should go first, but nothing above answers what will stop the attack, and I would sooner hand you a prioritized list with that limit stated than a coverage score that quietly implies more.

Bottom line: the framework got substantially better across two releases, it now points at a defensible first five or six controls, it runs out of things to say at 70.7% of what the incident record contains, and the evidence that any of it works is thinner than the map's confidence suggests, thinner still for the new controls now leading the curve.

Method and provenance

Built from MITRE ATLAS v2026.10 (Apache-2.0), released 28 October 2026 and pinned, with every figure regenerated from the pinned copy and never from a live query. Retired identifiers are remapped explicitly and the build asserts that each remap target resolves in the current release, which is what stopped two rows disappearing silently when AML.T0058 and AML.T0104 were consolidated into the AML.T0115 family in v2026.07, and which now holds across all eight identifiers retired between v2026.06 and v2026.10, three of which turned up in seven rows of the research corpus. One of those remaps, AML.T0024.002 onto AML.T0005.001, is inferred rather than published by MITRE, and the build lists that row separately.

On the six mitigations v2026.07 renamed: v2026.06 stated them generically, so Model Hardening read asuse techniques to make AI models robust to adversarial inputs such as adversarial training or network distillation, which a security architect standing up an LLM deployment could quite reasonably have applied to one. Both the name and the description were rewritten. The second cautionary figure behind the distinct-incident correction sits here too: Use Ensemble Methods scored 13 under the old arithmetic across 11 mappings while touching 11 distinct incidents.

The incident corpus is 27 ATLAS case studies typed as Incident plus 21 real-world incidents documented publicly but not yet cataloged. Those 21 are what remains of 29 from a separate research pass, technique-mapped and then checked back against the v2026.06 object graph it was mapped on: 230 candidate mapping rows, incidents and exercises together, across 76 distinct techniques, with no invalid identifiers, no technique-name mismatches and no maturity mismatches on that release. Eight of the 29 entries match six case studies ATLAS added in v2026.10 and are counted once, under ATLAS's version. Nine mapping rows whose case type the research pass recorded as unclear are excluded from both the incident and the exercise counts, since a case that cannot be typed should not inflate either one. Every primary source behind those 29 resolves, and the most heavily weighted of them are corroborated by reporting independent of the research pass itself. A small number of scale figures inside individual write-ups did not reconcile against their primary sources on review and none of them is used here, since this page uses the corpus only as a count of incidents and of the techniques employed in them.

Efficacy verdicts come from a separate assessment of the published literature and are attached to each recommendation and never folded into any score. Evidence tiers follow the rubric on the research page: A for peer-reviewed research, ratified standards and named production deployments, B for practitioner talks and controlled first-party measurements, C for vendor-published material, blogs and analyst reports with the bias flagged, D for speculation. A vendor's own documentation counts as B for what a feature does and C for any claim about how well it works. Where a control has no assessment I say so instead of inferring one from silence. The Secure Controls Framework is deliberately excluded from the weighting, which keeps this a single-license ATLAS-derived artifact and clean to publish.

Data sources and licences: MITRE ATLAS v2026.10 (atlas-data, Apache-2.0) and MITRE ATT&CK® Enterprise v20.1 STIX. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. ATT&CK is used under MITRE's non-exclusive, royalty-free licence for research, development and commercial purposes; see the ATT&CK terms of use.

AI-drafted, human observed