Home/Blog/AI Security
AI Security

MITRE ATLAS Explained: Mapping Attacks on AI Systems

MITRE ATLAS (Adversarial Threat Landscape for AI Systems) is a living knowledge base of adversary tactics, techniques, mitigations and case studies focused on AI. It sits beside MITRE ATT&CK the way a specialised map sits beside a country atlas: overlapping skills, different terrain. If ATT&CK helps you reason about enterprise intrusion, ATLAS helps you reason about attacks on models, data pipelines, retrieval systems, agent tooling and AI-enabled products. UK teams reach for it when a board or buyer asks how AI-specific threats are modelled without inventing a private taxonomy.

This article positions ATLAS for UK security and product leads. It is not a second copy of the OWASP LLM Top 10, and it is not a full LLM security handbook. Use ATLAS for adversary language. Use OWASP GenAI materials for ranked application risks or governance checklists. Keep those jobs on separate pages.

The short version

  • Canonical site: atlas.mitre.org (ATLAS is maintained as its own MITRE project site).
  • ATLAS covers tactics, techniques, mitigations and case studies for AI-enabled systems, abuse of AI capabilities, and harmful autonomous behaviour materially enabled by AI.
  • Counts move as the knowledge base updates. Quote live matrix numbers from the site, not from memory.
  • ATLAS informs threat modelling and red-team design. It is not a compliance certificate.
  • Pair it with OWASP Top 10 for LLM Applications for application risk ranking and the governance checklist for leadership actions.

Context: why ATT&CK alone is not enough

Traditional security testing still matters for AI products: identity, APIs, cloud misconfiguration, vulnerable dependencies. Those map cleanly to ATT&CK and classic application testing. AI adds failure modes that look different:

  • Poisoned training or retrieval data
  • Model extraction and inversion
  • Evasion and adversarial examples
  • Prompt injection and tool abuse in LLM-backed agents
  • Supply-chain compromise of model artefacts and MLOps tooling

ATLAS exists so teams can catalogue those behaviours with the same discipline ATT&CK brought to enterprise defence. MITRE describes it as globally accessible and based on empirical observations plus realistic demonstrations from AI red teams and security groups.

Attack Vector is UK-based. Lead consulting credentials include CSTL and ChCSP.

What ATLAS contains

Expect a matrix-style knowledge base with:

  • Tactics: the adversary’s intermediate goals across the AI lifecycle (for example resource development, initial access, persistence via poisoned artefacts, impact).
  • Techniques and sub-techniques: concrete behaviours such as training-data poisoning, model theft, prompt crafting, RAG poisoning, or compromise of model distribution channels.
  • Mitigations: defensive measures mapped to techniques.
  • Case studies: documented real-world or demonstrated attacks that keep the matrix honest.

Exact tactic and technique counts change between releases. Treat any blog that freezes “14 tactics / 100 techniques” as stale the moment MITRE ships an update. Always check atlas.mitre.org for the current release notes.

ATLAS is broader than chatbots. Computer vision, classical ML, GenAI and agentic systems all appear in the threat landscape. LLM-specific application risks are also ranked separately by the OWASP GenAI Security Project; ATLAS often appears as a mapping target in those materials rather than a replacement for them.

How UK organisations should use ATLAS

1. Threat modelling workshops

Pick the AI assets that matter: models you train, models you call, RAG corpora, agent tools, evaluation pipelines. Walk relevant ATLAS tactics and ask which techniques are plausible given your trust boundaries. Write down assumptions (“the model cannot send email”) and then verify whether the implementation actually enforces them.

2. Red-team and assurance scoping

Convert chosen techniques into test objectives. Example objectives might include whether untrusted documents can steer tool calls, whether a tenant can infer another tenant’s embeddings, or whether a model artefact supply chain can be tampered with. Scope still needs rules of engagement, data-handling limits and Denial-of-Wallet ceilings.

3. Detection and control mapping

Where ATLAS lists mitigations, map them to owners: MLOps, appsec, identity, SOC. Gaps become backlog items. This is governance work, not a logo exercise.

4. Incident learning

After an AI-related incident or near miss, tag the behaviour with ATLAS technique IDs where they fit. That improves internal reporting and vendor conversations.

What ATLAS is not

  • Not a UK legal mandate
  • Not a substitute for secure SDLC, IAM hygiene or classic penetration testing of the surrounding application
  • Not automatic coverage of every OWASP LLM Top 10 item just because you opened the matrix
  • Not a promise that “we are ATLAS-aligned” means customers are safe

If you need a ranked list of LLM application risks, use the OWASP GenAI Top 10 article on this site. If you need leadership to-dos before build-out, use the governance checklist. Keep those URLs distinct so searchers land on the right job.

Mapping without testing

Printing the ATLAS logo in a slide deck without naming in-scope techniques is empty assurance. The opposite mistake is trying to “test all of ATLAS” in a two-day engagement. Technique volume is large; prioritise by asset criticality, exposure and blast radius (especially tools with write access and retrieval over sensitive corpora).

Another failure mode: testing only chat jailbreaks while ignoring identity of tool credentials, CI for model artefacts, and retrieval access control. Those are often where real damage lives.

What ATLAS is not

  • ATLAS is a knowledge base, not a certification.
  • Technique counts and names change; verify against atlas.mitre.org before citing numbers in bids.
  • Attack Vector identifies weaknesses in scoped assessments. We do not remediate your AI stack as part of the test fee.
  • Mapping to ATLAS does not guarantee regulatory compliance (UK GDPR, sector rules, upcoming AI regimes).

If you are scoping an LLM or AI-enabled application assessment, start with LLM security assessment, try the instant quote calculator, or email [email protected]. For risk taxonomy detail see the OWASP Top 10 for LLM post; for leadership actions see the LLM AI security and governance checklist.

FAQ

Is MITRE ATLAS the same as MITRE ATT&CK?

No. ATT&CK focuses primarily on adversary behaviour against enterprise IT, cloud and related domains. ATLAS focuses on adversarial behaviour involving AI systems. Many programmes use both.

Where is the official ATLAS site?

https://atlas.mitre.org/. Prefer that over secondary mirrors when quoting structure or counts.

Does ATLAS replace the OWASP Top 10 for LLMs?

No. OWASP ranks critical risks for LLM applications. ATLAS catalogues adversary tactics and techniques across AI more broadly. They complement each other; OWASP materials often map across to ATLAS.

Can we be “certified against ATLAS”?

Not in the sense of a MITRE product certificate for your company. You can adopt ATLAS for modelling, testing and reporting. That is a method choice, not a badge MITRE issues to vendors.

Should every AI project run an ATLAS-mapped red team?

Not automatically. Prioritise when models touch sensitive data, drive privileged tools, or sit on a customer trust boundary. Smaller experiments may start with threat modelling and ordinary application testing.

Will Attack Vector remediate ATLAS findings?

No. We identify and evidence weaknesses so your engineers and ML owners can prioritise fixes. Retest can be scoped when you need closure evidence.

Suggested Resources

#mitre-atlas#ai-security#threat-modelling

Ready to strengthen your security?

Talk to our consultants about your penetration testing requirements, or get a fast, transparent quote.