Mapping the AI and Agentic Systems Threat Taxonomy to STRIDE, OWASP, MITRE ATLAS, CAPEC and CWE

TL;DR

• Every entry in the AI and Agentic Systems Threat Taxonomy, the reference for my Elevation of Autonomy deck, is mapped to STRIDE, the OWASP Top 10s, MITRE ATLAS, CAPEC and CWE, and the privacy cards to LINDDUN.
• Coverage: OWASP references on 22 of 30 cards, ATLAS 23, CWE 18, CAPEC 5. 12 entries have neither a CAPEC nor a CWE, and that’s a finding in itself.
• Every ID was checked against MITRE’s data on 3 November 2026 (ATLAS 2026.10, CAPEC 3.9, CWE 5.0). Discouraged CWEs and loose tags were removed, and one reference printed on a card turned out to be wrong.
• The crosswalk shows two OWASP entries that no card cites: Data and Model Poisoning (LLM04 in 2025, LLM05 in 2026) and ASI05 Unexpected Code Execution.
• The cards print the 2025 OWASP LLM IDs. The 2026 edition renumbered eight of the ten, so the taxonomy now carries both.

In my previous post I published the AI and Agentic Systems Threat Taxonomy: 30 entries, one per Elevation of Autonomy card, each with the card’s threat and prompts, a mitigation principle and design measures. This post is about the other half of each entry: the mappings.

Mappings are what let a finding travel. A finding tagged EOA·S9 means something to a team that has played the deck. The same finding tagged with an OWASP, ATLAS or CWE identifier means something to a compliance reviewer, a red team or a vulnerability management tool. So let’s dig into how the mappings were built, what they show, and where they come up short.

The frameworks

• STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege): the threat categories most teams already threat model with. Every entry has at least one.
• LINDDUN: the privacy threat categories, used for the five Clubs (privacy) cards alongside STRIDE, because STRIDE has nowhere to put “the model infers someone’s health from their calendar”.
• OWASP: the Top 10 for LLM Applications (LLM01 to LLM10) and the Top 10 for Agentic Applications (ASI01 to ASI10). These are the references printed on the cards, which use the 2025 LLM numbering; more on that below.
• MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems): adversary techniques against AI systems, with case studies. Version 2026.10.
• CAPEC (Common Attack Pattern Enumeration and Classification): attack patterns. Version 3.9.
• CWE (Common Weakness Enumeration): weaknesses. Version 5.0.

How the mappings were checked

A mapping is only useful if it’s right, and a loose one is worse than none: it sends the reader to the wrong place with confidence. So every ID was checked rather than taken from memory:

1. ATLAS and CAPEC IDs against MITRE’s published data: the ATLAS 2026.10 release and the CAPEC 3.9 STIX bundle. Every ID exists and isn’t deprecated.
2. CWE IDs against MITRE’s definition pages for CWE 5.0, including each entry’s vulnerability mapping usage. CWEs MITRE marks as Discouraged for mapping were removed. The obvious casualty is CWE-1426 Improper Validation of Generative AI Output, which looks perfect for Hallucinated Facts (EOA·DQ) and Wrong Abstraction (EOA·T1) but is Discouraged, so those entries carry no CWE rather than a misleading one.
3. Fit. Each ID was then judged against the threat text as good, loose or wrong. Loose tags went. For example, CAPEC-242 Code Injection is only an analogy for prompt injection (the card itself says “conceptually”), and CAPEC-115 Authentication Bypass only applies to a Geometric Attack (EOA·T6) when the model gates authentication, so neither appears in the mapping columns.

The references printed on the cards are shown as printed, with one exception. The Confused Deputy Across Servers card (EOA·H9) cites CAPEC-141, which is Cache Poisoning. That doesn’t describe the threat, so the taxonomy leaves it out and maps the card to CWE-441 Unintended Proxy or Intermediary (‘Confused Deputy’) instead. That one’s on me.

