# Teaching Script — Deep-Dive SDD-B12: MITRE ATLAS

**Course**: 2B — Securing & Attacking Harnesses and LLMs · **Deep-Dive**: SDD-B12
**Duration**: ~35–40 min spoken at ~140 wpm · **Slides**: 12 sections in `03-slide-deck.html`

> This is a verbatim teaching transcript. Each section is cued to a slide. Read it as you would speak it. The bracketed cues — `[SLIDE N]` — correspond to the slide deck sections in order.

---

[SLIDE 1 — Cover]

Welcome back. This is Deep-Dive SDD-B12, and the topic is MITRE ATLAS — the Adversarial Threat Landscape for AI Systems. You have already met three frameworks in this pillar. B9 gave you OWASP ASI, the builder's checklist. B10 gave you the Microsoft failure taxonomy, the diagnostic. SDD-B01 gave you the offensive expansion of the OWASP rows. This deep-dive gives you the fourth framework, and the load-bearing claim is that ATLAS is the connective tissue between all three. By the end of this session you will be able to read the ATLAS matrix end to end, plan an engagement with it, and map it against the Tau harness you met in SDD-B11. Prereqs are B1, B9, B10, SDD-B01, and SDD-B11. If any of those is fuzzy, the cross-references in this deep-dive will not land.

[SLIDE 2 — The thesis]

Here is the framing. ATLAS gives you the adversary's playbook. B9 gives you the builder's checklist. SDD-B01 gives you the offensive expansion. ATLAS is the connective tissue. Now, why do we need a fourth framework? Because none of the first three is the adversary's full playbook. OWASP is a checklist — ten rows, score each. Microsoft is a diagnostic — twelve failure modes organized by where in the system the failure originates. SDD-B01 is the offensive expansion of OWASP — the same ten rows read as attack procedures. But a real adversary does not think in ten rows or twelve failure modes. A real adversary thinks in a kill chain. They do 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. ATLAS is that library, structured exactly like ATT&CK, maintained by MITRE, fed by real incident reports and published research.

[SLIDE 3 — What ATLAS is, structurally]

ATLAS mirrors ATT&CK precisely, and that 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 through TA0012 — are the adversary's objectives, ordered left to right as a kill chain. Each tactic answers why. Techniques are how. Each technique sits under one or more tactics, has a unique ID, a description, procedure examples, and mitigations. Sub-techniques give you finer granularity — for example, Prompt Injection has sub-techniques for direct versus indirect injection, which maps directly to the SDD-B01 distinction. Case studies are the evidence layer. A case study is a real-world attack cataloged against the techniques it used. Case studies are why a technique is in the matrix and not on a wishlist. Mitigations are framework-agnostic control classes — input validation, output filtering, adversarial training — not products. And the Technique Maturity filter, added in the Secure AI v2 release in May 2026, tags each technique by how weaponized it is in the wild, from theoretical, meaning published in a paper but never observed, to weaponized, meaning available as tooling and used against production systems. That filter is the red-team planner's first prioritization lever.

[SLIDE 4 — The twelve tactics, kill-chain order]

Let me walk you through the twelve tactics in kill-chain order. This is the mental model. If you internalize only one slide from this deep-dive, make it this one. Reconnaissance — the adversary gathers information about the target AI system. Resource Development — they build attack capabilities, and this one sits outside the linear chain because it happens in parallel, before and during the attack. Initial Access — they gain a foothold, and this splits into traditional access like phishing, and ML-specific access like a poisoned model. ML Model Access — they obtain access to the model itself, either the weights, the inference API, or a local copy. Execution — they run adversarial inputs through the model, and this is where prompt injection lives. Persistence — they maintain access across sessions, and this is where weight poisoning and durable memory poisoning live. Defense Evasion — they evade your guardrails and detectors. Discovery — they explore the internal layout, learn the tool list, the trust boundaries. Collection — they gather data of interest. ML Attack Staging — they prepare the attack offline, craft adversarial examples, train surrogate models. Exfiltration — they remove data. Impact — they degrade, manipulate, or destroy. Walk it left to right. That is the adversary's chain.

