# Deep-Dive SDD-B12 — MITRE ATLAS: The Adversary's Playbook for AI Systems

**Course**: Course 2B — Securing & Attacking Harnesses and LLMs · **Module**: SDD-B12 · **Duration**: 45 min · **Level**: Senior engineer+ · **Status**: Complete
**Pillar**: Deep-Dives
**Prerequisites**: B1 (Threat Model), B9 (OWASP ASI Checklist), B10 (Microsoft Failure Taxonomy), SDD-B01 (OWASP Offensive Expansion), SDD-B11 (Tau Harness)

> ATLAS gives you the adversary's playbook. C2B B9 gives you the builder's checklist. SDD-B01 gives you the offensive expansion. ATLAS is the connective tissue — the framework that names every technique an adversary has actually used against an AI system, in the order an adversary actually chains them, from reconnaissance through impact.

## Learning objectives

1. Explain what MITRE ATLAS is, how it is structured (tactics × techniques × case studies, the ATT&CK analog), and why it is the connective tissue between OWASP ASI (B9), the Microsoft failure taxonomy (B10), and the offensive expansion (SDD-B01).
2. Read the ATLAS matrix end-to-end: all twelve tactics (AML.TA0001–AML.TA0012), the techniques beneath each, and the case studies that evidence them — and map each to an agentic-harness attack surface from B1.
3. For the six load-bearing ATLAS techniques (prompt injection, model inversion, data poisoning, adversarial examples, model stealing, membership inference), state the full attack procedure, the real-world case study that evidences it, and the OWASP ASI / Microsoft taxonomy cross-reference.
4. Use ATLAS to plan a red-team engagement: pick a target, walk the matrix left-to-right, select techniques by maturity and platform applicability, and produce a technique-by-technique attack plan a B12 assessor would accept.
5. Map ATLAS techniques against a zero-defense harness (the Tau harness from SDD-B11) and identify which techniques apply — the lab exercise that anchors the deep-dive.

---

## The thesis

OWASP ASI (B9) is a builder's checklist — ten risks, one control each, scored. The Microsoft failure taxonomy (B10) is a defender's diagnostic — twelve failure modes organized by where in the system the failure originates. SDD-B01 is the offensive expansion — the same ten OWASP rows read as attack procedures with the evasion that defeats each control.

**None of them is the adversary's full playbook.** A real adversary does not think in ten rows or twelve failure modes. An adversary thinks in a kill chain: reconnaissance, then initial access, then staging, then impact — and at every stage, they have a library of techniques to choose from, each one observed in the wild against a real AI system, each one with a documented case study.

**MITRE ATLAS (Adversarial Threat Landscape for AI Systems) is that playbook.** It is the ATT&CK equivalent for AI/ML: a living knowledge base of adversary tactics and techniques against AI-enabled systems, structured exactly like ATT&CK (a matrix of tactics × techniques, each technique with sub-techniques, case studies, and mitigations), maintained by MITRE, fed by real-world incident reports and published research. As of the v5.x stream (the 2025–2026 cadence), ATLAS catalogs twelve tactics and roughly eighty-plus techniques, backed by dozens of case studies drawn from published attacks on production AI systems.

The curriculum's load-bearing framing: **ATLAS gives you the adversary's playbook. C2B B9 gives you the builder's checklist. SDD-B01 gives you the offensive expansion. ATLAS is the connective tissue** — the framework that lets a red-team lead walk into an engagement with a target agentic system and answer, technique by technique, "has anyone ever done this to an AI system before, and how did it work?"

This deep-dive reads ATLAS the way SDD-B01 reads OWASP — as an operator. The three sub-sections cover (SDD-B12.1) the matrix structure and all twelve tactics with their load-bearing techniques, (SDD-B12.2) the six load-bearing techniques in depth with case studies and OWASP/Microsoft cross-references, and (SDD-B12.3) how to use ATLAS to plan an engagement and map it against a zero-defense target.

---

## SDD-B12.1 — The Matrix: Twelve Tactics, the ATT&CK Analog

