What MITRE ATLAS is and how to build an AI red-team plan from it

AI attackers do not stop at prompt injection. They target datasets, models, RAG, agent tools, and cloud infrastructure. This page turns the large MITRE ATLAS matrix into practical test paths and detection evidence.

Executive Summary and Mandate Overview

Target Audience: Cybersecurity teams, AI developers, machine learning engineers, and AI Red Teams
Mandatory Frequency: Pre-release adversary emulation testing and periodic reviews aligned with evolving threat intelligence
Required Scope: Data, models, RAG, prompt interfaces, model APIs, agent context, tools, MCP servers, and infrastructure
Non-Compliance Risk: Untested attack paths, prompt injection, agent-tool abuse, data exfiltration, and detection gaps

Read the 16-tactic matrix as an attack path

ATLAS is MITRE's living knowledge base. Data release 2026.09 contains 16 tactics, 120 techniques, 88 sub-techniques, 40 mitigations, and 73 case studies from incidents and realistic red-team demonstrations.

Reading MITRE ATLAS from objective to evidence: Tactic, Technique, Sub-technique, Mitigation, Case study — **Reading MITRE ATLAS from objective to evidence**
ATLAS provides shared language for threats, exercises, detections, and mitigations.
**Tactic** — The adversary objective
**Technique** — The method used to achieve that objective
**Sub-technique** — A specific variation of a technique
**Mitigation** — An approach that reduces likelihood or impact
**Case study** — Evidence from an incident or realistic demonstration

Tactics describe adversary objectives. Techniques and sub-techniques describe how those objectives are achieved, so the matrix is not a checklist that every system should test identically.
The matrix spans Predictive AI, Generative AI, Agentic AI, and Enterprise platforms, connecting model-specific weaknesses with conventional infrastructure compromise.
Maturity labels distinguish Feasible, Demonstrated, and Realized behavior, helping teams prioritize research possibilities versus attacks observed in practice.
Use ATLAS as shared language across management, engineering, the SOC, and the red team to connect threats, tests, detections, and mitigations.

High-value techniques for an AI penetration test

Select techniques from the real architecture and business impact, then build demonstrable attack paths instead of sending large prompt lists without a hypothesis.

AML.T0051 LLM Prompt Injection includes direct and indirect injection that makes a model follow unintended instructions or pass dangerous instructions to another component.
AML.T0054 LLM Jailbreak targets model restrictions, while AML.T0057 LLM Data Leakage targets disclosure. Test and measure them as distinct outcomes.
AML.T0020 Training Data Poisoning changes behavior during training or fine-tuning. AML.T0070 RAG Poisoning changes retrieved context at runtime.
AML.T0024.001 Invert AI Model reconstructs training information. AML.T0024.002 Extract AI Model approximates or copies model behavior.

Agentic AI, RAG, and MCP turn unsafe output into real action

When an agent reads email, calls APIs, writes files, or uses MCP servers, a model failure can become data modification, credential theft, or external data transfer.

AML.T0080 AI Agent Context Poisoning persistently changes decision context. AML.T0099 AI Agent Tool Data Poisoning weaponizes data returned by an otherwise benign tool.
AML.T0110 AI Agent Tool Poisoning covers altered tool definitions, implementations, and runtime responses, including MCP servers and agent skills.
AML.T0053 AI Agent Tool Invocation abuses agent privileges and can lead to AML.T0086 Exfiltration via AI Agent Tool Invocation.
AML.T0116, AML.T0118, and AML.T0124 cover autonomous reconnaissance, communication between AI agents, and autonomous orchestration of multi-stage attacks.
AML.T0129 covers instructions or triggers embedded in images, audio, video, or metadata that can alter model output or cause cross-modal prompt injection while evading defenses that do not inspect every modality.
Effective testing combines identity, permissions, approvals, sandboxing, memory, tool output, egress, and audit trails rather than inspecting only the system prompt.

Turn ATLAS into a measurable red-team plan

Start with crown jewels and trust boundaries, select techniques that can create real impact, and define test oracles, safety limits, and detection expectations before execution.

From an ATLAS path to a measurable exercise: Assets and trust boundaries → Select technique IDs → Define criteria and stop conditions → Test and collect telemetry → Record gaps and retest — **From an ATLAS path to a measurable exercise**
Technique IDs become useful when linked to success criteria, telemetry, and retesting.
**Assets and trust boundaries** — Identify crown jewels and impact paths
**Select technique IDs** — Choose methods relevant to the system
**Define criteria and stop conditions** — Set success, safety, and termination rules
**Test and collect telemetry** — Record prevention, detection, and response
**Record gaps and retest** — Capture coverage, remediation, and verification

