Summary: Cross-collection synthesis of every defensive control in the vault, organised by control and by layer rather than by threat. The defence-side counterpart to the four attack taxonomies.
Sources: no dedicated raw/ folder — this collection synthesises mitigation material already ingested across raw/MITRE-ATLAS/, raw/Laws/, raw/Agentic/, raw/Supply-chain-attacks/, raw/Data-poisoning/, raw/AI-incident-response/, raw/OWASP-Top-10-for-LLMs/, raw/Model-theft/. Reconciled against the three 2026-07-30 agentic sources (MAESTRO, agent observability, context failure modes).
Last updated: 2026-07-30
A synthesis collection, not a source collection
Every other collection here is paired with a raw/ folder. This one is not. It holds no new facts — every claim traces to a source already ingested elsewhere, and where a page states something, it cites the collection that carries it.
The reason it exists: the vault records four attack taxonomies and four control sets, and the control sets are each published attached to their own taxonomy. Nobody compares them. A practitioner asking “what do I actually build?” had to read six collections and reconcile them by hand.
If OWASP’s Securing Agentic Applications Guide or a NIST SSDF source is ever added to raw/, it should get its own paired collection — and this one should link to it, not absorb it.
Pages
| Page | Covers |
|---|---|
| control-catalogue | Controls by control, tiered by how many frameworks independently agree |
| defense-in-depth | The six layers — data, weights, behaviour, application, agent, organisation |
| mitigation-frameworks | ATLAS vs CoP Appendix 4 vs ASI playbooks vs Top 10 — what each is for |
| where-defenses-fail | The structural limits, each conceded by a source |
| telemetry-and-logging | The one control every framework requires |
Eight findings
- Telemetry is the only control all five frameworks independently demand — ATLAS, CoSAI, Microsoft, OWASP ASI and AI Act Art 12. Stronger agreement than anything the four attack taxonomies share. See telemetry-and-logging.
- Provenance beats detection wherever the artifact is not inspectable. CMU reaches this for training data, Google for model weights, OWASP ASI for agent memory. Three domains, three communities, one answer — and it is the closest thing the corpus has to a first principle.
- Roughly a third of defending AI systems is ordinary security engineering. ATLAS’s 35 mitigations split 16 Technical–AI / 12 Technical–Cyber / 7 Policy. Access control, segmentation and supply-chain vetting appear unchanged from any other domain.
- The defensive posture of an agent system is set by its least-guarded invocation route. MCP/A2A calls and stolen persistent agent identities both bypass the conversational path where nearly every “require approval” control lives. Under-appreciated, and it changes what you build first.
- Coverage gaps get read as coverage. 56% of ATLAS techniques have zero mapped mitigations; seven of seventeen ASI threats map to no Top 10 entry; CoP Appendix 4 is silent on the agentic surface. Absence of a control is a finding, not a pass.
- About a third of the ASI playbook controls name capabilities that do not exist. Trust scoring, truthfulness verification, cryptographic attestation of agent integrity — the last of which the source itself concedes. Sorted out in control-catalogue.
- An AI-based control inherits the threat model of what it protects. MAESTRO Layer 6 models attacks on security agents themselves — evasion, poisoning their operational data, extracting the detection model to learn the bypass, taking them over to disable other controls. This is the corpus’s only statement of it, and it discounts every control here that rests on a model checking a model. Google’s “isolate the critic from the poisoned context” answers one of the four routes.
- Detection must key on provenance, not falsity. Context poisoning is now measured occurring with no attacker, continuously, in any long-running agent — so “the context contains something false” is a signal that fires constantly and means nothing. This is a second, independent argument for finding 2, arrived at from reliability engineering rather than security.
Where to start
| Situation | Start with |
|---|---|
| Building anything | control-catalogue Tier 1 — six controls, all multi-framework |
| Threat-modelling before code | MAESTRO’s seven layers, then the ASI decision path to prune |
| Shipping agents | ASI Playbook 3, then control-catalogue Tier 3 |
| Holding unreleased weights | CoP Appendix 4 |
| Answering a specific technique | ATLAS |
| Setting expectations with leadership | where-defenses-fail |
Known gaps
- Secure design is now partly covered, and the gap has moved. MAESTRO was the named candidate for this gap; the primary source was ingested on 2026-07-30 (MAESTRO). It genuinely supplies the design-time activity that was missing — a decomposition, a per-layer threat landscape, and a six-step method to run before code exists. What it does not supply is the half that makes a threat model actionable: its step 4 references a risk matrix that appears nowhere in the document, and it maps no mitigation to any individual threat (~14 framework-level controls for ~60 threats). So the vault now holds a way to enumerate design-time threats and still nothing that prioritises them or says what to build for each. See the framework assessment for why STRIDE, PASTA, LINDDUN, OCTAVE, Trike and VAST were each judged insufficient — and note that PASTA and OCTAVE, which MAESTRO critiques, are strongest at exactly the prioritisation it omits.
- NIST SSDF (SP 800-218) and the CoSAI framework PDF remain the most-cited absent sources across the vault, both defensive.
- No cost or effort data. Nothing here says what any control costs to run, which is the first question anyone implementing will ask.
- Model-theft defences are under-integrated — that page overlaps
CoP4.3 output rate limiting and Tier 1 rate limiting but was written before either was cross-referenced.
Related collections
- MITRE ATLAS — the only technique-level control catalogue
- Agentic Security — the only control set for systems that act
- Laws — CoP Appendix 4, the most prescriptive set
- Supply Chain Attacks — provenance, and defences for code that calls models
- Data Poisoning — chain of custody, ensemble monitoring
- AI Incident Response — what to do when the controls fail