### How ATLAS is structured

ATLAS mirrors ATT&CK precisely, which is the point — an analyst who can read ATT&CK can read ATLAS, and the two are designed to be composed. The structure:

- **Tactics (AML.TA0001–AML.TA0012)**: the adversary's objectives, ordered left-to-right as a kill chain. Each tactic answers "why is the adversary doing this?" Reconnaissance, Initial Access, ML Model Access, Execution, Persistence, Defense Evasion, Discovery, Collection, ML Attack Staging, Exfiltration, Impact. Tactics are columns in the matrix.
- **Techniques (AML.Txxxx)**: how the adversary achieves the objective. Each technique sits under one or more tactics. Techniques have IDs (AML.T0048 for Prompt Injection, AML.T0010 for ML Model Access via Public APIs), descriptions, procedure examples, and mitigations. Techniques are cells in the matrix.
- **Sub-techniques**: finer-grained procedures beneath a technique. Prompt Injection has sub-techniques for direct vs. indirect injection, mirroring the SDD-B01 distinction.
- **Case studies**: real-world attacks cataloged against the techniques they used. A case study might be "Researcher X demonstrated model extraction against Vendor Y's commercial API using technique AML.T0024." Case studies are the evidence layer — they are why a technique is in the matrix and not on a wishlist.
- **Mitigations (AML.Mxxxx)**: defensive controls mapped to the techniques they address. ATLAS mitigations are deliberately framework-agnostic — they name the control class (input validation, output filtering, adversarial training), not the product.
- **Technique Maturity filter** (added in the Secure AI v2 release, May 2026): each technique is tagged by how mature the attack is in the wild — from theoretical (published in a paper, never observed) to weaponized (available as a tool, used against production systems). This is the red-team planner's first filter: a technique with high maturity is one your adversary may already be running.

The ATLAS/ATT&CK composition matters for agent systems specifically. An attack on an agentic harness is almost always a *compound* of a traditional ATT&CK technique (initial access via phishing the developer, persistence via a malicious dependency) and an ATLAS technique (prompt injection to weaponize the access, model inversion to extract training data). The frameworks are designed to be read together: ATT&CK gets the adversary onto the host; ATLAS weaponizes the AI layer once they are there. This is exactly the ASI08→ASI05→ASI10 chain from SDD-B01 — ATT&CK supply-chain compromise enabling ATLAS-grade AI exploitation.

### The twelve tactics, in kill-chain order

ATLAS tactics are not abstract — each one names a phase a real adversary passed through in a documented case study. Walk the matrix left to right:

**1. Reconnaissance (AML.TA0001).** The adversary gathers information about the target AI system — its existence, its model family, its training data sources, its API surface, its developers. Techniques include searching for public model artifacts (AML.T0019 Publish ML Model reveals what an adversary can find), scanning for ML-enabled services (AML.T0013 Discover ML Model Family), and gathering publicly available training data (AML.T0016 Obtain Public Training Data). The OWASP analogue is ASI02 (Prompt Leakage); the difference is that reconnaissance is passive and pre-engagement, while ASI02 is an active runtime disclosure. **Load-bearing point**: reconnaissance is where ATLAS case studies begin — the attacker cannot plan an ML-specific technique without first confirming the target has an ML component and identifying its model family. For agentic harnesses, the reconnaissance surface includes the agent's public documentation, the MCP servers it advertises, and the model providers it integrates.

**2. Initial Access (AML.TA0003).** The adversary gains a foothold. For AI systems this splits into two branches: traditional access (phishing, exploit, credential theft — pure ATT&CK) and ML-specific access (AML.T0017 ML Supply Chain Compromise, where a poisoned model or dependency is the entry vector; AML.T0040 ML Model Access via public APIs). The SDD-B01 ASI08 row maps here: a signed-but-malicious MCP server is an ATLAS Initial Access technique, not a runtime defense failure. **Load-bearing point**: Initial Access is where ATT&CK and ATLAS overlap most visibly. A traditional compromise (developer laptop, CI/CD pipeline) plus an ML-aware objective (poison the checkpoint before it ships) is the canonical agentic-harness supply-chain attack.

