Summary: 35 mitigations mapped to specific techniques with per-pairing applicability text — the technique-level defensive material the rest of this vault lacks. Also: 97 of 173 techniques have no mitigation at all.
Sources: raw/MITRE-ATLAS/AML.M00*.md (35 cards, release 2026.06)
Last updated: 2026-07-28
Before this ingest, the vault had no mitigation source at technique granularity — the closest was Code of Practice Appendix 4, which is organisational and infrastructural. ATLAS closes that gap for 76 techniques and, just as usefully, shows exactly where no answer exists.
The 35, by category
| Category | Count |
|---|---|
| Technical – AI | 16 |
| Technical – Cyber | 12 |
| Policy | 7 |
The near-even split between AI-specific and conventional-cyber controls is the practical message: roughly a third of defending AI systems is ordinary security engineering. Access control, network segmentation and supply-chain vetting appear here unchanged from any other domain.
By AI lifecycle phase
| Phase | Mitigations |
|---|---|
| Deployment | 24 |
| AI Model Engineering | 15 |
| Data Preparation | 13 |
| Business and Data Understanding | 12 |
| Monitoring and Maintenance | 11 |
| AI Model Evaluation | 10 |
Counts exceed 35 because mitigations span phases. Deployment dominates — most of what you can do, you do at deployment time, not during training.
What a mitigation card carries
Each mitigates relationship has its own applicability text, so the same mitigation reads differently per technique. Taking AML.T0051 LLM Prompt Injection, which has six:
- Control Access to AI Models and Data in Production — “Use access controls in production to prevent adversaries from injecting malicious prompts.”
- Generative AI Guardrails — “Guardrails can prevent harmful inputs that can lead to prompt injection.”
- Generative AI Guidelines — “Model guidelines can instruct the model to refuse a response to unsafe inputs.”
- Generative AI Model Alignment — “Model alignment can improve the parametric safety of a model by guiding it away from unsafe prompts and responses.”
- AI Telemetry Logging — “Telemetry logging can help identify if unsafe prompts have been submitted to the LLM.”
- Input and Output Validation for AI Agent Components — “Validation can prevent adversaries from executing prompt injections that could affect agentic workflows.”
(source: raw/MITRE-ATLAS/AML.T0051-llm-prompt-injection.md)
That is the per-technique defensive detail this vault previously had nowhere.
The coverage gap — read this before trusting the matrix
97 of 173 techniques (56%) have zero mapped mitigations.
ATLAS is far more complete as a threat taxonomy than as a control catalogue. Using it as a coverage checklist will produce a badly false picture of your posture: an unmitigated technique is not a technique you have handled, it is one where MITRE has no published answer.
Best-covered techniques, by mitigation count:
| Technique | Mitigations |
|---|---|
| AI Agent Tool Invocation | 11 |
| Craft Adversarial Data | 8 |
| Exfiltration via AI Agent Tool Invocation | 8 |
| Black-Box Optimization | 7 |
Two of the top three are agentic. Defensive attention is concentrated where the platform tagging says the surface is largest.
AI Telemetry Logging — the load-bearing one
AML.M0024 recurs across detection-oriented mappings, and it is the ATLAS control that connects directly to the vault’s regulatory and IR material:
- AI Act Art 12 mandates automatic event logging over the system’s lifetime.
- CoSAI’s preparation phase requires capturing “prompt logs, model inference activity, tool executions, and memory state changes” (source:
raw/AI-incident-response/Defending AI Systems...md). - Microsoft identifies telemetry gaps as one of four properties that break traditional IR for AI, and flags the privacy tension explicitly (source:
raw/AI-incident-response/Incident response for AI systems.md).
Four independent sources converge on logging as the precondition for everything else. See Microsoft IR readiness.
Where ATLAS and the Code of Practice differ
They are close to complementary:
| ATLAS mitigations | CoP Appendix 4 | |
|---|---|---|
| Granularity | Per technique | Per control family |
| Defends | The deployed system | Unreleased model weights |
| Binding | No | Voluntary, for GPAI systemic-risk providers |
| Agentic coverage | Substantial | Almost none |
| Weight protection | Thin | 256-bit encryption, attested TEEs, copy registries |
Using both gets you technique-level coverage for the deployed system and a hardening baseline for the weights. Neither alone is sufficient.