[SLIDE 5 — The two tactics with no ATT&CK analog]

Now look at the two tactics I marked in warn-orange. ML Model Access and ML Attack Staging have no ATT&CK analog. They exist because AI systems have an asset class — the trained model — that traditional systems do not. ML Model Access is the tactic that determines which downstream techniques are even available. Black-box API access scopes you to prompt injection, model stealing, and membership inference. White-box weight access unlocks adversarial examples at scale, representation-level attacks from B13, and weight-poisoning persistence. The access tier is the first variable an ATLAS-aware red team establishes. ML Attack Staging is the tactic that has no runtime defense, because it happens on the adversary's laptop. They craft the adversarial examples, they train the surrogate model, they build the payload — you cannot detect staging that happens on hardware you do not control. The mitigation is upstream: restrict ML Model Access so the adversary cannot query enough to stage an attack. If you scope these two tactics out of your engagement, you have reduced ATLAS to a relabeled ATT&CK, and you have lost the model-layer coverage that justifies the framework.

[SLIDE 6 — The six load-bearing techniques]

Of the roughly eighty-plus techniques in ATLAS, six recur in nearly every agentic-harness engagement. Prompt Injection, AML.T0048, the Execution and Impact technique. Model Inversion, AML.T0043, the Exfiltration technique. Data Poisoning, AML.T0034, the Persistence technique. Adversarial Examples, AML.T0040, the Impact technique. Model Stealing, AML.T0025, the Collection and Exfiltration technique. And Membership Inference, the Collection technique. Now look at the OWASP column. Prompt Injection maps to ASI01 and ASI07. Data Poisoning maps to ASI08, the supply chain row. Adversarial Examples map to ASI01 and ASI06. But Model Inversion, Model Stealing, and Membership Inference have no OWASP row. That is not an oversight. OWASP is an agent-layer framework. Those three techniques target the model layer the agent is built on. OWASP is silent on the model layer by design. ATLAS is the framework that covers the model. This is the connective-tissue claim in its sharpest form: an engagement scoped only to OWASP 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.

[SLIDE 7 — Three techniques in depth, case-study anchor]

Let me anchor three of these with the case studies that evidence them. Prompt Injection — direct injection is what your tests cover. Indirect injection, where the payload arrives in a tool output, a retrieved document, or an inter-agent message, is the deployed attack. That is the SDD-B01 load-bearing evasion. The case studies are InjecAgent and the indirect-injection benchmark literature. Data Poisoning — the canonical case study is BadNets, from 2017. The attackers trained a backdoored network that classifies cleanly on normal inputs and misclassifies on a trigger pattern known only to them. The load-bearing finding from BadNets is that the backdoor survives transfer learning and fine-tuning. This is a durable compromise. There is no runtime defense, because the malice is baked into the weights. The modern analogue is pretraining-data poisoning of LLMs via web content. Model Stealing — the canonical case study is Tramèr and colleagues from 2016, who extracted production models from major ML-as-a-service providers with thousands of queries. The LLM analogue is distillation-based extraction — query the target, fine-tune a smaller model on the query-response pairs, replicate the behavior. The standard defense is rate limiting and query auditing. 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 from SDD-B01. The other three — Model Inversion, Adversarial Examples, Membership Inference — follow the same structure: case study anchors the technique, OWASP cross-reference names the overlap or its absence, Microsoft B10 names the failure class.

[SLIDE 8 — The cross-reference: three frameworks, one finding surface]

So here is how the three frameworks relate. A failure that is an ATLAS technique, an OWASP ASI row, and a Microsoft B10 failure mode is the highest-confidence finding you can report. All three frameworks describe the same adversary behavior from different angles. ATLAS tells you what the adversary does and in what order — the kill chain. OWASP tells you which row to score it against — the builder's checklist. Microsoft tells you which class of failure it is — the diagnostic. When all three agree, you have a finding that is robust to framework-shopping. And remember the empty OWASP cells — Model Inversion, Model Stealing, Membership Inference. Those are the finding surface ATLAS adds that OWASP cannot reach. An engagement that reports only on OWASP-confirmed findings is silent on the model layer.