**3. ML Model Access (AML.TA0004).** The adversary obtains access to the model itself — either the weights, the inference API, or a local copy. This is the tactic that has no ATT&CK analogue; it exists because AI systems have an asset class (the trained model) that traditional systems do not. Techniques include AML.T0010 (access via public APIs like an LLM chat endpoint), AML.T0020 (access to full model via supply chain or insider), and AML.T0043 (access to model internals via white-box access on an open-weights release). **Load-bearing point**: the access tier determines which downstream techniques are available. Black-box API access limits the adversary to prompt injection, model stealing, and membership inference. White-box weight access unlocks adversarial-example crafting at scale, representation-level attacks (B13), and weight-poisoning persistence. The access tier is the first variable an ATLAS-aware red team establishes.

**4. Execution (AML.TA0005).** The adversary runs adversarial code or inputs against the model. For agentic systems this is where prompt injection lives — AML.T0048 Prompt Injection is an Execution technique because the adversary is *executing* an adversarial input through the model's instruction-processing pipeline. Sub-techniques distinguish direct injection (the payload arrives in the user turn) from indirect injection (the payload arrives via a tool output or retrieved document — the SDD-B01 load-bearing evasion). **Load-bearing point**: Execution in ATLAS is broader than code execution. An adversarial prompt is an execution technique because it causes the model to run an attacker-chosen computation (the attacker's instructions) on the victim's compute.

**5. Persistence (AML.TA0006).** The adversary maintains access across sessions, model reloads, or defensive resets. ATLAS persistence techniques include AML.T0034 (Poison Training Data — a backdoor that survives retraining), AML.T0032 (Backdoor ML Model — weights modified to trigger on a secret input), and AML.T0046 (Implant Backdoor via Supply Chain). This is where weight poisoning (the B13 deep-dive) and the memory-poisoning-with-durable-writes pattern from SDD-B01 ASI04 converge. **Load-bearing point**: persistence is the tactic that turns a one-time injection into a durable compromise. A prompt-injection finding is a one-turn problem; a poisoned-checkpoint finding is a model-lifecycle problem. The mitigation effort is an order of magnitude apart, which is why ATLAS separates them.

**6. Defense Evasion (AML.TA0007).** The adversary evades the target's defensive controls — guardrails, input filters, injection detectors, output sanitizers. Techniques include AML.T0050 (Evade ML Model — crafting inputs that pass the detector but still execute the payload), AML.T0015 (Evade ML Analyzer — the SDD-B01 indirect-channel pattern, where the input arrives on a channel the analyzer does not inspect). **Load-bearing point**: this tactic is the empirical home of the SDD-B01 thesis — "every defense has a known evasion, and the evasion is almost always the indirect channel." ATLAS Defense Evasion is where that thesis is cataloged technique-by-technique.

**7. Discovery (AML.TA0008).** The adversary explores the AI system's internal layout — what tools are available, what the system prompt contains, what other agents exist, where the credentials live. Techniques include AML.T0014 (Discover ML Model Ontology — probing the model's capabilities and training-data boundaries), and the runtime analogue of ASI02 capability enumeration. **Load-bearing point**: Discovery is the bridge between Initial Access and Impact. An adversary with a foothold but no map cannot plan a chain; Discovery builds the map. For agentic systems, Discovery is where the attacker learns the tool list, the orchestrator's trust boundaries, and the inter-agent message contracts — the inputs to every ASI05/ASI10 escalation.

