MITRE ATLAS

Definition

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a publicly available knowledge base of adversary tactics, techniques and case studies observed against AI-enabled systems, structured after MITRE ATT&CK so that AI-specific attacks can be described in the same terms as the rest of an organisation's threat intelligence.

Scope

Any organisation that builds, deploys or defends AI-enabled systems, and any security team that already speaks ATT&CK. It is a knowledge base, not a standard: nothing certifies against it, and it prescribes no controls — it describes what adversaries do so defenders can decide what to detect and prevent.

Key requirements

• Structured as tactics (the adversary's goal) and techniques (how it is achieved), deliberately mirroring MITRE ATT&CK so AI attacks slot into existing threat models rather than sitting beside them.
• It spans the whole intrusion arc — reconnaissance, access to the model, execution, persistence, defence evasion, discovery, collection, exfiltration, impact — with AI-specific stages such as staging an attack against a model.
• It is evidence-led: entries are grounded in documented incidents and red-team exercises, which is what separates it from a list of things that could theoretically go wrong.
• It complements OWASP rather than competing with it. OWASP classifies weaknesses in your design; ATLAS describes the adversary behaviour that exploits them.
• Its practical value is detection and red-teaming: a technique is a thing you can attempt against your own system and a thing you can look for in your logs.
• The matrix is maintained and extended as new attacks are documented, so it is a living reference and not a fixed checklist.

Controls

Map your agent stack onto the matrix

Walk the tactics against your own architecture and mark which techniques are reachable. Reachability, not plausibility, is what makes a technique worth defending against.

Turn reachable techniques into detections

For each one, name the signal that would show it in your telemetry. A technique with no corresponding signal is one you have decided not to notice.

Use it as the red-team backlog

Techniques are testable by construction. Run them against your own system and treat 'we could not reproduce it' as a result worth recording, not as an absence of work.

Speak ATT&CK where the organisation already does

Report AI findings in ATLAS terms so they enter the same intelligence, triage and response processes as everything else. Novel vocabulary is how AI risk ends up owned by nobody.

Read the case studies, not only the matrix

The case studies carry the operational detail — how access was obtained, what the adversary did next — which is the part that transfers to your own environment.

Feed it back into the threat model

ATLAS is the external input to an agentic threat model; the threat model is where its techniques become surfaces you own, with controls and owners attached.

Checklist

• 01Identify which ATLAS tactics are reachable in your architecture at all.
• 02For each reachable technique, record the control that bounds it and the signal that detects it.
• 03Where there is no detection, say so explicitly rather than leaving the row blank.
• 04Schedule red-team exercises drawn from the matrix, and see each attempt fail or succeed before claiming coverage.
• 05Report findings using ATLAS identifiers so they join the organisation's existing intelligence flow.
• 06Review the matrix periodically, since new techniques are documented as they are observed.
• 07Cross-reference with the OWASP LLM Top 10 so weaknesses and adversary behaviour are mapped to each other, not tracked separately.

Common pitfalls

• Treating it as a compliance checklist. Nothing certifies against ATLAS, and 'we reviewed the matrix' is not a control.
• Mapping every technique regardless of reachability, which produces a large document and no priorities.
• Keeping AI threat intelligence in a separate process from the organisation's existing one — the exact outcome ATT&CK alignment exists to prevent.
• Reading the matrix and skipping the case studies, which is where the transferable operational detail lives.
• Assuming coverage without testing. A technique you have never attempted against your own system is a technique you have an opinion about.

Examples

• A team maps its retrieval agent onto ATLAS and finds that model access is trivial (the endpoint is public), staging is cheap (any wiki editor can plant content) and exfiltration has no control (egress is unrestricted). Three techniques, one of which they were already worrying about.
• A security organisation that already runs ATT&CK-based detection engineering adds ATLAS techniques to the same backlog, so AI-specific detections are built, reviewed and on-call'd by the team that does that work.
• A red team uses the matrix as its target list for an agent assessment, and reports back in ATLAS identifiers — which lets the finding be triaged by people who have never worked on an agent.

FAQs

Is ATLAS a replacement for ATT&CK?

No, it is a companion. ATT&CK covers conventional adversary behaviour; ATLAS covers the AI-specific stages, deliberately structured the same way so an attack that starts with a phishing email and ends at a model is describable end to end.

Do I need ATLAS if I already follow the OWASP LLM Top 10?

They serve different purposes and the pairing is the point. OWASP tells you what class of weakness you have; ATLAS tells you what an adversary does with it, which is what detection and red-teaming actually need.

Where does it fit for a small team?

As a red-team backlog first. Even without a detection programme, the matrix gives a prioritised list of attacks to attempt against your own system — and attempting them is the cheapest way to find out which of your controls exist only on paper.

References

• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• OWASP — Top 10 for LLM Applications
• NIST — AI Risk Management Framework (AI RMF 1.0)

Related governance