MITRE ATLAS gives AI attacks a shared vocabulary

When a security team says lateral movement, everyone in the room understands the same thing. That shared vocabulary — built over years around MITRE ATT&CK — is one of the quieter reasons defence has improved. Machine learning has had no equivalent, which is why AI risk conversations so often stall at whether a model can be tricked. MITRE ATLAS exists to fix that.

What the matrix covers

ATLAS maps tactics and techniques specific to AI-enabled systems: reconnaissance of a model and its training data, obtaining or reproducing a model, poisoning the data or the supply chain, evading a deployed model, and exfiltrating what the model has memorised. Each technique is backed by documented case studies rather than hypotheticals, which matters when you are trying to convince an engineering team that the risk is real.

Threat-modelling a pipeline instead of a model

The most common mistake is to threat-model the model alone. The attack surface is the pipeline: where training data comes from, who can modify it, how features are computed, where model artefacts are stored, how they are promoted to production, what the inference endpoint exposes, and what monitoring would notice a change. Most real compromises target the boring parts of that list.

• Data provenance — can you prove what your model was trained on, and would you notice a poisoned contribution?
• Artefact integrity — are model files signed and access-controlled like production binaries, or shared like documents?
• Inference exposure — does your endpoint leak enough signal for extraction or membership inference, and is it rate-limited accordingly?
• Monitoring — do you have detection for anomalous query patterns, not just accuracy metrics?

From matrix to detections

ATLAS becomes operational when techniques turn into detections. Query-pattern anomalies for extraction attempts. Integrity alerts on training data stores. Provenance failures in the model registry. Drift monitoring that distinguishes natural change from adversarial pressure. None of this is exotic engineering — it is the same discipline the SOC already applies, pointed at a system the SOC has not historically owned.

And an incident plan that has been rehearsed

If a model is found to be poisoned, who decides to roll back? To which version? How long does retraining take, and what does the product do in the meantime? These questions are answerable in advance and miserable to answer during an incident.

Ask your ML team where their training data comes from. If the answer takes more than a minute, the answer is the finding.