**8. Collection (AML.TA0009).** The adversary gathers data of interest — training data, model outputs, user prompts, credentials, tool results. Techniques include AML.T0025 (Extract ML Model — the model-stealing technique), AML.T0022 (Collect Toolkit Information — harvesting the agent's tool schemas and permissions). **Load-bearing point**: Collection overlaps with Exfiltration, but ATLAS separates them because Collection is *gathering* (often internal, often undetected) while Exfiltration is *removal* (crossing a trust boundary the defender monitors). The SDD-B01 ASI02 multi-turn rapport is a Collection technique; the ASI07 output-as-input chain that carries the data out is the Exfiltration technique.

**9. ML Attack Staging (AML.TA0010).** The adversary prepares the attack — crafting adversarial examples, training a surrogate model for a model-stealing attack, building the payload for a prompt-injection campaign. Techniques include AML.T0018 (Craft Adversarial Data — generating inputs that trigger misclassification or instruction-following), AML.T0024 (Train Surrogate Model — the staging step for a black-box extraction attack). **Load-bearing point**: this is the tactic that has no ATT&CK analogue and no runtime defense. You cannot detect staging that happens on the adversary's laptop. The mitigation is upstream — restrict ML Model Access (Tactic 3) so the adversary cannot query enough to stage an attack — not runtime detection.

**10. Exfiltration (AML.TA0011).** The adversary removes data from the target — model weights, training data, user data, system prompts. Techniques include AML.T0025 (Exfiltrate ML Model — the act of removing the weights, distinct from extracting them via queries), AML.T0026 (Exfiltrate Training Data — the model-inversion attack). **Load-bearing point**: the SDD-B01 exfiltration chain (ASI07→01→05→03) terminates in an ATLAS Exfiltration technique. The OWASP row names the control; ATLAS names the adversary objective it serves.

**11. Impact (AML.TA0012).** The adversary degrades, manipulates, or destroys the AI system. Techniques include AML.T0028 (Denial of ML Service — resource exhaustion, the ASI09 analogue), AML.T0031 (Manipulate ML Model Outputs — the goal-hijack outcome, the ASI01 analogue), AML.T0036 (Cost Hijacking — the bill-amplification variant of ASI09 specific to metered LLM APIs). **Load-bearing point**: Impact is where the adversary's objective becomes visible. Every prior tactic is in service of an Impact technique; mapping Impact first (what is the adversary trying to achieve?) and walking backward is a valid planning approach.

**12. Resource Development (AML.TA0002).** The adversary builds the capabilities for the attack — acquiring compute for surrogate-model training, developing adversarial-example tooling, compromising a supply-chain node. This tactic sits outside the kill-chain ordering because it happens in parallel, before and during the attack. Techniques include AML.T0027 (Acquire Compute), AML.T0029 (Acquire Software / Tools — including off-the-shelf jailbreak toolkits). **Load-bearing point**: Resource Development is the tactic that makes ATLAS case studies reproducible. A published attack becomes an ATLAS case study; the tooling from that attack becomes available as a Resource Development technique; the next adversary uses it. This is why Technique Maturity trends upward over time.

---

## SDD-B12.2 — Six Load-Bearing Techniques in Depth

Twelve tactics is the structure; the techniques are the substance. Of the eighty-plus, six recur in nearly every agentic-harness engagement and deserve the offensive-expansion treatment. Each gets the procedure, the case study, the OWASP/Microsoft cross-reference, and the evasion that defeats the standard defense.

### Prompt Injection (AML.T0048) — the Execution + Impact technique

The procedure is SDD-B01's: direct injection for the test, indirect injection (tool output, retrieved document, inter-agent message) for the evasion. ATLAS catalogs both as sub-techniques and backs them with case studies from published injection research (InjecAgent, the indirect-prompt-injection benchmark literature, and the agent-in-the-middle attack patterns covered in SDD-B03 and SDD-B04). The OWASP cross-reference is ASI01 (Goal Hijacking) and ASI07 (Insecure Output Handling, the indirect channel). The Microsoft taxonomy cross-reference is the Cogitative Failure class (B10) — injection succeeds when the model treats an untrusted data channel as a trusted instruction channel. The evasion is always the indirect channel the per-row test does not exercise; ATLAS's contribution is to name this as a Defense Evasion technique (AML.T0015) rather than leaving it implicit.

### Model Inversion (AML.T0043 / AML.T0026) — the Exfiltration technique

Model inversion is the family of attacks that recover information about a model's training data from its outputs. The procedure: query the model (or read its weights if white-box) with crafted inputs, observe the outputs, and reconstruct training examples or membership facts. The classic case study is the reconstruction of training images from a facial-recognition model (Fredrikson et al., 2015); the modern LLM analogue is extracting memorized training text by sampling high-perplexity completions (Carlini et al., "Extracting Training Data from Large Language Models"). The OWASP cross-reference is none directly (model inversion is not in the agentic top 10 because it targets the model, not the agent) — which is exactly why ATLAS is the connective tissue: OWASP covers the agent, ATLAS covers the model the agent is built on. The Microsoft cross-reference is the Data and Model Security class. The evasion: there is no standard defense to evade. The mitigation is upstream — restrict ML Model Access so the adversary cannot query enough to invert.

### Data Poisoning (AML.T0034) — the Persistence technique

Data poisoning is the insertion of malicious examples into the training data so the trained model behaves incorrectly on a trigger known to the attacker. The procedure: identify the training pipeline's data sources (open-source datasets, user-feedback loops, web crawls), inject examples that are benign on their face but encode a trigger, and let the pipeline train the backdoor in. The classic case study is the BadNets attack (Gu, Dolan-Gavitt, Garg, 2017) — a backdoored network that classifies cleanly on normal inputs and misclassifies on a trigger pattern, surviving transfer learning and fine-tuning. The modern analogue is the pretraining-data poisoning of LLMs via web content (Anthropic, CARPET-BOMB, the "poisoned RAG" literature). The OWASP cross-reference is ASI08 (Supply Chain) — a poisoned dataset is a supply-chain compromise of the model layer. The ATLAS Persistence tactic placement is load-bearing: a poisoned model is a *durable* compromise that survives redetection, distinct from a one-shot injection. The evasion: there is no runtime defense, because the malice is baked into the weights. Detection requires pre-deployment scanning (the B13 deep-dive territory).

### Adversarial Examples (AML.T0040 / AML.T0018) — the Impact technique

Adversarial examples are inputs crafted to cause a specific misclassification or misbehavior. The procedure: obtain query access (black-box) or weight access (white-box) to the target model, optimize an input to maximize the probability of the target misbehavior while minimizing perceptual change, and deliver the input. The classic case studies are the image-classifier attacks (Goodfellow et al., "Explaining and Harnessing Adversarial Examples"; the "1-pixel attack"; the stop-sign-to-speed-limit physical-world attack). The LLM analogue is the jailbreak — a crafted prompt that bypasses alignment to elicit restricted content (covered in C3 FT17 abliteration, which is the representation-level variant). The OWASP cross-reference is ASI01 (Goal Hijacking — a jailbreak is a goal hijack) and ASI06 (Cascading Hallucination — an adversarial input can trigger a specific hallucination). The evasion: adversarial training is the standard defense; the evasion is the transferability of adversarial examples (an example crafted against one model often works against another), which means a surrogate-model attack (AML.T0024 staging) bypasses model-specific adversarial training.

### Model Stealing (AML.T0025) — the Collection + Exfiltration technique

Model stealing is the extraction of a model's functionality (and sometimes its weights) by querying it and training a surrogate. The procedure: query the target model with a large set of inputs, record the outputs (including confidence scores if exposed), and train a local model to match. The classic case study is Tramèr et al. ("Stealing Machine Learning Models via Prediction APIs", 2016), which extracted production models from major ML-as-a-service providers with thousands of queries. The LLM analogue is distillation-based extraction — querying a target LLM and fine-tuning a smaller model on the query-response pairs to replicate its behavior. The OWASP cross-reference is none in the agent layer (model stealing targets the provider); the ATLAS cross-reference is the ML Attack Staging tactic, because a stolen model enables adversarial-example crafting and membership-inference attacks offline. The evasion: rate limiting and query auditing are the standard defenses; the evasion is the low-and-slow query pattern that stays under the rate limit, which is the same shape as the ASI09 under-threshold loop.

### Membership Inference (AML.T0014 variant) — the Collection technique

Membership inference determines whether a specific example was in a model's training data. The procedure: query the model with a candidate example, observe the output confidence or loss, and compare against a threshold calibrated on known members and non-members. The classic case study is Shokri et al. ("Membership Inference Attacks Against Machine Learning Models", 2017), which demonstrated the attack against production models. The LLM analogue is detecting whether a specific document was in the pretraining corpus (a privacy and IP concern, and the foundation of canary-based training-data detection). The OWASP cross-reference is none in the agent layer; the Microsoft cross-reference is the Data and Model Security class. The evasion: the standard defense is differential privacy in training; the evasion is that DP defenses degrade model quality, creating a quality-privacy tradeoff that producers often resolve in favor of quality — leaving the attack viable.

### The cross-reference matrix

The six techniques map across the three frameworks as follows. OWASP ASI covers the agent layer; ATLAS covers the model layer the agent is built on; the Microsoft taxonomy (B10) covers the failure-mode classification. Where a technique appears in all three, that is the highest-confidence finding surface.

| ATLAS technique | Tactic | OWASP ASI | Microsoft B10 | Case study |
| --- | --- | --- | --- | --- |
| Prompt Injection (AML.T0048) | Execution, Impact | ASI01, ASI07 | Cogitative Failure | InjecAgent, indirect injection benchmarks |
| Model Inversion (AML.T0043) | Exfiltration | (model layer, not agent) | Data & Model Security | Fredrikson 2015; Carlini LLM extraction |
| Data Poisoning (AML.T0034) | Persistence | ASI08 (supply chain) | Data & Model Security | BadNets; pretraining poisoning |
| Adversarial Examples (AML.T0040) | Impact | ASI01, ASI06 | Cogitative Failure | Goodfellow; physical-world attacks |
| Model Stealing (AML.T0025) | Collection, Exfiltration | (model layer) | Data & Model Security | Tramèr 2016; LLM distillation theft |
| Membership Inference | Collection | (model layer) | Data & Model Security | Shokri 2017; training-data canaries |

The empty OWASP cells are the load-bearing finding: **OWASP ASI is silent on the model layer because it is an agent-layer framework.** ATLAS is the framework that covers the model. An engagement scoped only to OWASP ASI misses every model-layer technique; an engagement scoped to ATLAS covers both, because every agent-layer OWASP row maps to an ATLAS tactic, and ATLAS adds the model-layer tactics OWASP does not touch. This is the "connective tissue" claim: ATLAS is the superset, organized as a kill chain, that lets one engagement cover agent and model.

---

## SDD-B12.3 — Planning an Engagement with ATLAS

### The planning procedure

A B12 engagement scoped against an agentic harness follows a four-step ATLAS-driven procedure:

**Step 1 — Establish the access tier.** What can the adversary reach? Black-box API (the chat endpoint only), gray-box (tool schemas and system prompt visible via Discovery), or white-box (open-weights model, the harness source, the checkpoint files). The access tier determines which ATLAS techniques are in scope. Black-box scopes you to prompt injection, model stealing, membership inference. White-box adds adversarial examples, representation-level attacks (B13), and weight poisoning. Record the tier as the engagement's first finding — it bounds everything downstream.

**Step 2 — Walk the matrix left to right.** For each tactic, list the techniques that apply to this target's access tier and platform. Use the Technique Maturity filter to deprioritize theoretical techniques in a time-boxed engagement. The output is a technique inventory: "for this target, at this access tier, these N techniques are in scope." This inventory is the engagement's scope document, and it is derived from the matrix rather than from the assessor's prior experience — which is the load-bearing value. An assessor who relies on prior experience reproduces the techniques they have used before; an assessor who walks the matrix covers the techniques the field has documented.

**Step 3 — Map each technique to the target's surfaces.** For each in-scope technique, identify the concrete attack surface on the target. Prompt Injection maps to the user-turn input, the tool outputs, the retrieved documents, the inter-agent messages (the SDD-B01 indirect channels). Data Poisoning maps to the training pipeline, the fine-tuning corpus, the RAG index, the memory store (ASI04). Model Stealing maps to the inference endpoint and its rate limits. The output is a technique-to-surface map, which is the engagement's attack plan.

**Step 4 — Design the chains.** Single-technique findings are the entry points; compound chains are the findings. Use the ATLAS kill-chain ordering to construct chains: a Reconnaissance technique (discover the tool list) enables a Discovery technique (probe the trust boundaries), enables an Execution technique (indirect injection), enables an Impact technique (privilege escalation via ASI10). Each chain is a finding; the single techniques are the links. This is the SDD-B01 "compound is the finding" claim, restated in ATLAS terms: the ATLAS kill chain is the structure for designing the compound.

### Mapping ATLAS against the Tau harness (the lab)

The lab maps the ATLAS matrix against the Tau harness (SDD-B11) — a zero-defense agentic system with seven attack surfaces and none of the controls from B2–B8. The exercise: for each of the twelve ATLAS tactics, identify which Tau surfaces expose it, which techniques apply, and which B-module control would close it.

The expected output: nearly every ATLAS tactic applies, because Tau is undefended. Prompt Injection applies (Tau has no taint gate). Persistence applies (Tau's memory writes are unmanaged). Defense Evasion is trivially satisfied (there is nothing to evade). Impact applies (Tau's bash tool runs unsandboxed). The exercise's value is not the finding (everything applies) but the *mapping*: the student produces a tactic-to-surface-to-control document that becomes the hardening plan. Each row of the document names an ATLAS tactic, the Tau surface it applies to, and the B-module that closes it — which is the concrete artifact a B12 engagement delivers.

This is the deep-dive's load-bearing connection to the rest of the curriculum: ATLAS is the adversary's playbook; the B-modules are the builder's response. Walking ATLAS against Tau produces the complete hardening map, because every ATLAS tactic has a B-module control that addresses it, and every B-module control has an ATLAS tactic that motivates it. The frameworks are inverses of each other, and reading them together is the engagement.

---

## Anti-patterns

1. **Treating ATLAS as a checklist instead of a kill chain.** OWASP ASI (B9) is a checklist — ten rows, score each. ATLAS is a kill chain — twelve tactics ordered by adversary progression. Running ATLAS as "we tested one technique per tactic and here is the scorecard" misses the point. The value is the chain: a Reconnaissance technique enables an Execution technique enables an Impact technique. The compound is the finding. Score the chains, not the techniques in isolation.

2. **Scoping the engagement to agent-layer techniques only.** Because the curriculum's context is agentic harnesses, the temptation is to scope ATLAS to the prompt-injection and tool-abuse tactics and declare the model layer out of scope. This is the OWASP trap — OWASP ASI covers the agent and is silent on the model. ATLAS's value is precisely the model-layer coverage (model inversion, data poisoning, model stealing, membership inference) that OWASP omits. An engagement that skips the model layer because "the agent is the target" misses the asset the agent is built on.

3. **Ignoring Technique Maturity.** ATLAS techniques range from theoretical (published, never observed in the wild) to weaponized (available as tooling, used against production). A time-boxed engagement that treats all techniques equally will spend half its time on techniques no adversary has ever used. Filter by maturity: spend engagement time on the techniques your actual adversary would plausibly run. This is the same prioritization logic as the Microsoft taxonomy's "frequency x impact" scoring.

4. **Mapping ATLAS to OWASP one-to-one and stopping there.** Several ATLAS techniques map cleanly to OWASP rows (Prompt Injection → ASI01, Persistence → ASI04/08). The temptation is to map the obvious ones and skip the rest. This reproduces the OWASP scope (and its blind spots) in ATLAS clothing. The value of ATLAS is the techniques that do NOT map to OWASP — the model-layer techniques that have no agent-layer row. Map the unmapped ones first; they are the finding surface OWASP cannot reach.

5. **Confusing ATLAS mitigations with controls.** ATLAS mitigations are framework-agnostic control classes ("input validation," "adversarial training"). They are not products and they are not the B-module controls. Translating an ATLAS mitigation into a B-module control is the curriculum's work, not ATLAS's. Do not report "we implemented AML.M1015" — report "we implemented the B2 taint gate, which is the B-module instantiation of the ATLAS input-validation mitigation class."

---

## Key terms

| Term | Definition |
| --- | --- |
| MITRE ATLAS | Adversarial Threat Landscape for AI Systems; the ATT&CK analog for AI/ML, maintained by MITRE |
| Tactic (AML.TA0001–12) | An adversary objective in the kill chain (Reconnaissance, Initial Access, ..., Impact) |
| Technique (AML.Txxxx) | How the adversary achieves a tactic; a cell in the matrix |
| Case study | A real-world attack cataloged against the techniques it used; the evidence layer |
| Mitigation (AML.Mxxxx) | A framework-agnostic defensive control class mapped to the techniques it addresses |
| Technique Maturity | A filter (added Secure AI v2, May 2026) tagging each technique by in-the-wild weaponization level |
| ML Model Access | The ATLAS tactic with no ATT&CK analog — the adversary obtains access to the model asset |
| ML Attack Staging | The tactic covering offline attack preparation (surrogate training, adversarial-example crafting) |
| Kill chain | The left-to-right ordering of tactics from Reconnaissance through Impact; the structure for chain design |
| ATT&CK composition | The pattern of combining ATT&CK (traditional access) with ATLAS (ML weaponization) in one engagement |

---

## Lab exercise

Map ATLAS against the Tau harness. See [07-lab-spec.md](07-lab-spec.md) — "Map the ATLAS Matrix Against a Zero-Defense Harness." The lab builds an ATLAS-tactic-to-Tau-surface-to-B-module-control mapping, establishes the access tier, and designs one compound chain across the ATLAS kill chain. Python 3.10+, stdlib only, no GPU, 45–60 min.

---

## References

1. MITRE ATLAS — https://atlas.mitre.org/ (the canonical matrix; v5.x stream, twelve tactics, ~80+ techniques)
2. MITRE ATT&CK — https://attack.mitre.org/ (the traditional adversary framework ATLAS mirrors and composes with)
3. ATLAS case studies — https://atlas.mitre.org/studies/ (the evidence layer; each technique backed by published attacks)
4. ATLAS mitigations — https://atlas.mitre.org/mitigations/ (framework-agnostic control classes mapped to techniques)
5. MITRE ATLAS data repository — github.com/mitre-atlas/atlas-data (machine-readable YAML; the v5.x tactic and technique inventory)
6. OWASP Agentic AI Top 10 (ASI01–ASI10) — the builder's checklist; SDD-B01 reads it as the offensive expansion
7. Microsoft AI Failure Mode Taxonomy (B10) — the diagnostic framework; cross-referenced per technique above
8. Gu, Dolan-Gavitt, Garg — "BadNets: Identifying Vulnerabilities in the ML Model Supply Chain" (2017) — the canonical data-poisoning case study
9. Fredrikson et al. — "Model Inversion Attacks that Exploit Confidence Information" (2015) — the canonical model-inversion case study
10. Carlini et al. — "Extracting Training Data from Large Language Models" (2021) — the LLM training-data extraction case study
11. Tramèr et al. — "Stealing Machine Learning Models via Prediction APIs" (2016) — the canonical model-stealing case study
12. Shokri et al. — "Membership Inference Attacks Against Machine Learning Models" (2017) — the canonical membership-inference case study
13. Goodfellow et al. — "Explaining and Harnessing Adversarial Examples" (2015) — the canonical adversarial-examples paper
14. SDD-B01 (this curriculum) — the offensive expansion of OWASP ASI; the chain-design methodology ATLAS complements
15. SDD-B11 (this curriculum) — the Tau harness; the zero-defense target the lab maps ATLAS against
16. B13 (this curriculum) — Representation-Level Attacks; the deep-dive on the ATLAS Persistence and Execution techniques that target model internals