⭐ Star on GitHub

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

PageCovers
control-catalogueControls by control, tiered by how many frameworks independently agree
defense-in-depthThe six layers — data, weights, behaviour, application, agent, organisation
mitigation-frameworksATLAS vs CoP Appendix 4 vs ASI playbooks vs Top 10 — what each is for
where-defenses-failThe structural limits, each conceded by a source
telemetry-and-loggingThe one control every framework requires

Eight findings

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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

SituationStart with
Building anythingcontrol-catalogue Tier 1 — six controls, all multi-framework
Threat-modelling before codeMAESTRO’s seven layers, then the ASI decision path to prune
Shipping agentsASI Playbook 3, then control-catalogue Tier 3
Holding unreleased weightsCoP Appendix 4
Answering a specific techniqueATLAS
Setting expectations with leadershipwhere-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-integratedthat page overlaps CoP 4.3 output rate limiting and Tier 1 rate limiting but was written before either was cross-referenced.

6 items under this folder.