"front"	"back"	"tags"
"What is MITRE ATLAS, and what is its curriculum role (the load-bearing framing)?"	"ATLAS (Adversarial Threat Landscape for AI Systems) is MITRE's ATT&CK analog for AI/ML — a living knowledge base of adversary tactics and techniques against AI-enabled systems, structured like ATT&CK (tactics × techniques × case studies × mitigations). Curriculum 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 — the framework that names every technique an adversary has used, in the order they chain them."	c2b::sddb12::recall
"How is ATLAS structured (the five components)?"	"TACTICS (AML.TA0001–12) — adversary objectives, kill-chain columns. TECHNIQUES (AML.Txxxx) — how, the cells; with sub-techniques, procedure examples, mitigations. CASE STUDIES — real-world attacks evidencing each technique (why it is in the matrix). MITIGATIONS (AML.Mxxxx) — framework-agnostic control classes (input validation, adversarial training), not products. TECHNIQUE MATURITY filter (added Secure AI v2 May 2026) — tags each technique from theoretical to weaponized; the red-team planner's first prioritization lever."	c2b::sddb12::recall
"Name the twelve ATLAS tactics in kill-chain order, and flag the two with no ATT&CK analog."	"(1) Reconnaissance TA0001, (2) Resource Development TA0002 (parallel feeder), (3) Initial Access TA0003, (4) ML Model Access TA0004 ★ no ATT&CK analog, (5) Execution TA0005, (6) Persistence TA0006, (7) Defense Evasion TA0007, (8) Discovery TA0008, (9) Collection TA0009, (10) ML Attack Staging TA0010 ★ no ATT&CK analog, (11) Exfiltration TA0011, (12) Impact TA0012. The two AI-specific tactics exist because AI systems have an asset class — the trained model — that traditional systems do not."	c2b::sddb12::recall
"Why do ML Model Access (TA0004) and ML Attack Staging (TA0010) have no ATT&CK analog, and why are they load-bearing?"	"ML MODEL ACCESS exists because AI systems have an asset class (the trained model) traditional systems lack. The access tier determines which downstream techniques are available: black-box API scopes to prompt injection, model stealing, membership inference; white-box weights add adversarial examples, representation-level attacks (B13), weight poisoning. ML ATTACK STAGING is the offline preparation (craft adversarial examples, train surrogates) that has NO RUNTIME DEFENSE because it happens on the adversary's hardware. Scoping these two out reduces ATLAS to relabeled ATT&CK and loses the model-layer coverage."	c2b::sddb12::analysis
"How does the access tier (black-box / gray-box / white-box) determine which ATLAS techniques are in scope?"	"BLACK-BOX API (chat endpoint only) scopes to: prompt injection, model stealing (AML.T0025), membership inference. GRAY-BOX (tool schemas + system prompt visible via Discovery) adds: indirect injection chains, capability enumeration, ASI05-style dispatch attacks. WHITE-BOX (open weights, harness source, checkpoints) adds: adversarial examples at scale, representation-level attacks (B13 — CAA, weight editing), weight-poisoning persistence, model inversion with full weight access. The access tier is the FIRST variable an ATLAS-aware red team records — it bounds the entire engagement."	c2b::sddb12::analysis
"Give the ATLAS treatment of Prompt Injection (AML.T0048) — tactic, OWASP/MSFT cross-ref, evasion."	"TACTIC: Execution and Impact. The adversary executes an adversarial input through the model's instruction pipeline. Sub-techniques: direct injection (test surface) vs indirect injection (tool output, retrieved doc, inter-agent message — the deployed attack, per SDD-B01). CASE STUDIES: InjecAgent, indirect-injection benchmarks. OWASP cross-ref: ASI01 (Goal Hijacking) and ASI07 (Insecure Output Handling — the indirect channel). Microsoft B10 cross-ref: Cogitative Failure. EVASION: the indirect channel the per-row test does not exercise; ATLAS catalogs this as Defense Evasion AML.T0015."	c2b::sddb12::application
"Give the ATLAS treatment of Data Poisoning (AML.T0034) — tactic, case study, why it is durable."	"TACTIC: Persistence — the tactic that turns a one-time injection into a durable compromise surviving model reloads and retraining. CASE STUDY: BadNets (Gu, Dolan-Gavitt, Garg, 2017) — a backdoored network that classifies cleanly on normal inputs and misclassifies on a secret trigger pattern; the load-bearing finding is that the backdoor SURVIVES transfer learning and fine-tuning. Modern analogue: pretraining-data poisoning of LLMs via web content. OWASP cross-ref: ASI08 (Supply Chain) — a poisoned dataset is a supply-chain compromise of the model layer. NO RUNTIME DEFENSE: the malice is baked into the weights. Detection requires pre-deployment scanning (B13)."	c2b::sddb12::application
"Give the ATLAS treatment of Model Stealing (AML.T0025) — tactic, case study, evasion."	"TACTIC: Collection and Exfiltration. The adversary queries the target model with many inputs, records outputs (and confidence scores if exposed), trains a surrogate to replicate behavior. CASE STUDY: Tramèr et al. 2016 — extracted production models from major ML-as-a-service providers with thousands of queries. LLM analogue: distillation-based extraction (query target, fine-tune smaller model on query-response pairs). OWASP cross-ref: NONE in agent layer (targets the provider). STANDARD DEFENSE: rate limiting + query auditing. EVASION: low-and-slow query pattern under the rate limit — same shape as the SDD-B01 ASI09 under-threshold loop."	c2b::sddb12::application
"Give the ATLAS treatment of Model Inversion (AML.T0043) — tactic, case study, why OWASP is silent."	"TACTIC: Exfiltration. Recover information about training data from the model's outputs. CASE STUDIES: Fredrikson et al. 2015 (reconstructed training images from a facial-recognition model); Carlini et al. 'Extracting Training Data from Large Language Models' (memorized text extraction). OWASP cross-ref: NONE — Model Inversion targets the model, not the agent. THIS IS THE LOAD-BEARING GAP: OWASP ASI is silent on the model layer because it is an agent-layer framework. ATLAS is the framework that covers the model the agent is built on. EVASION: there is no standard defense to evade — mitigation is upstream (restrict ML Model Access so the adversary cannot query enough to invert)."	c2b::sddb12::analysis
"Give the ATLAS treatment of Adversarial Examples (AML.T0040) — tactic, case study, connection to C3 FT17."	"TACTIC: Impact (and ML Attack Staging for the offline crafting). Crafted inputs causing specific misclassification or misbehavior. CASE STUDIES: Goodfellow et al. 2015 ('Explaining and Harnessing Adversarial Examples'); the 1-pixel attack; physical-world stop-sign-to-speed-limit attacks. LLM analogue: the jailbreak (a crafted prompt that bypasses alignment). OWASP cross-ref: ASI01 (Goal Hijack — a jailbreak is a goal hijack) and ASI06 (Cascading Hallucination). C3 FT17 CONNECTION: abliteration is the representation-level variant — the same objective (bypass alignment) achieved by editing internal representations rather than crafting inputs. STANDARD DEFENSE: adversarial training. EVASION: transferability (an example crafted against one model often works against another), enabling surrogate-model attacks."	c2b::sddb12::application
"Why do four of the six load-bearing ATLAS techniques have no OWASP ASI row, and what is the engagement implication?"	"Four of six (Model Inversion, Data Poisoning model-layer variant, Model Stealing, Membership Inference) target the MODEL layer the agent is built on. OWASP ASI is an AGENT-layer framework — it covers the agent loop, the tools, the permissions, the memory. It is silent on the model asset by design. The engagement implication: scoping only to OWASP misses every model-layer technique. Scoping 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. ATLAS is the superset; the empty OWASP cells are the finding surface OWASP cannot reach."	c2b::sddb12::analysis
"What does it mean that ATLAS, OWASP, and Microsoft B10 are 'three angles on the same adversary behavior'?"	"ATLAS = the adversary's kill chain (what they do, in order — twelve tactics from Reconnaissance through Impact). OWASP ASI = the builder's checklist (which row to score — ten risks, one control each). Microsoft B10 = the diagnostic (which class of failure — twelve failure modes organized by origin). A failure that is an ATLAS technique, an OWASP row, AND a Microsoft failure mode is the HIGHEST-CONFIDENCE finding — robust to framework-shopping. The empty OWASP cells (model-layer techniques) are where ATLAS adds coverage the other two cannot reach."	c2b::sddb12::analysis
"State the four-step ATLAS-driven engagement-planning procedure."	"STEP 1 — Establish the access tier (black-box API / gray-box / white-box weights). Record it as the first finding; it bounds everything downstream. STEP 2 — Walk the matrix left to right; filter by Technique Maturity; output is the technique inventory (the scope, derived from the matrix not from the assessor's prior experience). STEP 3 — Map each in-scope technique to a concrete target surface (PI → user turn + tool outputs + retrieved docs; Data Poisoning → training pipeline + RAG index + memory store); output is the technique-to-surface map (the attack plan). STEP 4 — Design the chains using kill-chain ordering (Recon enables Discovery enables Execution enables Impact); single-technique findings are entry points, compound chains are the findings."	c2b::sddb12::application
"Why is 'walking the matrix' more valuable than 'relying on assessor prior experience'?"	"An assessor relying on prior experience reproduces the techniques they have used before — their personal highlight reel. An assessor walking the matrix covers the techniques the field has DOCUMENTED, organized as the adversary actually chains them. The matrix is derived from published case studies and incident reports, not from one assessor's history. This is the difference between a coverage-driven engagement (matrix-derived, reproducible, defensible scope) and a highlight-driven engagement (assessor-derived, irreproducible, biased toward known techniques). The matrix is also auditable — a reviewer can check which tactics were in scope and which were filtered out by maturity, and challenge the filtering."	c2b::sddb12::analysis
"Why is the ATLAS–Tau mapping the inverse of the B-module hardening plan?"	"Every ATLAS tactic has a Tau surface (Tau is undefended, so every tactic applies), and every Tau surface has a B-module control that closes it. The tactic-to-surface-to-control map IS the hardening plan. Prompt Injection → agent loop → B2 taint gate. Persistence → memory store → B3 memory-write gate. Impact → bash tool → B7 sandbox. Exfiltration → credential store → B5 vault. Discovery/Collection → event stream → B8 observability. ATLAS is the adversary's playbook; the B-modules are the builder's response. The two frameworks are inverses — every offensive tactic has a defensive control, every defensive control has an offensive tactic that motivates it. Reading them together is the engagement."	c2b::sddb12::analysis
"Why is 'treating ATLAS as a checklist' an anti-pattern, and what is the cure?"	"ATLAS is a KILL CHAIN — twelve tactics ordered by adversary progression. Treating it as 'we tested one technique per tactic and here is the scorecard' reproduces the OWASP-as-checklist mistake in ATLAS clothing. The value of ATLAS is the CHAIN: Reconnaissance enables Initial Access enables Execution enables Impact. A single-technique finding is an entry point; the compound chain is the finding. CURE: score the chains, not the techniques in isolation. Walk the matrix left to right and design compound findings where each step passes its individual control but the compound reaches impact (the SDD-B01 compound-is-the-finding claim, restated in ATLAS terms)."	c2b::sddb12::analysis
"Why is 'scoping to agent-layer techniques only' an anti-pattern?"	"Because the curriculum context is agentic harnesses, the temptation is to scope ATLAS to prompt injection and tool abuse and declare the model layer (model inversion, data poisoning, model stealing, membership inference) out of scope. This is the OWASP trap — OWASP covers the agent and is silent on the model. ATLAS's value is precisely the model-layer coverage that OWASP omits. Four of the six load-bearing ATLAS techniques target the model layer. An engagement that skips the model layer because 'the agent is the target' misses the asset the agent is built on. The cure: scope the engagement by ACCESS TIER, which naturally brings the model-layer techniques in scope when the adversary has white-box or sufficient query access."	c2b::sddb12::analysis
"Why is 'ignoring Technique Maturity' an anti-pattern?"	"ATLAS techniques range from theoretical (published in a paper, never observed in the wild) to weaponized (available as tooling, used against production systems). A time-boxed engagement that treats all ~80+ techniques equally will spend half its time on techniques no adversary has ever used, leaving no time for the weaponized ones that actually threaten production. CURE: filter by Technique Maturity first (added Secure AI v2, May 2026). Spend engagement time on techniques your actual adversary would plausibly run. This is the same prioritization logic as the Microsoft B10 frequency-times-impact scoring — rank by adversary realism, not by theoretical completeness."	c2b::sddb12::analysis
"Why is 'mapping ATLAS to OWASP one-to-one and stopping there' an anti-pattern?"	"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 (Model Inversion, Model Stealing, Membership Inference) that have no agent-layer row. CURE: map the UNMAPPED techniques first; they are the finding surface OWASP cannot reach. The obvious mappings are confirmation; the unmapped mappings are the new findings."	c2b::sddb12::analysis
"Why is 'confusing ATLAS mitigations with controls' an anti-pattern?"	"ATLAS mitigations are framework-AGNOSTIC control classes — 'input validation,' 'adversarial training,' 'output filtering.' 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. CURE: do not report 'we implemented AML.M1015' (a mitigation class). Report 'we implemented the B2 taint gate, which is the B-module INSTANTIATION of the ATLAS input-validation mitigation class.' The mitigation tells you the control class to build; the B-module tells you the specific implementation. Conflating them produces reports that are unfalsifiable ('we did input validation') rather than auditable ('we built a taint gate at the tool-output boundary')."	c2b::sddb12::analysis