The attack surface: the eight classes, and the frameworks that name them

A taxonomy earns its place in an engagement in exactly one way: it is the completeness check you run after open-ended exploration, so that the report can say which surfaces were explored and which were not. That is the fourth of the four things a report may claim, and it is the only one a taxonomy can supply. Everything on this page exists to make that fourth claim honest.

Here is the whole list, with where each item sat in the previous edition. Read the right-hand column first. Four rows in it are the reason this session exists.

How the 2026 ranking was made, and why it is the best teaching moment on this page

The ranking is 75% community vote and 25% incident data, and the incident half was drawn from 7,714 real incidents, of which 6,639 were classifiable. That is a serious evidence base by the standards of this field. Now the part worth stopping on.

There is a second list, released in December 2025, running ASI01 to ASI10. It is not a replacement and not a subset. The two lists divide the ground by a rule worth memorising, because it decides which taxonomy your finding belongs in and therefore who reads it.

Applied to Beacon: the Analyst Bot writing SQL that a warehouse executes is squarely an LLM-list problem right up until you notice the query runs with a credential, at which point ASI03 Identity and Privilege Abuse joins LLM10:2026 Improper Output Handling on the same finding. The Support Bot that can issue a refund credit is an actor by any reading, so its worst findings will carry ASI02 alongside LLM03:2026. The Insight Bot caches what it reads, which is ASI06 Memory and Context Poisoning territory even though nothing it does looks agentic in a demo.

OWASP gives you categories. ATLAS gives you techniques with IDs you can put in a ticket, tactics that say where in an operation a technique sits, and - new in the version 6 schema - an evidence grade that tells you what to test first.

The two v6 fields worth building a workflow around

• maturity grades the evidence behind a technique: Realized 68, Demonstrated 92, Feasible 18. Realized means it has been observed in the wild. That is a ready-made test-prioritisation axis and you should use it exactly that way - test Realized first, put Demonstrated on the watch list, and let Feasible sit in the backlog until something changes. It is the cheapest defensible ordering argument you will ever get to make to a stakeholder who wants everything tested at once.
• platforms shows Agentic AI 119, Generative AI 92, Predictive AI 70, Enterprise 61. Agentic AI is now the largest tag in the dataset. If your inventory says you have "a chatbot" and your ATLAS coverage is drawn from the Generative AI tag alone, you are working from the smaller half of the map.

The technique IDs for Beacon's surface

These are the rows you will actually cite in findings for the rest of the builder track. All verified from the 2026.07 dataset.

NIST AI 100-2e2025 - the objective layer above both

NIST's adversarial ML taxonomy classifies by what the attacker is trying to achieve, which is the layer that survives when the technique names change. Five objectives: NISTAML.01 Availability Breakdown, .02 Integrity Violation, .03 Privacy Compromise, .04 Misuse Enablement - GenAI only, and .05 Supply Chain. Attacks are then classified on five axes: system type, lifecycle stage, properties violated, attacker capability and access, and attacker knowledge.

Two structural points to carry forward. First, NIST taxonomises predictive AI and generative AI separately, and the separation is not cosmetic - the attack surfaces genuinely differ, and a control inventory written for one does not transfer. Second, .04 Misuse Enablement exists only on the GenAI side, because it is the objective that has no predictive-model analogue: the attacker is not corrupting your system, they are using it as a capability. That distinction is why misuse findings so often fall between the security team and the trust-and-safety team, and why b1 asked you to name the two tracks and their owners before the engagement starts.

A taxonomy that lives in a slide is decoration. A taxonomy that lives in the test-case schema is infrastructure, because every finding then arrives carrying the IDs a reviewer needs to place it. Build the schema now and the rest of the builder track just fills it in.

Here is the same eight-class taxonomy from the other side: not what an attacker does, but what each control actually removes. Read the top row before anything else. It belongs to the control every team reaches for first, and it is the only row on the board with zeroes in it.

• Search your own wiki, tickets and slide decks for "LLM05". Every hit that means improper output handling is a document written against the 2025 list. You are not looking for errors so much as for how old your internal mental model is.
• Fill the schema from Demo 1 for one real system you own. Eight rows, four framework references each. The rows you cannot fill are the more interesting output.
• Pull the ATLAS maturity field for the techniques on your rows and sort by it. Write down the Realized ones. That list, not your instinct, is your test order for the first sprint.
• Find every Realized technique on your map with no mitigation mapped and, for each, write the one sentence describing what bounds the consequence today. If the sentence is "nothing", you have found the first item for b9.
• Check one automated ATLAS mapping by hand against the dataset. If your tooling predates the v6 rename, the ATT&CK column will be quietly empty rather than wrong, which is harder to notice.

Every framework, figure and quotation on this page traces to a primary source catalogued in this course's source map, verified 2026-08-14. This page covers: