Summary: Four control sets in this vault — ATLAS mitigations, Code of Practice Appendix 4, OWASP ASI playbooks, OWASP Top 10 prevention guidance — what each is for, what each protects, and why no two are substitutes.
Sources: raw/MITRE-ATLAS/AML.M00*.md; raw/Laws/Overview of the Code of Practice...md; raw/Agentic/Agentic-AI-Threats-and-Mitigations-1.1.pdf; raw/OWASP-Top-10-for-LLMs/
Last updated: 2026-07-29
The vault records four attack taxonomies. It also holds four control sets, and they divide the problem just as cleanly — but nobody says so, because each is published attached to its own taxonomy.
Side by side
| ATLAS mitigations | CoP Appendix 4 | ASI playbooks | Top 10 prevention | |
|---|---|---|---|---|
| Count | 35 mitigations | 5 control families | 6 playbooks, ~90 controls | 10 entries |
| Granularity | Per technique | Per control family | Per threat group | Per risk |
| Protects | The deployed system | Unreleased weights | Agent behaviour and seams | The LLM application |
| Binding | No | Voluntary (GPAI systemic-risk) | No | No |
| Structure | mitigates pairs with per-pairing text | Prescriptive requirements | Proactive / reactive / detective | Prose per risk |
| Agentic coverage | Substantial | Almost none | Total | Partial (LLM06) |
| Weight protection | Thin | 256-bit, TPM, attested TEEs, copy registry | None | None |
| Implementability | High — concrete, per-technique | High — specifies numbers | Mixed — a third name capabilities that don’t exist | Moderate |
| Known coverage gap | 56% of techniques have zero mitigations | Nothing on prompt injection or agentic containment | No secure-design method | Granularity too coarse for agents |
What each is actually for
ATLAS mitigations — the only technique-level control catalogue in the corpus. Each mitigates relationship carries its own applicability text, so the same control reads differently against different techniques. Use it when you have a specific technique and need to know what answers it. The 35 split 16 Technical–AI / 12 Technical–Cyber / 7 Policy, which carries its own message: roughly a third of defending AI systems is ordinary security engineering.
Code of Practice Appendix 4 — a hardening baseline for the parameter file. Read as a whole it defends against weight theft, not misuse of a deployed model. It is the most prescriptive set here and the only one with numbers. Use it if you hold unreleased weights that matter; it is nearly silent otherwise.
ASI playbooks — the only set that addresses systems that act. Organised proactive/reactive/detective and scoped by a decision path that prunes against a specific architecture. Use it for anything agentic. Sort its controls before adopting — see the implementability sort.
Top 10 prevention guidance — the shared vocabulary. Too coarse to build from directly, and LLM06 Excessive Agency is doing the work of three separate agentic threats. Use it to name risks for people who need names, then descend to one of the other three.
Why none is a substitute
ATLAS and CoP are close to complementary. Technique-level coverage for the deployed system plus a hardening baseline for the weights. Neither alone is sufficient — and the pairing was already noted in ATLAS mitigations before the agentic material was ingested.
ASI fills the gap both leave. CoP Appendix 4 “has nothing on prompt injection, tool poisoning or agentic containment beyond ‘sandboxing and code execution isolation’.” ATLAS has substantial agentic coverage but at technique granularity, with no architectural scoping. ASI provides the architecture, the decision path, and the seam threats — inter-agent protocols, delegation chains, human-boundary exploitation — that neither of the others models.
None of the four covers secure design. All are runtime or organisational. See defense-in-depth.
Read the coverage gaps as gaps, not coverage
The single most important caution across all four:
97 of 173 ATLAS techniques (56%) have zero mapped mitigations.
Using any of these as a checklist produces a false picture. An unmitigated technique is not one you have handled — it is one where the framework has no published answer. The same reading applies to the seven ASI threats with no Top 10 counterpart, and to CoP Appendix 4’s silence on the agentic surface: absence of a control is a finding, not a pass.
Which to reach for
| Situation | Start with |
|---|---|
| You hold unreleased weights | CoP Appendix 4 |
| You are shipping an LLM feature | T10, then SC application defences |
| You are shipping agents | ASI, Playbook 3 first |
| You have a specific technique to answer | ATLAS |
| You need to brief non-specialists | T10 |
| You are training or fine-tuning | DP chain of custody + CoP 4.4 |
A fifth set, named but not held
MAESTRO (Cloud Security Alliance) — a layered extension of STRIDE for agentic AI, characterised in the ASI source as offering “a detailed lens to identify Agentic Threats through the use of architectural layers,” covering both agentic and traditional ML/application threats. OWASP declined to adopt it on cognitive-load and scope grounds while recommending practitioners evaluate it. It is the closest thing to a secure-design method any source here names, and no primary source for it is in raw/.
Related pages
- control-catalogue — the controls themselves
- defense-in-depth — arranged by layer
- where-defenses-fail — what none of the four solves
- ATLAS mitigations
- Code of Practice Appendix 4
- ASI playbooks
- The ten risks