🗺️ MITRE ATLAS for LLM Applications: Tactics, Techniques, and AI-Agent Defense
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a public, continuously updated knowledge base of the tactics, techniques, and real-world case studies of attacks on artificial-intelligence and machine-learning systems. If the OWASP Top 10 for LLMs answers the question "what breaks," then ATLAS answers "how exactly attackers operate" — in terms inherited from MITRE ATT&CK: the chain "tactic → technique → sub-technique → case study." This guide walks through the structure of the ATLAS matrix, the key techniques for LLM and agentic applications with precise AML.Txxxx identifiers, and shows which engines of SYNTREX — the defense layer of the Spectorn platform — close off each vector at the runtime level.
Spectorn is a security and compliance-perimeter platform; SYNTREX is its AI-defense layer (a set of detection-and-blocking engines), which also deploys standalone on customers' internal perimeters. ATLAS gives the language of threats; SYNTREX gives detection and an immutable audit of those threats in production.
What MITRE ATLAS Is and How It Differs from ATT&CK
ATLAS is created and maintained by the MITRE Corporation — the same one that runs ATT&CK, the industry standard for describing attacks on traditional IT infrastructure. ATLAS is built on the same model with the same naming system, but its focus is different: the attack surfaces specific to AI — training data, inference APIs, LLM prompts, model theft, agent tool chains.
The ATLAS matrix is a set of tactics (why the attacker takes a step: the columns of the matrix) and the techniques nested within them (how exactly they do it: the cells). Most tactics are inherited from ATT&CK and adapted to the AI context (Reconnaissance, Initial Access, Execution, Exfiltration, Impact, and others), but some are AI-exclusive — for example, AI Model Access (AML.TA0000) and AI Attack Staging (AML.TA0001, formerly "ML Attack Staging"). In the late-2025 editions the matrix added the Lateral Movement (AML.TA0015) and Command and Control (AML.TA0014) tactics, and in 2025–2026 a large group of techniques specific to autonomous AI agents was folded in.
An important detail for anyone cross-checking against the matrix: tactic identifiers are not sequential.
AML.TA0002is Reconnaissance, whileAML.TA0001is AI Attack Staging, not the other way around. Always check the ID against the current version at atlas.mitre.org, because the numbering and the set of techniques have changed from version to version.
Three layers: ATLAS, OWASP, and NIST AI RMF
ATLAS does not compete with other frameworks but complements them in a three-layer model:
- Strategic layer — NIST AI RMF: how an organization manages risk (the GOVERN / MAP / MEASURE / MANAGE functions).
- Tactical layer — MITRE ATLAS: how an adversary actually runs an attack (the TTP matrix, case studies, mitigations).
- Operational layer — OWASP Top 10 for LLMs: which concrete vulnerabilities to fix in application code.
The connection is simple: OWASP names the vulnerability, ATLAS describes the technique that exploits it, NIST sets the management loop. SYNTREX's detection map below draws on all three.
ATLAS Tactics for LLM Applications
Not all 16 tactics are equally relevant to a typical LLM application. For systems built on large language models and AI agents, the key ones are:
| Tactic (ID) | What it means in the LLM context |
|---|---|
Initial Access (AML.TA0004) | Gaining first access: exploiting a public endpoint, compromising the AI supply chain |
AI Model Access (AML.TA0000) | Access to the model itself — from black-box via API to full white-box |
Execution (AML.TA0005) | Launching malicious behavior: prompt injection, agent tool invocation, jailbreak |
Persistence (AML.TA0006) | Establishing a foothold: modifying agent configuration, a backdoor in a fine-tuned model |
Defense Evasion (AML.TA0007) | Bypassing defenses: prompt obfuscation, forging trusted output components |
Discovery (AML.TA0008) | Reconnaissance: extracting LLM system information, probing for hallucinations, agent configuration |
Collection / Exfiltration (AML.TA0009 / AML.TA0010) | Collecting and exfiltrating data: leakage via the inference API, via agent tools |
Impact (AML.TA0011) | Impact: denial of AI service, erosion of model integrity, external harm |
Key ATLAS Techniques and SYNTREX Defense
Below are the techniques most significant for LLM applications, with precise identifiers and the SYNTREX engines that close them off at the runtime level.
AML.T0051 — LLM Prompt Injection (Execution)
The basic and most common technique: the attacker crafts a prompt that makes the model ignore its original instructions and follow the attacker's own. Two sub-techniques:
AML.T0051.000— Direct Prompt Injection: malicious input is supplied directly through the UI or API.AML.T0051.001— Indirect Prompt Injection: the instruction is hidden in external data the model processes — a document, web page, email, tool output, including multimedia.
Maps to: OWASP LLM01:2025 Prompt Injection.
SYNTREX defense: the injection, output_scanner, lethal_trifecta, goal_predictability engines. injection inspects both user input (direct) and untrusted external content — tool output, document and page content (indirect) — for embedded instructions and attempts to override the system directives. A detailed walkthrough is in the Prompt Injection guide, and the multimodal variant (.001 via images/documents/audio) is in the multimodal injection guide.
AML.T0054 — LLM Jailbreak (Execution)
Moving the model into a state in which its safety training is bypassed — usually through a carefully constructed prompt. ATLAS separates jailbreak (bypassing the model's own policies) from prompt injection (overriding the application's instructions), although in practice the two are often combined.
Maps to: OWASP LLM01:2025 (jailbreak as a special case of injection).
SYNTREX defense: the jailbreak engine recognizes known bypass families (DAN, Skeleton Key, Policy Puppetry, many-shot, Crescendo). A detailed walkthrough is in the jailbreaks guide.
AML.T0056 — Extract LLM System Prompt and AML.T0057 — LLM Data Leakage (Exfiltration)
AML.T0056 — extracting the hidden system prompt (internal rules, business logic, sometimes secrets mistakenly placed there). AML.T0057 — crafting requests that provoke unintended leakage of data from the context or the training set.
Maps to: OWASP LLM07:2025 System Prompt Leakage, LLM02:2025 Sensitive Information Disclosure.
SYNTREX defense: the output_scanner, injection, pii, secret_scanner engines. output_scanner intercepts responses containing fragments of the system instructions; secret_scanner (an undisableable platform-level invariant) masks keys and tokens before they leave the perimeter; pii masks personal data in the output.
AML.T0024 — Exfiltration via AI Inference API (Exfiltration)
Exfiltrating data through the inference API itself: membership inference of training data (.000), model inversion (.001), model extraction/theft (.002).
Maps to: OWASP LLM02:2025 Sensitive Information Disclosure.
SYNTREX defense: exfiltration recognizes anomalous data offloading, provenance_reduction tracks attempts to reduce the traceability of the data source, and intent_revelation helps surface reconnaissance intent within a sequence of requests.
AML.T0086 — Exfiltration via AI Agent Tool Invocation (Exfiltration)
Using write/send-capable tools available to the agent to exfiltrate data. This technique describes most of the real zero-click incidents of 2025 (for example, EchoLeak in Microsoft 365 Copilot, CVE-2025-32711): an indirect injection via email makes the agent output the context through a trusted channel.
Maps to: OWASP LLM06:2025 Excessive Agency.
SYNTREX defense: tool_abuse, cross_tool_guard, lethal_trifecta, exfiltration. lethal_trifecta recognizes the "lethal trifecta" (data access + untrusted input + output channel) in a single agent action; cross_tool_guard controls dangerous cross-tool chains; tool_abuse catches abuse of a tool's privileges.
AML.T0020 — Poison Training Data and AML.T0018 — Backdoor ML Model (AI Attack Staging)
Poisoning of training data (AML.T0020) and embedding a backdoor in the model (AML.T0018, with sub-techniques .000 Poison ML Model and .001 Inject Payload) — attacks on the training stage that activate on a trigger at runtime.
Maps to: OWASP LLM04:2025 Data and Model Poisoning.
SYNTREX defense: SYNTREX has no direct "training-data scanner" — that is the MLOps and supply-chain zone. On the runtime side, dormant_payload, which surfaces dormant payloads that activate on a trigger, partially helps. The full walkthrough and the honest boundary of responsibility are in the data and model poisoning guide.
AML.T0010 — AI Supply Chain Compromise (Initial Access)
Compromise through third-party components: hardware (.000), ML software (.001), data (.002), model (.003). The classic example is malicious models on Hugging Face (ATLAS case AML.CS0031), where a reverse shell was embedded in pickle files.
Maps to: OWASP LLM03:2025 Supply Chain.
SYNTREX defense: verifying signatures, hashes, and provenance of artifacts before installation is a task for DevSecOps processes (SBOM / ML-BOM). At runtime, dormant_payload and inline output_scanner content inspection limit the "blast radius" of a compromised component. An honest boundary: supply-chain management is predominantly an organizational control.
AML.T0070 — RAG Poisoning and AML.T0066 — Retrieval Content Crafting (AI Attack Staging)
Techniques added in the RAG era: injecting malicious content into RAG sources (AML.T0070) and crafting content so that it is indexed and later retrieved by the system (AML.T0066). Also here: AML.T0061 LLM Prompt Self-Replication (the Morris II worm pattern in multi-agent RAG pipelines).
Maps to: OWASP LLM04:2025 and LLM08:2025 Vector and Embedding Weaknesses.
SYNTREX defense: injection inspects content retrieved from RAG for hidden instructions; dormant_payload surfaces dormant payloads in the corpus. More in the RAG security guide.
How SYNTREX Helps: ATLAS → Engine Map
SYNTREX is a pipeline of specialized detection engines, inline output-content inspection (Shield / output_scanner), event correlation (SOC), and an immutable audit (Decision Logger). A summary "ATLAS technique → engine" map:
| ATLAS technique | Primary SYNTREX engines |
|---|---|
AML.T0051 LLM Prompt Injection (.000/.001) | injection, output_scanner, goal_predictability |
AML.T0054 LLM Jailbreak | jailbreak |
AML.T0056 Extract LLM System Prompt | output_scanner, injection |
AML.T0057 LLM Data Leakage | pii, secret_scanner, exfiltration |
AML.T0024 Exfiltration via Inference API | exfiltration, provenance_reduction, intent_revelation |
AML.T0086 Exfiltration via Agent Tool | tool_abuse, cross_tool_guard, lethal_trifecta |
AML.T0020 / AML.T0018 Poison / Backdoor | dormant_payload (+ MLOps/SBOM processes) |
AML.T0010 AI Supply Chain Compromise | dormant_payload, output_scanner (+ SBOM/ML-BOM) |
AML.T0070 / AML.T0066 RAG Poisoning | injection, dormant_payload |
syntrex.yaml configuration
A profile oriented toward covering the key ATLAS techniques for the LLM and agentic perimeter:
# syntrex.yaml — MITRE ATLAS coverage profile
version: "1.0"
mode: ai_gateway
engines:
injection: # AML.T0051 (.000 direct + .001 indirect)
action: block
inspect_tool_output: true
confidence_threshold: 0.7
jailbreak: # AML.T0054
action: block
confidence_threshold: 0.85
output_scanner: # AML.T0056, AML.T0057
action: sanitize
pii: # AML.T0057
action: redact
mask_character: "*"
secret_scanner: always_on # AML.T0057 — an undisableable invariant
exfiltration: # AML.T0024, AML.T0086
action: block
confidence_threshold: 0.90
lethal_trifecta: # AML.T0086 — data + untrusted + egress
action: block
tool_abuse: # AML.T0086
action: block
cross_tool_guard: # AML.T0086 — cross-tool chains
action: block
goal_predictability: # deviation from a locally predictable goal
action: block
dormant_payload: # AML.T0018, AML.T0020, AML.T0070
action: alert
provenance_reduction: # AML.T0024
action: alert
shield:
dmz: true # inline response-content inspection (AML.T0010, AML.T0086)
audit:
decision_logger: true # immutable SHA-256/HMAC chain
SOC correlation rule
A multi-stage attack is almost always visible as a chain of ATLAS events. Example: injection (Execution) → an attempt to exfiltrate via an agent tool (Exfiltration):
rules:
- id: ATLAS_INJECTION_TO_EXFIL
name: "AML.T0051 → AML.T0086"
description: "Indirect prompt injection followed by an attempt to exfiltrate via an agent tool"
enabled: true
conditions:
- sequence:
- category: injection
min_confidence: 0.7
- category: lethal_trifecta
min_confidence: 0.7
within: "3m"
same_field: "session_id"
action:
create_incident: true
severity: CRITICAL
kill_chain_stage: "exfiltration"
playbook: "auto_block_session"
metadata:
mitre_atlas: ["AML.T0051.001", "AML.T0086"]
owasp_llm: ["LLM01", "LLM06"]
Every engine decision is written to the Decision Logger — an immutable chain with SHA-256 and HMAC hashes, suitable for incident review and for presenting to a regulator: it shows which ATLAS technique fired and in what sequence.
An honest boundary: SYNTREX closes the ATLAS techniques that manifest at the level of input/output and agent behavior at runtime (Execution, Exfiltration, part of Defense Evasion and Discovery). Training-stage techniques (
AML.T0020,AML.T0018) and supply-chain compromise (AML.T0010) require predominantly organizational and MLOps measures — SYNTREX complements them with runtime detection and audit but does not stand in for them.
Frequently Asked Questions (FAQ)
What is MITRE ATLAS in plain terms? It is MITRE's knowledge base of how AI systems are attacked: a matrix of tactics (why) and techniques (how), with real case studies and mitigations. ATLAS is built on the model of MITRE ATT&CK but is dedicated to threats specific to machine learning and LLMs — data poisoning, prompt injection, model theft, abuse of agent tools.
How does MITRE ATLAS differ from the OWASP Top 10 for LLMs? OWASP is a list of vulnerabilities from the developer's point of view ("what breaks"), while ATLAS is a matrix of tactics and techniques from the attacker's point of view ("how exactly an attack is run"). They are used together: OWASP helps build defense requirements, ATLAS provides the threat model for red teams and detection/response. SYNTREX maps its engines to both systems.
What is the identifier for prompt injection in ATLAS?
AML.T0051 (LLM Prompt Injection), with two sub-techniques: AML.T0051.000 — direct injection (via the UI/API), AML.T0051.001 — indirect (via external data, documents, web pages, multimedia). Be careful: some outdated sources confuse the sub-technique numbering — check against atlas.mitre.org.
Does SYNTREX close every ATLAS technique?
No, and we note this honestly. SYNTREX uses engines to close the techniques that manifest at runtime at the level of input/output and agent behavior: injection (AML.T0051), jailbreak (AML.T0054), leakage (AML.T0056, AML.T0057), exfiltration (AML.T0024, AML.T0086). Training-stage and supply-chain-compromise techniques require MLOps and organizational measures; SYNTREX complements them with detection of dormant payloads (dormant_payload) and an immutable audit.
How is ATLAS connected to NIST AI RMF? ATLAS is the tactical threat layer that gives substance to the NIST AI RMF functions: ATLAS data feeds MAP (risk identification), MEASURE (testing and detection), and MANAGE (mitigations). NIST sets the management framework, ATLAS provides the vocabulary of concrete attacks. More on NIST is in our AI RMF guide.
What is the AI Attack Staging tactic in ATLAS?
It is an AI-exclusive tactic (AML.TA0001, formerly "ML Attack Staging") — the stage of preparing an attack on the model: crafting adversarial data (AML.T0043), poisoning training data (AML.T0020), building a proxy model, preparing RAG content (AML.T0066). It is the "staging" before the exploitation proper.
Where do I get the official ATLAS matrix and navigator?
The matrix is available at atlas.mitre.org, the machine-readable data is in the mitre-atlas/atlas-data repository (the ATLAS.yaml file), and the case studies are at atlas.mitre.org/studies. The set of techniques is expanded regularly, so it's worth pinning the version when citing.
Sources
- MITRE ATLAS — official site and matrix — tactics, techniques, sub-techniques, case studies, mitigations.
- MITRE ATLAS — Case Studies — a library of real incidents (for example,
AML.CS0031Malicious Models on Hugging Face). - MITRE ATLAS — data repository (GitHub) — the machine-readable
ATLAS.yamlwith current tactic and technique IDs. - OWASP Top 10 for LLM Applications (2025) — the operational vulnerability layer, mapped onto ATLAS techniques.
- NIST AI Risk Management Framework (AI 100-1) — the strategic management layer.
- MITRE ATT&CK — the parent framework on which ATLAS is modeled.
Related guides: OWASP Top 10 for LLMs · NIST AI RMF · EU AI Act · Prompt Injection · Multimodal Injection · Data and Model Poisoning · Industry Scenarios