Coverage at a glance

Across the 30 entries:

• OWASP: 22 cards cite an LLM or ASI entry.
• MITRE ATLAS: 23 entries map to 39 distinct techniques.
• CWE: 18 entries map to 18 distinct CWEs.
• CAPEC: 5 entries.

Read by suit, the picture is clear. Every Spades, Hearts and Diamonds entry (adversarial, autonomy and data) maps to OWASP and ATLAS, and most map to a CWE. The Clubs (privacy) map to almost nothing outside LINDDUN. And the Trumps (structural hazards) map well for the adversarial machine learning cards and only patchily for the product and architecture ones.

STRIDE

An entry can map to more than one category, so the totals add up to more than 30: Tampering 14, Elevation of privilege 12, Information disclosure 10, Spoofing 6, Repudiation 3, Denial of service 2.

At first glance Denial of service looks under-represented. It isn’t. Unbounded Consumption (EOA·DJ) and Cascading Failure (EOA·HJ) carry it, and the agentic version of denial of service is usually a bill, not an outage. The bigger story is Tampering and Elevation of privilege: in an agentic system, the attacker’s goal is usually to change what the agent does, and then to borrow its authority.

OWASP: the crosswalk

Turning the card references around gives a crosswalk from each OWASP entry to the cards that cite it. Two things stand out.

Eight cards cite no OWASP entry at all, by design. The five privacy cards and three of the Trumps (Adversarial Subspace, Geometric Attack and Decision Boundary Transfer) cover threats the OWASP lists don’t: the generation of personal data, and the mathematics that bounds what any model-layer defence can achieve. Context Rot (EOA·T5) is the odd one out: it cites six OWASP entries, as the amplifier that makes each of them worse over a long session.

Two OWASP entries have no card.

• Data and Model Poisoning (LLM04:2025, LLM05:2026). Memory Poisoning (EOA·SJ) covers memory, and Vector and Embedding Weakness (EOA·DK) covers writes to the retrieval corpus, but no card covers poisoning training or fine-tuning data.
• ASI05 Unexpected Code Execution. Improper Output Handling (EOA·S10) has a design measure for sandboxing generated code, but there’s no card that makes a table stop and ask what happens when the agent writes and runs code.

Both are candidates for the next version of the deck. Until then, if your system fine-tunes on user data or lets an agent execute code, add them to your review by hand.

The 2026 renumbering

The cards were printed against the 2025 edition of the OWASP Top 10 for LLM Applications. In August 2026 OWASP published the 2026 edition, and it reordered the list: Prompt Injection and Sensitive Information Disclosure kept LLM01 and LLM02, but the other eight moved, and System Prompt Leakage was renamed Hidden Context Exposure with a broader scope.

That matters more than it sounds. A finding tagged “LLM06” meant Excessive Agency in 2025 and means Unbounded Consumption in 2026. If your reports, test cases or questionnaires use bare LLM numbers, they are now ambiguous.

So the taxonomy keeps the references exactly as printed on the cards and adds the 2026 equivalent next to them, always written with the year:

Note to anyone writing findings: always write the OWASP LLM ID with its year (LLM06:2025 or LLM03:2026). The EoA ID doesn’t have this problem: EOA·HA is Excessive Agency on every version of the deck.

The Agentic Top 10 has only had one edition so far, so the ASI IDs on the cards are current.

MITRE ATLAS

ATLAS is where the taxonomy meets the attacker. 23 entries map to 39 distinct ATLAS techniques, and ATLAS rates each technique’s maturity: 20 of the 39 are Realized (used in real attacks), 17 Demonstrated (shown by researchers) and 2 Feasible.

ATLAS also links techniques to its case studies, which gives a rough measure of how much documented evidence sits behind each card.