Define each test with an ATLAS ID, preconditions, payload class, expected control, success criteria, and required evidence so results are reproducible.
Use synthetic data and canary secrets for disclosure tests, with explicit stop conditions for agents that can change external state.
Inspect AI gateway, application, model, identity, EDR, WAF, and SIEM telemetry to measure prevention, detection, triage, and response.
MITRE lists AML.M0035 AI Red Team as a mitigation recommending recurring, authorized, threat-informed exercises before deployment and throughout operation.

Show what was prevented and detected

Adding an ATLAS ID after a finding is not enough. The report should show which technique was tested, why it mattered, what impact was demonstrated, and whether defenders observed the path.

From an ATLAS scenario to evidence: Define a scenario → Select techniques → Test and observe → Record the gaps — **From an ATLAS scenario to evidence**
Separate what was blocked, what was detected, and what remained invisible. Listing a technique alone does not demonstrate that a safeguard worked.
**Define a scenario** — Select assets and trust boundaries
**Select techniques** — Build an attack path relevant to the system
**Test and observe** — Set success criteria and collect telemetry
**Record the gaps** — Capture coverage, detection gaps, and retests

A coverage matrix should connect assets, attack surfaces, ATLAS techniques, test status, controls, telemetry sources, and detection outcomes.
Separate Prevented, Detected, Partially Detected, and Undetected results so one blocked payload is not mistaken for complete technique coverage.
Record model versions, prompt templates, RAG corpora, agent tools, policies, and configurations because results can change when any component changes.
Close with remediation, detection engineering, retesting, and explicit residual-risk acceptance by the system owner.

Requirements and Testing Scope Matrix

Summary of the referenced clauses, the testing scope they cover, and the expected evaluation cycle.

Reference	Mandate Title	Scope Required	Testing Cycle
ATLAS 2026.09: AML.T0051 and AML.T0054	LLM Prompt Injection and LLM Jailbreak	Test direct injection, indirect injection, and guardrail bypass with distinct success criteria	Pre-deployment and upon prompt or API updates
AML.T0020 and AML.T0070	Training Data Poisoning and RAG Poisoning	Evaluate provenance, integrity, ingestion, fine-tuning, and retrieved context that can alter system behavior	After changes to datasets, RAG sources, or training pipelines
AML.T0024 and AML.T0057	Model Access and LLM Data Leakage	Test membership inference, model inversion, model extraction, and sensitive-data disclosure with synthetic data	Before external API exposure and after model-access policy changes
AML.T0080, AML.T0099, and AML.T0110	Agent Context and Tool Poisoning	Assess context, memory, tool data, tool definitions, runtime responses, permissions, and agent egress	Whenever new tools or external integrations are connected
AML.T0116, AML.T0118, AML.T0124, and AML.T0129	Autonomous Agent Orchestration and Multimodal Triggers	Assess autonomous reconnaissance, inter-agent communication, multi-agent tool abuse, and embedded multimodal triggers	Suggested risk-based trigger: before deploying multi-agent systems or multimodal ingestion pipelines

Compliance Readiness Self-Assessment

Select items your organization has completed to evaluate your readiness score.

Build a threat model and select ATLAS techniques from assets, platforms, crown jewels, and business impact Test AML.T0051 Prompt Injection and AML.T0054 Jailbreak with separate success criteria Evaluate training-data poisoning, RAG poisoning, model access, and LLM data leakage against the real architecture Test agent context, tool data, tool definitions, permissions, user approval, sandboxing, and egress Connect AI gateway, application, model, identity, EDR, WAF, and SIEM telemetry to each test case Produce a coverage matrix, detection result, remediation, retest, and residual risk for each technique

Frequently Asked Questions (FAQ)

Key answers and practical guidance addressing common compliance questions.

How is MITRE ATLAS different from the OWASP LLM and Agentic Top 10?

OWASP groups common risks for communication and mitigation. ATLAS models adversary behavior through tactics, techniques, sub-techniques, mitigations, and case studies, making it useful for threat modeling and adversary emulation.

Must an AI red team test every MITRE ATLAS technique?

No. Select techniques from the architecture, platform, crown jewels, threat actors, and business impact. Record scope rationale and any coverage gaps that remain untested.

Does ATLAS mapping certify that an AI system is secure?

No. ATLAS is a threat knowledge base, not a certification standard. Mapping improves traceability, but credible assurance still requires test evidence, telemetry, remediation, and retesting.