[SLIDE 9 — Planning an engagement, the four-step procedure]

Now the practical part. How do you use ATLAS to plan a red-team engagement? Four steps. Step one: establish the access tier. What can the adversary actually reach? Black-box API — the chat endpoint only. Gray-box — tool schemas and system prompt are visible through Discovery. White-box — open-weights model, the harness source code, the checkpoint files. The tier determines which ATLAS techniques are in scope. Record the tier as the engagement's first finding, because it bounds everything downstream. Step two: 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 of step two is the technique inventory — and this is the engagement's scope document, derived from the matrix rather than from the assessor's prior experience. That 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 three: map each in-scope technique to the target's concrete attack surfaces. Prompt Injection maps to the user-turn input, the tool outputs, the retrieved documents, the inter-agent messages. Data Poisoning maps to the training pipeline, the fine-tuning corpus, the RAG index, the memory store. The output of step three is the technique-to-surface map — the attack plan. Step four: design the chains. Single-technique findings are entry points. Compound chains are the findings. Use the ATLAS kill-chain ordering to construct them: a Reconnaissance technique enables a Discovery technique enables an Execution technique enables an Impact technique. This is the SDD-B01 compound-is-the-finding claim, restated in ATLAS terms.

[SLIDE 10 — Mapping ATLAS against Tau]

The lab maps the ATLAS matrix against the Tau harness from SDD-B11. Tau is a zero-defense agentic system — seven attack surfaces, none of the controls from B2 through B8. The exercise is: for each of the twelve ATLAS tactics, identify which Tau surface exposes it, which technique applies, and which B-module control would close it. And the expected output is: nearly every 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. The value is the mapping. You produce a tactic-to-surface-to-control document, and that document becomes the hardening plan. Each row names an ATLAS tactic, the Tau surface it applies to, and the B-module that closes it. This is the concrete artifact a B12 engagement delivers. And notice the pattern: every ATLAS tactic has a Tau surface, and every Tau surface has a B-module control. The frameworks are inverses of each other. ATLAS is the adversary's playbook. The B-modules are the builder's response. Reading them together is the engagement.

[SLIDE 11 — Anti-patterns]

Before the lab, five anti-patterns to avoid. One: treating ATLAS as a checklist instead of a kill chain. OWASP 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. Score the chains. Two: scoping the engagement to agent-layer techniques only. Because our context is agentic harnesses, the temptation is to scope ATLAS to prompt injection and tool abuse and declare the model layer out of scope. That is the OWASP trap. ATLAS's value is the model-layer coverage. Three: ignoring Technique Maturity. A time-boxed engagement that treats all techniques equally will spend half its time on techniques no adversary has ever used. Filter by maturity. Four: mapping ATLAS to OWASP one-to-one and stopping there. The obvious mappings — Prompt Injection to ASI01, Persistence to ASI04 — reproduce the OWASP scope in ATLAS clothing. The value is the unmapped techniques. Map them first. Five: confusing ATLAS mitigations with controls. ATLAS mitigations are framework-agnostic control classes. They are not products and they are not 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."

[SLIDE 12 — The lab and what comes next]

The lab is in 07-lab-spec.md. You will build the ATLAS-tactic-to-Tau-surface-to-B-module-control mapping, establish the access tier, and design one compound chain across the ATLAS kill chain. Python 3.10 plus, standard library only, no GPU, forty-five to sixty minutes. To close, here is how this deep-dive fits the pillar. B9 is the builder's checklist. SDD-B01 is the offensive expansion of those rows. SDD-B11 is the Tau harness, the zero-defense target. B13, the next module, covers Representation-Level Attacks — the model-internal techniques that ATLAS Persistence and Execution cover. B10 is the Microsoft failure taxonomy, the diagnostic overlay. Read together, ATLAS is the adversary's playbook, the B-modules are the builder's response, and the frameworks are inverses. Every tactic has a control. Every control has a tactic. The engagement walks the first and builds the second. End of deep-dive. Duration: approximately thirty-eight minutes.