Adversarial Subspace (EOA·T7, 30 case studies) and Prompt Injection (EOA·SA, 29) lead, which won’t surprise anyone. What’s more interesting is the bottom of the chart. Seven entries have no ATLAS technique at all: the five privacy cards, Context Rot and Wrong Abstraction. ATLAS describes what an adversary does, and none of those seven needs an adversary. A model that invents facts about a person, or forgets its safety instructions on turn 50, or a team that treats a summary as the system of record, causes harm with nobody attacking it.

That’s exactly why I don’t use ATLAS alone for elicitation. It’s the right tool for sequencing an attack path and rating likelihood once you’ve found a threat. It isn’t the right tool for finding the threats that come from the design itself.

Note to AppSec teams: tag AI findings with both. The EoA ID says what a sound design should have done; the ATLAS technique says how an attacker gets there and how mature that technique is. Together they give you the fix and the likelihood.

CAPEC and CWE: built for code

CAPEC maps to 5 entries and CWE to 18. The CWEs that come up most are CWE-1427 Improper Neutralization of Input Used for LLM Prompting, CWE-1357 Reliance on Insufficiently Trustworthy Component and CWE-1039 Inadequate Detection or Handling of Adversarial Input Perturbations in Automated Recognition Mechanism, three entries each.

12 entries have neither a CAPEC nor a CWE. They are Tool Misuse, Memory Poisoning, Cascading Failure, Rogue Agent, Hallucinated Facts, all five privacy cards except Minimisation (which maps to CWE-201), Context Rot, Excessive Autonomy by Design and Wrong Abstraction. Some, like Memory Poisoning, are new enough that the catalogues haven’t caught up. Most are properties of the system or the product: there’s no line of code to point at when the problem is that a confirmation was removed because the demo felt smoother.

I don’t think that’s a failure of CAPEC or CWE. They were written to describe code and the attacks on it, and they do that well. It’s a reminder that a weakness catalogue can’t be your threat model for an AI system. If a team’s only security review is a scanner mapped to CWE, those 12 threats are invisible to it.

Where to find the mappings

• On the suit pages, each entry lists its mappings with links to MITRE and OWASP, and each page has a mapping table image: Adversarial, Autonomy, Data, Privacy, Structural Hazards.
• In the Excel file, as columns you can filter.
• In SKOS, CAPEC and CWE are skos:closeMatch links and ATLAS techniques skos:relatedMatch.
• In STIX 2.1, they are external references on each attack pattern, with the EoA ID as the taxonomy’s own external ID.

All four downloads are on the overview page.

Final thoughts

Mapping a taxonomy is a good way to audit it. This exercise caught a wrong reference on one of my own cards, removed more than a dozen draft tags that looked right and weren’t, and showed two OWASP entries the deck doesn’t yet cover. It also showed, with numbers, the point the Trumps make in words: a large part of the AI threat surface is about design and product decisions, and the catalogues built for code and for adversaries can’t see it.

The mappings will be updated as ATLAS, CWE and the OWASP lists move, and each update will be recorded in the taxonomy’s version table.

Stay tuned!

References

1. Crawley, B. (2026) AI and Agentic Systems Threat Taxonomy, v1.0. https://ostering.com/taxonomies/ai-agentic-systems/
2. Crawley, B. (2026) Elevation of Autonomy card deck. https://github.com/BrettCrawley/elevation-of-autonomy
3. MITRE. ATLAS (2026.10). https://atlas.mitre.org/ and data: https://github.com/mitre-atlas/atlas-data
4. MITRE. CAPEC (3.9). https://capec.mitre.org/
5. MITRE. CWE (5.0), including the CWE Vulnerability Mapping guidance. https://cwe.mitre.org/
6. OWASP GenAI Security Project. Top 10 for LLM Applications (2025 and 2026 editions) and Top 10 for Agentic Applications (2026). https://genai.owasp.org/
7. Microsoft. The STRIDE threat model. https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
8. LINDDUN privacy threat modeling. https://linddun.org/