@blamejs/exceptd-skills 0.20.1 → 0.21.0

package/skills/incident-response-playbook/skill.md

@@ -22,7 +22,8 @@ data_deps:
   - zeroday-lessons.json
 atlas_refs:
   - AML.T0096
-  - AML.T0017
+  - AML.T0013
+  - AML.T0024
   - AML.T0051
 attack_refs:
   - T1486
@@ -72,7 +73,7 @@ The incident-response landscape in mid-2026 is materially different from the reg
 
 - **Dwell time has compressed, but the window for regulator-clock compliance has compressed faster.** Mandiant M-Trends 2026 reports a global median dwell time of 7 days, down from 16 days in 2022. The classical IR cycle (detect → triage → contain → eradicate → recover → lessons) assumed quarters of engineering capacity. EU CRA Art. 11 (24h early warning for actively exploited vulnerabilities) and EU NIS2 Art. 23 (24h early warning for significant incidents at essential/important entities) collapse the time between "we have telemetry" and "we have a regulator notification due" to less than a day. NYDFS 23 NYCRR 500.17 requires 72h notification of cybersecurity events and 24h notification of ransom payment. CERT-In's 2022 direction requires 6h reporting for in-scope incidents in India. AU SOCI requires 12h notification for significant cyber incidents at critical infrastructure entities. The IR playbook that does not bake these clocks in is non-compliant by clock arithmetic alone.
 - **Ransomware continues to dominate the critical-infrastructure incident class.** Healthcare (Change Healthcare 2024, NHS via Synnovis 2024), energy (Colonial Pipeline 2021 echoes through 2026 OT-IT segmentation requirements), manufacturing, and water utilities take the volume. Cl0p's MOVEit campaign (2023) demonstrated mass-exploit incident shape; LockBit-style affiliate ecosystems persist post-takedown via fork brands. Initial-access brokers monetize valid-account compromise (T1078) faster than the credential-rotation cycle.
-- **AI-class incidents are operational reality, not a thought experiment.** Three sub-classes show up in 2024-2026 incident telemetry: (1) **prompt-injection breach** — indirect prompt injection via web content, RAG corpus, email signatures, or document metadata achieves unauthorized action against enterprise AI assistants and agentic systems (see `ai-attack-surface`, `rag-pipeline-security`); (2) **model exfiltration** (AML.T0017) — adversary extracts model weights, training data, or system prompts via inference-side attacks (membership inference, training-data extraction, prompt leaking); (3) **AI-API as C2 channel** (AML.T0096) — SesameOp-pattern operations where the adversary uses legitimate AI provider APIs (Claude, ChatGPT, Gemini) as a covert command-and-control channel, blending into legitimate enterprise AI usage. Detection coverage for these classes lags conventional incident classes by 12-24 months in most enterprise SOC stacks.
+- **AI-class incidents are operational reality, not a thought experiment.** Three sub-classes show up in 2024-2026 incident telemetry: (1) **prompt-injection breach** — indirect prompt injection via web content, RAG corpus, email signatures, or document metadata achieves unauthorized action against enterprise AI assistants and agentic systems (see `ai-attack-surface`, `rag-pipeline-security`); (2) **model exfiltration** (AML.T0024) — adversary extracts model weights, training data, or system prompts via inference-side attacks (membership inference, training-data extraction, prompt leaking); (3) **AI-API as C2 channel** (AML.T0096) — SesameOp-pattern operations where the adversary uses legitimate AI provider APIs (Claude, ChatGPT, Gemini) as a covert command-and-control channel, blending into legitimate enterprise AI usage. Detection coverage for these classes lags conventional incident classes by 12-24 months in most enterprise SOC stacks.
 - **AI-generated code is a new supply-chain incident vector.** GitHub Copilot, Claude Code, Cursor, and Cline produce code that ships to production without the human-author guarantee SLSA Level 3 assumes. Compromise of an AI coding assistant's training data, system prompt, or runtime pipeline (the IDE plugin, the MCP server, the model endpoint) creates a class of supply-chain incident where the artifact in the SBOM has no human author to interview. The Anthropic / OpenAI / Microsoft / Google AI bug-bounty programs are the upstream pipeline; the downstream incident response is largely undocumented at most orgs.
 - **Identity is the perimeter, and identity compromise is the dominant initial-access vector.** Snowflake 2024 (credentials harvested from infostealers used to authenticate to multi-tenant cloud without MFA), Microsoft Midnight Blizzard 2024 (legacy non-production tenant compromised via password-spray), and the broader infostealer market collectively make T1078 (Valid Accounts) the most common precursor to subsequent stages.
 - **Cloud-ephemeral evidence preservation is the new hard problem.** When the compromised workload is a serverless function (Lambda, Cloud Run, Azure Functions) that scaled to zero before triage starts, or a Kubernetes pod that the scheduler killed and replaced, the chain of custody assumed by NIST 800-86 (Guide to Integrating Forensic Techniques into Incident Response) breaks. Memory, ephemeral disk, and stdout are gone. The mid-2026 fix is pre-incident: continuous forensic-grade telemetry shipping (process trees, syscall traces, network flows, container layer diffs) to an external store before the workload terminates. Most orgs have not configured this; their first incident in an ephemeral environment becomes their lessons-learned moment.
@@ -91,8 +92,8 @@ IR obligations span four layers — methodology (NIST 800-61r3, ISO 27035, SANS
 | ISO/IEC 27035-1:2023 | Information security incident management — Principles and process | Process model: plan & prepare → detect & report → assess & decide → respond → learn lessons. | Process-shaped, not playbook-shaped. No AI-class sub-types. No regulator-clock matrix. Conformance does not imply playbook completeness. |
 | ISO/IEC 27035-2:2023 | Guidelines to plan and prepare for incident response | Planning, team structure, communication. | Same process orientation. Mentions "external reporting obligations" without operationalizing EU CRA / NIS2 / AI Act / NYDFS clocks. |
 | NIST SP 800-53 rev 5 | IR-4 Incident Handling; IR-5 Incident Monitoring; IR-6 Incident Reporting; IR-8 Incident Response Plan | Method-neutral control objectives. | Per `framework-control-gaps.json` NIST-800-53-AC-2: AC-2 (Account Management) does not require AI-agent identity lifecycle management; identity-compromise (T1078) detection feeds IR but the underlying control gap leaves AI-agent service accounts under-instrumented. IR-4 says "implement an incident handling capability" without specifying AI-class handling. |
-| ISO/IEC 27001:2022 | A.5.24 Information security incident management planning and preparation; A.5.26 Response to information security incidents; A.8.16 Monitoring activities | Process-level requirements for incident response and monitoring. | Per `framework-control-gaps.json` ISO-27001-2022-A.8.16: monitoring requirements are technology-neutral but AI-system telemetry (prompt logs, embedding-store access, model-output classification) is not addressed. An ISO 27001-certified org with no AI-system monitoring is formally compliant and operationally blind to AML.T0051 / AML.T0096 / AML.T0017. |
-| SOC 2 | CC7 (System operations — security event detection, incident response) | Trust services criteria for anomaly detection and incident response. | Per `framework-control-gaps.json` SOC2-CC7-anomaly-detection: CC7 requires anomaly detection without specifying coverage for AI-API C2 (AML.T0096), training-data exfiltration (AML.T0017), or prompt-injection incident triggers (AML.T0051). Auditors test for "an anomaly detection system" without testing whether it covers AI traffic shape. Theater-prone. |
+| ISO/IEC 27001:2022 | A.5.24 Information security incident management planning and preparation; A.5.26 Response to information security incidents; A.8.16 Monitoring activities | Process-level requirements for incident response and monitoring. | Per `framework-control-gaps.json` ISO-27001-2022-A.8.16: monitoring requirements are technology-neutral but AI-system telemetry (prompt logs, embedding-store access, model-output classification) is not addressed. An ISO 27001-certified org with no AI-system monitoring is formally compliant and operationally blind to AML.T0051 / AML.T0096 / AML.T0024. |
+| SOC 2 | CC7 (System operations — security event detection, incident response) | Trust services criteria for anomaly detection and incident response. | Per `framework-control-gaps.json` SOC2-CC7-anomaly-detection: CC7 requires anomaly detection without specifying coverage for AI-API C2 (AML.T0096), training-data exfiltration (AML.T0024), or prompt-injection incident triggers (AML.T0051). Auditors test for "an anomaly detection system" without testing whether it covers AI traffic shape. Theater-prone. |
 | EU NIS2 Directive (2022/2555) | Art. 23 — incident notification | 24h early warning, 72h initial notification, 1-month final report to national CSIRT for significant incidents at essential/important entities. | Clocks are explicit; significance criteria are partly Member-State-defined; cross-border coordination via ENISA CSIRTs Network. The IR playbook must run the clocks; the directive does not define playbook content. |
 | EU DORA (Regulation 2022/2554) | Art. 17 (ICT incident management); Art. 19 (major ICT-related incident reporting); Art. 18 (classification) | Financial-entity-specific: 4h initial notification for major ICT incidents, 72h intermediate, 1-month final, all to competent authority (national + ECB/EIOPA/ESMA depending on entity). | DORA 4h is tighter than NIS2 24h; an entity in scope of both runs whichever is shorter. DORA RTS on classification (2024) defines "major" but the operational determination at the 4h mark requires triage maturity most entities lack. |
 | EU AI Act (Regulation 2024/1689) | Art. 73 — serious incident reporting (high-risk AI systems) | High-risk AI providers must report serious incidents to market surveillance authorities within 15 days; 2 days for "widespread infringement" or breaches of fundamental rights. | Clock is longer than CRA/NIS2/DORA but the determination ("serious incident" in an AI system) is novel. Overlap with CRA Art. 11 unresolved — same event may trigger both. |
@@ -122,10 +123,10 @@ This skill is response-shaped — the TTPs below name the incident classes the p
 |---|---|---|---|---|
 | **T1486** | Data Encrypted for Impact | Ransomware | Identification: EDR file-encryption telemetry, share-mass-write pattern. Containment: network-segment isolation, identity revocation. Eradication: backup-validation-before-restore. Recovery: validated-restore + service-level verification. Lessons: feed to `zeroday-gap-learn` if initial access was a known CVE. | Detection coverage strong; identity-rotation maturity weak. NYDFS 24h ransom-payment clock and OFAC sanctions screening intersect at decision-to-pay. |
 | **T1041** | Exfiltration Over C2 Channel | Data exfiltration via established C2 | Identification: DLP egress, anomalous outbound bandwidth, beaconing patterns. Containment: egress filtering, certificate-pinned proxy. Eradication: C2 artifact removal. Recovery: identity + secrets rotation. Lessons: detection-engineering gap analysis. | EDR coverage variable; encrypted exfiltration to legitimate services (Box, OneDrive, S3) often missed by signature-based DLP. |
-| **T1567** | Exfiltration Over Web Service | Exfiltration via legitimate web/SaaS services including AI-API | Identification: web-egress to anomalous services or anomalous-volume to legitimate services; for AI-API channel pair with `ai-c2-detection`. Containment: egress block of identified channel, AI-API key revocation, MCP-server scope reduction. Eradication: identify exfiltrated dataset, follow data-incident sub-playbook. Recovery: re-key + re-issue access. | AI-API exfiltration (sub-technique T1567.<sub-technique-id> pattern; ATLAS overlap with AML.T0017) typically blends with legitimate traffic — see `ai-c2-detection` for content-layer detection. |
+| **T1567** | Exfiltration Over Web Service | Exfiltration via legitimate web/SaaS services including AI-API | Identification: web-egress to anomalous services or anomalous-volume to legitimate services; for AI-API channel pair with `ai-c2-detection`. Containment: egress block of identified channel, AI-API key revocation, MCP-server scope reduction. Eradication: identify exfiltrated dataset, follow data-incident sub-playbook. Recovery: re-key + re-issue access. | AI-API exfiltration (sub-technique T1567.<sub-technique-id> pattern; ATLAS overlap with AML.T0024) typically blends with legitimate traffic — see `ai-c2-detection` for content-layer detection. |
 | **T1078** | Valid Accounts | Identity compromise as initial access | Identification: anomalous-sign-in UEBA, impossible-travel, MFA-fatigue patterns. Containment: account disable + session revocation + re-authentication for affected blast radius. Eradication: credential rotation, token revocation, OAuth-grant audit, AI-agent service-account rotation. Recovery: re-issue under zero-trust posture. Lessons: identity-control gap analysis. | Dominant initial-access vector mid-2026; coverage strong for human accounts, weak for AI-agent / service-account / OAuth-app identities. |
-| **AML.T0096** | LLM API as C2 | AI-API as command-and-control channel (SesameOp pattern) | Identification: see `ai-c2-detection` skill — content-layer detection at the AI API egress boundary, prompt-and-response correlation, anomalous AI-API usage shape. Containment: AI-API egress block or proxy-mediated allowlist. Eradication: identify the agent or workload abusing the channel. Recovery: re-issue AI-API keys under scoped least-privilege. | Detection coverage near-absent in legacy SOC stacks; the AI traffic shape is novel and signatures do not exist for most enterprise SIEMs. |
-| **AML.T0017** | Discover ML Model Ontology | Adversary mapping of deployed model family, system-prompt structure, guardrails, and training-data signal — precursor to extraction and adversarial-input crafting | Identification: anomalous inference-API usage patterns (high-volume queries, structured probing, membership-inference signatures, repeated training-data extraction prompts). Containment: rate-limit + API-key revocation + IP block. Eradication: identify attacker access surface; assess what model-ontology data was exposed. Recovery: re-key, consider model-rotation if proprietary weights are at risk; for training-data exfiltration consider differential-privacy retraining. | No standardized detection signatures; org must build custom telemetry over AI inference APIs. |
+| **AML.T0096** | AI Service API (LLM API as C2) | AI-API as command-and-control channel (SesameOp pattern) | Identification: see `ai-c2-detection` skill — content-layer detection at the AI API egress boundary, prompt-and-response correlation, anomalous AI-API usage shape. Containment: AI-API egress block or proxy-mediated allowlist. Eradication: identify the agent or workload abusing the channel. Recovery: re-issue AI-API keys under scoped least-privilege. | Detection coverage near-absent in legacy SOC stacks; the AI traffic shape is novel and signatures do not exist for most enterprise SIEMs. |
+| **AML.T0013** | Discover AI Model Ontology | Adversary mapping of deployed model family, system-prompt structure, guardrails, and training-data signal — precursor to extraction and adversarial-input crafting | Identification: anomalous inference-API usage patterns (high-volume queries, structured probing, membership-inference signatures, repeated training-data extraction prompts). Containment: rate-limit + API-key revocation + IP block. Eradication: identify attacker access surface; assess what model-ontology data was exposed. Recovery: re-key, consider model-rotation if proprietary weights are at risk; for training-data exfiltration consider differential-privacy retraining. | No standardized detection signatures; org must build custom telemetry over AI inference APIs. |
 | **AML.T0051** | LLM Prompt Injection | Prompt-injection breach as incident trigger | Identification: AI-assistant or agentic-system anomalous action (unauthorized data access, anomalous tool invocation, identity-context confusion). Containment: revoke AI-system tool scopes, disable agent autonomy, isolate affected RAG corpus. Eradication: identify injection vector (web content, email signature, document metadata, RAG corpus poisoning) and remove. Recovery: re-deploy with hardened system prompt + tool-scoping per `mcp-agent-trust`. | Detection lags; most orgs discover the incident from downstream effect (unauthorized action) rather than detection at the prompt boundary. |
 
 ATLAS pinned to v2026.09 (September 2026). ATT&CK pinned to v19.2 (August 2026); the Defense Evasion (TA0005) split into Stealth (TA0005) and Defense Impairment (TA0112) is traced via `tactic_moved_from` on affected `data/attack-techniques.json` entries and does not introduce breaking changes for the T-IDs cited above.
@@ -144,7 +145,7 @@ For IR, "exploit availability" is the question of which incident exemplars are o
 | SolarWinds Sunburst | 2020 | Supply-chain compromise (vendor-shipped malware) | T1195.002, T1041 | Detection capability significantly improved post-incident; SBOM/SLSA adoption | Supply-chain-incident playbook hand-off to `supply-chain-integrity` for VEX response. |
 | Volt Typhoon / Salt Typhoon (telecom) | 2023-2024 | Nation-state telecom infrastructure compromise (CCP-attributed by USG) | T1078, T1133, T1556 | Improved post-CISA advisories; living-off-the-land patterns hard to detect | Telecom-sector playbook + national-security coordination. |
 | Microsoft Midnight Blizzard | 2024 | Nation-state cloud-tenant compromise via legacy test tenant | T1078 (password spray on legacy account) | Strong for password-spray; weak for legacy-tenant inventory | Identity-hygiene playbook requires legacy-account inventory and decommissioning audit. |
-| Anthropic / OpenAI / Microsoft AI bug bounty disclosures (multiple, 2024-2026) | 2024-2026 | Prompt-injection class, jailbreak class, training-data extraction | AML.T0051, AML.T0017 | Detection coverage near-absent in customer SOCs; vendors handle in serving infrastructure | AI-class incident playbook required; the customer-side IR playbook for AI-system anomalies is the gap. |
+| Anthropic / OpenAI / Microsoft AI bug bounty disclosures (multiple, 2024-2026) | 2024-2026 | Prompt-injection class, jailbreak class, training-data extraction | AML.T0051, AML.T0024 | Detection coverage near-absent in customer SOCs; vendors handle in serving infrastructure | AI-class incident playbook required; the customer-side IR playbook for AI-system anomalies is the gap. |
 | Public agentic-system unauthorized-action incidents (research disclosures + named enterprise cases 2024-2026) | 2024-2026 | AI-agent-initiated unauthorized action via indirect prompt injection | AML.T0051 → unauthorized T-action | Detection at the agent-tool boundary, not the prompt boundary | Hand-off to `mcp-agent-trust` for tool-scope hardening; playbook covers agent-disable + scope-revoke + log-replay. |
 
 Detection-tool maturity (mid-2026):
@@ -162,7 +163,7 @@ Before stepping through the IR program assessment, thread the three foundational
 
 **Defense in depth — IR as a multi-layer pipeline.** A real IR program is not the playbook document; it is the stack that produces the conditions for the playbook to fire and the conditions for it to succeed:
 - **Layer 1 — Preparation.** Playbook library (by ATT&CK technique + incident class + sector + jurisdiction), tabletop exercises (at least quarterly, scenarios drawn from current threat-intel feed), runbook tooling (SOAR + ticketing + comms), redundant logging (SIEM + DLP + identity + EDR + AI-system telemetry shipped to immutable store), legal and PR alignment, executive and board awareness, retainer with external IR firm.
-- **Layer 2 — Identification.** SIEM correlation rules mapped to ATT&CK; EDR / XDR on every endpoint and workload; UEBA for identity-anomaly detection; AI-incident detectors per `ai-c2-detection` for AML.T0096 / AML.T0017 / AML.T0051; threat-intel feed integration; honeypot / canary telemetry.
+- **Layer 2 — Identification.** SIEM correlation rules mapped to ATT&CK; EDR / XDR on every endpoint and workload; UEBA for identity-anomaly detection; AI-incident detectors per `ai-c2-detection` for AML.T0096 / AML.T0024 / AML.T0051; threat-intel feed integration; honeypot / canary telemetry.
 - **Layer 3 — Containment.** Network-segment isolation capability (SDN, microsegmentation, firewall policy push); identity revocation capability (Conditional Access, OAuth-grant revocation, service-account rotation); endpoint isolation (EDR-driven network quarantine); AI-API egress block; cloud-workload pause/snapshot.
 - **Layer 4 — Eradication and recovery.** Artifact removal (file, registry, scheduled task, persistence mechanism); credential rotation at scope (privileged, service, AI-agent, OAuth app, API key); validated backup restore; AI-system rollback (model version, system prompt, RAG corpus state); service-level verification before declaring recovery.
 - **Layer 5 — Lessons learned.** Post-incident review (root-cause analysis using the Diamond Model and the Unified Kill Chain for adversary-narrative reconstruction); playbook update; detection-engineering refinement; control-gap filing per `framework-gap-analysis`; zero-day learning per `zeroday-gap-learn`; threat-model refresh per `threat-model-currency`; skill-update propagation per `skill-update-loop`.
@@ -181,7 +182,7 @@ Before any incident fires, audit detection coverage against the ATT&CK + ATLAS t
 - Map each playbook in the library to one or more ATT&CK / ATLAS techniques.
 - For each technique, identify the detection rule, the log source, the false-positive baseline, and the tested-fire status.
 - Identify coverage gaps: techniques with no rule, rules with no log source, rules with no recent test fire.
-- Specifically audit AI-class detection: AML.T0096 (AI-API egress shape — hand off to `ai-c2-detection`), AML.T0017 (anomalous inference-API usage), AML.T0051 (downstream-action anomaly).
+- Specifically audit AI-class detection: AML.T0096 (AI-API egress shape — hand off to `ai-c2-detection`), AML.T0024 (anomalous inference-API usage), AML.T0051 (downstream-action anomaly).
 - Specifically audit identity detection: T1078 sub-technique coverage (cloud accounts, default accounts, domain accounts, local accounts) and service-account / AI-agent variants.
 
 ### Step 2 — Incident classification taxonomy (the "what is this" check)
@@ -192,7 +193,7 @@ When an incident fires, classify before responding. Classification dimensions:
 - **Incident class** — ransomware, data exfiltration, identity compromise, supply-chain, AI-system breach, business-email-compromise, DoS, insider, other.
 - **Impact severity** — confidentiality / integrity / availability per the org's incident-severity matrix.
 - **Jurisdictional notification clock** — per the matrix in Section 7. Which clocks start, when did they start (awareness moment), who is the named officer per clock.
-- **AI-class flag** — does the incident involve an AI system as victim, vector, or attacker? AI-as-victim: AML.T0051/AML.T0017. AI-as-vector: AML.T0096. AI-as-attacker: agent-initiated unauthorized action.
+- **AI-class flag** — does the incident involve an AI system as victim, vector, or attacker? AI-as-victim: AML.T0051/AML.T0024. AI-as-vector: AML.T0096. AI-as-attacker: agent-initiated unauthorized action.
 - **Sector flag** — does a sectoral framework apply (`sector-healthcare`, `sector-financial`, `sector-energy`, `sector-federal-government`)?
 
 ### Step 3 — Declaration and runbook activation
@@ -211,7 +212,7 @@ Apply containment matching the class. Common patterns:
 - **Data exfiltration (T1041 / T1567)**: egress block at the identified channel; certificate-pinned proxy enforcement; identify what was exfiltrated (scope determination drives notification scope).
 - **Identity compromise (T1078)**: account disable, session revocation, MFA re-enrollment, OAuth-grant audit; for service / AI-agent accounts, scope-reduce + rotate.
 - **AI-API C2 (AML.T0096)**: AI-API egress block or proxy-mediated allowlist; identify the workload abusing the channel; AI-API key revocation.
-- **Model ontology discovery (AML.T0017)**: rate-limit the inference API; revoke the abusing API key; IP-block as supplemental; assess what model-ontology data (system prompt, guardrail surface, model family signal) was exposed and tighten the inference-API rate + shape baseline before re-issue.
+- **Model ontology discovery (AML.T0013)**: rate-limit the inference API; revoke the abusing API key; IP-block as supplemental; assess what model-ontology data (system prompt, guardrail surface, model family signal) was exposed and tighten the inference-API rate + shape baseline before re-issue.
 - **Prompt-injection breach (AML.T0051)**: disable the affected agent autonomy or revoke its tool scopes; isolate the RAG corpus suspected as injection vector; capture the injected content for forensics.
 - **Supply-chain (T1195)**: identify affected component versions via SBOM; coordinate with vendor (hand off to `coordinated-vuln-disclosure` reverse-direction — receiving vendor advisory); VEX-driven inventory of affected workloads.
 
@@ -326,7 +327,7 @@ runbooks/
     ...
   by-atlas-technique/
     AML-T0051-prompt-injection.md
-    AML-T0017-model-exfiltration.md
+    AML-T0024-model-exfiltration.md
     AML-T0096-llm-api-c2.md
     ...
   by-incident-class/
@@ -500,7 +501,7 @@ Four concrete tests distinguish a real IR program from IR theater. Run them in o
 
 > **Test 2 — Walk me through your EU DORA 4-hour initial-notification process, named officer included.** Substitute the tightest jurisdictional clock that applies to the org (DORA 4h for in-scope financial entities; SG CSA CCoP2.0 2h for SG CII; NERC CIP-008 1h for North American electric utilities; CERT-In 6h for India-operating entities; AU SOCI 12h; CRA Art. 11 24h for EU manufacturers). If the answer is "we'll figure it out when it happens" or "legal will handle it," the program will miss the clock during a real incident. The named officer must be identifiable, reachable on a documented out-of-band channel, and trained on the determination criteria for the relevant "significance" or "major" or "actively exploited" thresholds. If the org cannot produce the named officer's contact card and the decision tree they will use at 03:00 on a Saturday, the regulator-notification capability is theater.
 
-> **Test 3 — Do you have an AI-class incident playbook, and when was it last exercised?** Three failure modes signal theater: (a) "AI is just IT — we use our normal playbook" — the org has not engaged with AML.T0096 / AML.T0017 / AML.T0051 detection and containment specifics; (b) "we don't run AI systems" — verify against actual product surface (Copilot, Claude, ChatGPT, Gemini, AI features embedded in SaaS, internal agentic systems, RAG features); (c) "we have a draft playbook but never tested it" — untested AI-class playbooks fail at the same rate as untested conventional playbooks, but the failure modes are unfamiliar to the SOC. Particular smell: the AI-class playbook exists in the security team's shared drive but the AI-platform team and the data-science team have never seen it. AI-incident response requires cross-team rehearsal; AML.T0017 forensics requires data-science skills the SOC does not have.
+> **Test 3 — Do you have an AI-class incident playbook, and when was it last exercised?** Three failure modes signal theater: (a) "AI is just IT — we use our normal playbook" — the org has not engaged with AML.T0096 / AML.T0024 / AML.T0051 detection and containment specifics; (b) "we don't run AI systems" — verify against actual product surface (Copilot, Claude, ChatGPT, Gemini, AI features embedded in SaaS, internal agentic systems, RAG features); (c) "we have a draft playbook but never tested it" — untested AI-class playbooks fail at the same rate as untested conventional playbooks, but the failure modes are unfamiliar to the SOC. Particular smell: the AI-class playbook exists in the security team's shared drive but the AI-platform team and the data-science team have never seen it. AI-incident response requires cross-team rehearsal; AML.T0024 forensics requires data-science skills the SOC does not have.
 
 > **Test 4 — Enumerate every jurisdictional notification clock that applies to your operations, name the officer for each, and produce the last drill record per clock.** If the org cannot enumerate clocks — clocks are discovered mid-incident, while running them late — the program will miss at least one in a real cross-jurisdictional event. The minimum enumeration for a multinational organization: EU (CRA Art. 11 + NIS2 Art. 23 + DORA Art. 19 if financial + AI Act Art. 73 if high-risk AI), UK (NIS + UK GDPR), AU (SOCI), JP (NISC + APPI), IL (INCD + PPA), SG (CSA CCoP2.0 + PDPC), IN (CERT-In), BR (LGPD), CN (MLPS + CSL + DSL + PIPL), US-NYDFS, US-HIPAA (if in scope), US-NERC (if in scope), AE (TDRA + DIFC DP). For each: clock, authority, channel, named officer, last drill. If the clocks live in a regulatory-comms team's binder rather than the IR runbook library, the program will run them out of sequence with the technical response and burn one of them.
 
@@ -518,10 +519,10 @@ IR consumes defensive controls across multiple D3FEND categories; the four cited
 |---|---|---|---|---|---|
 | **D3-RPA** (Remote Process Analysis) | Forensic acquisition during containment and eradication. Memory, syscall trace, container layer diff acquired from compromised hosts and from suspected-but-not-confirmed lateral-spread hosts. For ephemeral compute, applies to the immutable telemetry pipeline that captured the process state before workload termination. | Containment / Eradication layer. The acquisition runs *before* destructive containment so the post-incident review has evidence. | Forensic-acquisition tooling scoped to a sealed workstation set; chain-of-custody log restricts access to named incident-handler roles. | Treat the host as adversarial — its self-reported state cannot be trusted; rely on independent telemetry capture. | Applies — AI-system process analysis includes inference-runtime telemetry (prompt logs, response logs, tool-invocation logs), agent process trees, and MCP-server interaction logs. The AI-pipeline equivalent of memory capture is the prompt-and-response state at the incident time. |
 | **D3-NTA** (Network Traffic Analysis) | Egress detection during identification; lateral-movement detection during containment; post-incident hunt for residual adversary infrastructure. For data-exfiltration incidents (T1041 / T1567), NTA is the primary identification surface. For AI-API C2 (AML.T0096) NTA alone is insufficient because the egress is to legitimate AI provider domains — pair with D3-CSPP for content-layer detection. | Identification layer (primary) and Containment / Eradication layer (residual). | NTA scoped to the IR analyst role; full-take capture is sealed and accessed under chain-of-custody for evidentiary use. | Default-suspect for unexpected egress patterns; verify per session against the baseline rather than trusting prior allowlist. | Partial — AI-API egress traffic shape is novel and most NTA stacks do not have signatures for AML.T0096. Pair with `ai-c2-detection` skill recommendations. |
-| **D3-IOPR** (Input/Output Profiling) | AI-API egress correlation and SaaS-egress anomaly detection. For AI-system incidents, profiling the input (prompt) and output (response) distribution is the defensive surface that can detect AML.T0051 (anomalous prompt patterns), AML.T0017 (extraction-pattern queries), and AML.T0096 (C2-channel encoded payloads). | Identification layer (primary for AI-system incidents). | Scoped to the AI-incident specialist role; raw prompts and responses may contain confidential data and must be access-controlled per data-classification policy. | Default-suspect for prompt distributions outside the baseline; do not whitelist by source identity alone — verify per request. | High applicability — D3-IOPR is the highest-leverage D3FEND technique for AI-system incident detection and is the operational complement to D3-NTA when the egress is to a legitimate AI provider. |
+| **D3-IOPR** (Input/Output Profiling) | AI-API egress correlation and SaaS-egress anomaly detection. For AI-system incidents, profiling the input (prompt) and output (response) distribution is the defensive surface that can detect AML.T0051 (anomalous prompt patterns), AML.T0024 (extraction-pattern queries), and AML.T0096 (C2-channel encoded payloads). | Identification layer (primary for AI-system incidents). | Scoped to the AI-incident specialist role; raw prompts and responses may contain confidential data and must be access-controlled per data-classification policy. | Default-suspect for prompt distributions outside the baseline; do not whitelist by source identity alone — verify per request. | High applicability — D3-IOPR is the highest-leverage D3FEND technique for AI-system incident detection and is the operational complement to D3-NTA when the egress is to a legitimate AI provider. |
 | **D3-CSPP** (Client-Server Payload Profiling) | C2 protocol detection during identification; AI-API content-layer detection for AML.T0096. Where the C2 channel is HTTPS to a legitimate service (Box, OneDrive, S3, AI provider), CSPP is the content-shape detection surface that catches the abuse pattern. | Identification layer. | Scoped to the detection-engineering and IR analyst roles; payload-content access controlled. | Default-suspect for novel payload shapes against baseline; verify-not-assume that previously-good clients have not been compromised. | Applies — particularly for AI-API C2 detection where TLS termination at an enterprise proxy enables payload-shape analysis of prompts and responses. |
 
-**No orphaned controls**: each D3FEND technique above maps to one or more incident classes in the TTP Mapping section (T1486 / T1041 / T1567 / T1078, AML.T0096 / AML.T0017 / AML.T0051). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during IR.
+**No orphaned controls**: each D3FEND technique above maps to one or more incident classes in the TTP Mapping section (T1486 / T1041 / T1567 / T1078, AML.T0096 / AML.T0024 / AML.T0051). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during IR.
 
 **AI-pipeline statement**: D3FEND coverage of AI-incident defense is concentrated in D3-IOPR (input/output profiling) and the content-layer subset of D3-CSPP. The ephemeral-compute evidence-preservation problem is largely outside the D3FEND ontology as of mid-2026; the operational fix (continuous forensic-grade telemetry shipping to immutable store) is documented in `attack-surface-pentest` and `defensive-countermeasure-mapping` as a control gap pending ontology coverage.
 
@@ -536,7 +537,7 @@ IR sits downstream of detection and upstream of organizational learning. Route t
 - **`threat-model-currency`** — *downstream refresh trigger.* An incident is the strongest real-world signal that the threat model may be stale; trigger the currency refresh routine.
 - **`compliance-theater`** — *paper-IR detection.* The four compliance theater tests in this skill compose with the broader theater detection across frameworks; run `compliance-theater` after this skill when the org is claiming SOC 2 / ISO 27001 / NIST CSF / HIPAA maturity that the IR test results contradict.
 - **`framework-gap-analysis`** — *control-gap filing.* When an incident exposes that an existing control was insufficient to detect, prevent, or contain, file the gap under the appropriate framework entry per `data/framework-control-gaps.json`.
-- **`dlp-gap-analysis`** — *data exfiltration incident class.* T1041 / T1567 / AML.T0017 incidents hand off to DLP gap analysis for the egress-control assessment.
+- **`dlp-gap-analysis`** — *data exfiltration incident class.* T1041 / T1567 / AML.T0024 incidents hand off to DLP gap analysis for the egress-control assessment.
 - **`ai-c2-detection`** — *AML.T0096 incident trigger.* AI-API as C2 channel detection feeds IR identification; this skill consumes those detections.
 - **`ai-attack-surface`**, **`rag-pipeline-security`**, **`mcp-agent-trust`** — *AI-class incident depth.* AML.T0051 and AI-agent-initiated unauthorized action route through these skills for vector identification and containment depth.
 - **`defensive-countermeasure-mapping`** — *full D3FEND cross-walk* beyond the four IDs cited in the Defensive Countermeasure Mapping section above.

package/skills/kernel-lpe-triage/skill.md

@@ -178,7 +178,7 @@ Note: ATLAS refs are intentionally empty in frontmatter — these are Linux kern
 
 Run this check for any org claiming patch-management compliance for kernel LPE class CVEs:
 
-> "Your patch-management control (NIST SI-2 / ISO 27001:2022 A.8.8 / PCI-DSS v4 6.3.3 / NIS2 Art. 21(2)(g) / UK-CAF B4 / AU-ISM-1493) documents a 30-day remediation window for Critical/High CVEs. CVE-2026-31431 (Copy Fail) is CISA KEV listed with a public deterministic exploit requiring no privileges and KEV listing dated 2026-05-01. What is the actual time, on this fleet, between KEV listing and confirmed patch-or-mitigate for the affected kernel versions? If that interval exceeds 72 hours without live-patching as a deployed capability for the affected hosts, the patch-management control is theater for the KEV-class kernel-LPE threat surface."
+> "Your patch-management control (NIST SI-2 / ISO 27001:2022 A.8.8 / PCI-DSS v4 6.3.3 / NIS2 Art. 21(2)(g) / UK-CAF B4 / AU ISM-1695) documents a 30-day remediation window for Critical/High CVEs. CVE-2026-31431 (Copy Fail) is CISA KEV listed with a public deterministic exploit requiring no privileges and KEV listing dated 2026-05-01. What is the actual time, on this fleet, between KEV listing and confirmed patch-or-mitigate for the affected kernel versions? If that interval exceeds 72 hours without live-patching as a deployed capability for the affected hosts, the patch-management control is theater for the KEV-class kernel-LPE threat surface."
 
 **Theater fingerprints (any of these reduces the control to paper compliance):**
 

package/skills/log-injection-telemetry/skill.md

@@ -36,7 +36,7 @@ framework_gaps:
   - ISO-27001-2022-A.8.15
   - NIS2-Art21-network-security
   - UK-CAF-B4
-  - AU-ISM-1556
+  - AU-ISM-1815
 cwe_refs:
   - CWE-117
   - CWE-532

package/skills/mcp-agent-trust/skill.md

@@ -21,7 +21,8 @@ data_deps:
   - rfc-references.json
 atlas_refs:
   - AML.T0010
-  - AML.T0016
+  - AML.T0053
+  - AML.T0086
   - AML.T0096
 attack_refs:
   - T1195.001
@@ -150,7 +151,7 @@ Every MCP server listed in popular registries (MCP Hub, npm `@modelcontextprotoc
 | UK NCSC CAF | Principle A4 (Supply Chain), B4 (System Security), B2 (Identity and Access Control) | Outcome-based language. NCSC's 2024 guidance on securing AI systems names supply-chain integrity for AI tooling, but the CAF outcome statements are unchanged — an organisation can achieve A4 / B4 outcomes at Achieved level with zero MCP server allowlisting, no signature verification, and no per-server authentication. |
 | UK DSIT AI Cyber Code of Practice (2025) | Principle 7 (secure software supply chain) + Principle 8 (secure development) | Names supply-chain integrity for AI development but as a principle, not a testable control. No technical floor for MCP signing, allowlisting, or per-server auth. |
 | AU ASD Essential 8 | Strategy: Application Control + Restrict Administrative Privileges | Application Control (allowlisting) is the closest existing strategy to MCP allowlisting but is scoped to operating-system-level executables. MCP servers run as long-lived child processes spawned by the AI assistant's process — Application Control rarely reaches the npm/pip-installed JavaScript or Python that constitutes an MCP server. None of the eight strategies address agent-mediated tool execution. |
-| AU ASD ISM | ISM-1728 (managing cyber supply chain risk) + ISM-1808 (cloud consumer responsibilities) + ISM-0935 (application control) | ISM-1728 supply-chain language is scoped to traditional vendor classes; MCP servers fall outside enumerated supply-chain categories. ISM-0935 application control is operating-system-level and does not reach package-level MCP servers. |
+| AU ASD ISM | ISM-2156 and ISM-2157 (agentic AI restricted to minimum tools; each tool call authorized for the user and the task) + ISM-2159 (tool invocations centrally logged) + ISM-1452 (supply chain risk assessment) + ISM-1657 (application control) | ISM-2156 and ISM-2157 cover what an agent may call, but neither covers where an MCP server came from: ISM-1452 assesses suppliers, not individual packages pulled from a registry, and ISM-1657 application control restricts executables and scripts on the host rather than the tool definitions an MCP server advertises to the agent. |
 | AU APRA CPS 234 / CPS 230 | Para 27 (information security capability) + CPS 230 ICT-service-provider obligations | "Capability commensurate with vulnerabilities and threats" language. APRA-regulated entities deploying AI coding assistants meet CPS 234 attestation with traditional vendor-management capability; MCP-specific supply-chain capability is not an examined control. CPS 230 (effective 2025-07-01) third-party-arrangements obligations do not enumerate MCP servers as in-scope material service providers. |
 
 **Fundamental gap:** No current framework has a control category for "AI tool trust boundaries" — the concept that an AI model can be the authorization mechanism for code execution, and that this creates a new class of supply chain and access control risk.
@@ -165,7 +166,7 @@ Every MCP server listed in popular registries (MCP Hub, npm `@modelcontextprotoc
 |---|---|---|---|
 | AML.T0010 | AI Supply Chain Compromise | Direct: malicious MCP server in public registry compromises AI assistant's tool execution | ATLAS covers this conceptually; no framework has a technical control |
 | AML.T0054 | LLM Jailbreak | Indirect: adversarial prompt in tool response bypasses guardrails and triggers AI to call next malicious action | No framework control |
-| AML.T0096 | LLM Integration Abuse | AI assistant is the integration point being abused — MCP tool calls are the mechanism | Not in ATT&CK; only in ATLAS v2026.09 |
+| AML.T0053 | AI Agent Tool Invocation | AI assistant is the integration point being abused — MCP tool calls are the mechanism | Not in ATT&CK; only in ATLAS v2026.09 |
 | T1195.001 | Supply Chain Compromise: Compromise Software Dependencies | MCP server package as supply chain attack target | ATT&CK covers but enterprise controls don't reach developer MCP configs |
 | T1059 | Command and Script Interpreter | MCP server causes shell command execution via model-mediated tool call | Standard SI-3/EDR doesn't attribute this to the MCP server as origin |
 | T1190 | Exploit Public-Facing Application | CVE-2026-30615: MCP client vulnerability driven by a locally-installed malicious server (AV:L) | Standard vuln management covers client; MCP server trust is unaddressed |
@@ -359,7 +360,7 @@ D3FEND v1.3.0+ references from `data/d3fend-catalog.json`. MCP trust failures la
 |---|---|---|---|
 | `D3-EHB` | Executable Hash-based Allowlist | Host / MCP server registration | Pins each MCP server binary by hash so CVE-2026-30615-class supply-chain swaps (compromised `npx` package replaces the server with an exploit variant) cannot replace the trusted binary silently. Direct counter to AML.T0010 + T1195.001. |
 | `D3-EAL` | Executable Allowlisting | Host / shell-capable tool | Restricts which executables an MCP shell-tool or process-exec-capable server can spawn. Without this, a server with `bash`/`pwsh` tools is a shell on the developer workstation with the developer's authority. |
-| `D3-CAA` | Credential Access Auditing | Identity / MCP bearer-auth | Logs every MCP server's use of the bearer token / OAuth credential and the resources it touched. The audit anchor for AML.T0016 (model and credential exfiltration via tool calls); the only post-hoc evidence stream when an MCP server is trusted but malicious. |
+| `D3-CAA` | Credential Access Auditing | Identity / MCP bearer-auth | Logs every MCP server's use of the bearer token / OAuth credential and the resources it touched. The audit anchor for AML.T0086 (model and credential exfiltration via tool calls); the only post-hoc evidence stream when an MCP server is trusted but malicious. |
 | `D3-CSPP` | Client-server Payload Profiling | MCP gateway | Gateway-layer inspection of MCP tool-call args and tool-result bodies. The single control that can detect indirect prompt-injection payloads landing in `tools/call` results, AML.T0051 patterns reaching the assistant through document fetches, and AML.T0096 covert C2 over MCP transport. |
 | `D3-CBAN` | Certificate Analysis | Transport / MCP server-side | Validates the MCP server's TLS certificate chain and binds it to a pinned identity registered in the host's MCP catalog. Counters the "stand-up a malicious MCP server with a Let's Encrypt cert pretending to be a sanctioned vendor" pattern. |
 | `D3-MFA` | Multi-factor Authentication | Identity / OAuth client registration | Required for MCP servers registered as OAuth clients against enterprise IdPs. Without phishing-resistant MFA on the registration flow, a compromised developer credential can register an attacker-controlled MCP server inside the org's trust boundary. |

package/skills/mlops-security/skill.md

@@ -30,7 +30,7 @@ atlas_refs:
   - AML.T0018
   - AML.T0020
   - AML.T0043
-  - AML.T0017
+  - AML.T0013
 attack_refs:
   - T1195.001
   - T1565
@@ -119,7 +119,7 @@ Descriptions sourced from `data/atlas-ttps.json` (ATLAS v2026.09, released 2026-
 | AML.T0018 | Manipulate AI Model (sub-techniques: Poison Training Data, Trojan Model via direct weight manipulation, Federated Learning Poisoning) | Training pipeline and post-training tampering — adversary modifies weights either through poisoned training data persisted into weights or through direct binary edit of an unsigned checkpoint | No framework requires model-weight signature verification at registry write and at deployment read; CWE-502 deserialization risk on `.pt` / `SavedModel` is unmapped to compliance control |
 | AML.T0020 | Poison Training Data (sub-techniques: Inject at Scale, Craft Targeted, RAG Knowledge Base Poisoning) | Data ingestion → feature store → training. Adversary contaminates training corpus to embed targeted misbehavior. ATLAS carries this as a single technique with no sub-techniques; the RAG-corpus variant is covered in `rag-pipeline-security`, the training-pipeline variant here. | No framework requires training-data lineage attestation, source signing, or poisoning-detection scanning at ingestion. EU AI Act Art. 10 requires data-governance documentation but not cryptographic attestation. |
 | AML.T0043 | Craft Adversarial Data (White-Box, Black-Box, Physical) | Inference serving and feedback loop — adversary crafts inputs to either cause misclassification at inference time or to poison the feedback corpus when feedback is logged for retraining | No framework requires adversarial-robustness testing for deployed models or adversarial-input detection at the serving layer; AI RMF MEASURE-2.5 recommends but does not require |
-| AML.T0017 | Discover ML Model Ontology (Probe, Extract System Prompt, Map Filters) | Model registry exposure — adversary maps deployed model family, extracts metadata, infers training corpus, harvests prompts and guardrails | No framework requires model-registry RBAC at the granularity needed (per-project read scoping, signed registry queries, audit of model-extraction-pattern queries) |
+| AML.T0013 | Discover AI Model Ontology (probing, system prompt extraction, filter mapping) | Model registry exposure — adversary maps deployed model family, extracts metadata, infers training corpus, harvests prompts and guardrails | No framework requires model-registry RBAC at the granularity needed (per-project read scoping, signed registry queries, audit of model-extraction-pattern queries) |
 | T1195.001 | Supply Chain Compromise: Software Dependencies and Development Tools | Training pipeline dependency chain — Python wheels, CUDA drivers, ML framework versions, notebook kernels | SCA detects known-vulnerable; XZ-class novel compromise is not detectable without SLSA L3 + reproducible builds for the training environment |
 | T1565 | Data Manipulation (Stored, Transmitted, Runtime) | Cross-cuts every MLOps stage — manipulation of stored training data, transmitted features to inference, or runtime model state | SI-7 maps to traditional file/firmware integrity; extending to feature-store payload integrity and embedding-space integrity is not in current control |
 
@@ -150,7 +150,7 @@ Sourced from `data/cve-catalog.json`, public incident history, and `data/atlas-t
 **Tool maturity for defenders (mid-2026 baseline):**
 
 - **ProtectAI ModelScan** (open source) — static analysis on model artifacts for unsafe deserialization patterns; production-ready for `.pt`, `.h5`, ONNX, GGUF surface checks.
-- **Garak** (open source) — LLM red-team probing framework; useful for AML.T0017 and AML.T0043 coverage on deployed LLMs.
+- **Garak** (open source) — LLM red-team probing framework; useful for AML.T0013 and AML.T0043 coverage on deployed LLMs.
 - **CleverHans** (open source) — adversarial-input library; production use for AML.T0043 robustness testing.
 - **Hugging Face model scanner** — first-party scanning on uploaded artifacts; surface-level deserialization and known-malicious detection.
 - **Sigstore cosign + OpenSSF model-signing** — production signing for model weights via OCI registries.
@@ -219,7 +219,7 @@ Every artifact is untrusted until cryptographically verified.
    - **Semantic drift** — concept drift in input meaning; embedding-distribution shift over time; D3-IOPR-style profiling of input/output payloads.
    - **Cadence** — daily statistical, weekly semantic, alert on threshold breach. Quarterly drift review is not sufficient — that is miss-the-attacker territory.
 
-9. **Adversarial monitoring.** Input distribution profiling for OOD detection, prediction confidence anomaly detection, query-pattern profiling (D3-IOPR) to surface AML.T0017 (model probing) and AML.T0043 (adversarial inputs). For LLM-serving, integrate Garak-class probing into a continuous red-team loop.
+9. **Adversarial monitoring.** Input distribution profiling for OOD detection, prediction confidence anomaly detection, query-pattern profiling (D3-IOPR) to surface AML.T0013 (model probing) and AML.T0043 (adversarial inputs). For LLM-serving, integrate Garak-class probing into a continuous red-team loop.
 
 10. **Feedback loop integrity.** Every retrain run produces an in-toto attestation. Feedback sources are signed by the collecting service. Statistical detection of feedback distribution shift on a per-source basis. Holdout retraining — feedback is sampled and validated against a labeled baseline before incorporation, not wholesale ingested. Verify that every model in production carries a chain of attestations back to the original training run plus every retrain run since.
 
@@ -304,7 +304,7 @@ D3FEND techniques referenced (see `data/d3fend-catalog.json`). Each is annotated
 
 - **D3-EAL (Executable Allowlisting)** — Runtime restriction of execution to pre-approved executables, extended in the MLOps context to inference-service binary lineage. Closes the loop on training-run signing: even if a tampered training artifact reaches the serving host, D3-EAL on the serving container blocks unauthorized binary execution emerging from a deserialization-RCE in the model artifact. Defense-in-depth layer: runtime inference-service host. Least-privilege scope: serving container has a minimum binary allowlist for the model-serving framework only — no shell, no debugging utilities, no outbound-network utilities. Zero-trust posture: every binary execution is verified against the allowlist regardless of pathway. AI-pipeline applicability: ephemeral serving pods are reprovisioned with the allowlist baked into the immutable image; persistent training runs use a separate, broader allowlist scoped to training-only operations.
 
-- **D3-IOPR (Input/Output Profiling)** — Profiling of input and output payloads at inference services to detect adversarial inputs (AML.T0043) and model-probing patterns (AML.T0017). Defense-in-depth layer: serving-layer pre- and post-inference. Least-privilege scope: profiling service has read-only access to inference traffic at the serving proxy; no model-load privileges, no registry-write privileges. Zero-trust posture: every inference request is profiled regardless of source authentication — authenticated users execute AML.T0043 attacks too. AI-pipeline applicability: serves both ephemeral inference pods (profiling sidecar) and persistent monitoring services (drift-detection pipeline ingesting profiled telemetry).
+- **D3-IOPR (Input/Output Profiling)** — Profiling of input and output payloads at inference services to detect adversarial inputs (AML.T0043) and model-probing patterns (AML.T0013). Defense-in-depth layer: serving-layer pre- and post-inference. Least-privilege scope: profiling service has read-only access to inference traffic at the serving proxy; no model-load privileges, no registry-write privileges. Zero-trust posture: every inference request is profiled regardless of source authentication — authenticated users execute AML.T0043 attacks too. AI-pipeline applicability: serves both ephemeral inference pods (profiling sidecar) and persistent monitoring services (drift-detection pipeline ingesting profiled telemetry).
 
 MLOps stacks span three architectural layers, each requiring an explicit defense story (and each surfacing controls that are architecturally impossible in ephemeral environments):
 

package/skills/multitenancy-isolation/skill.md

@@ -38,7 +38,7 @@ framework_gaps:
   - NIST-800-53-AC-3
   - NIS2-Art21-network-security
   - UK-CAF-B4
-  - AU-ISM-1556
+  - AU-ISM-1268
 cwe_refs:
   - CWE-639
   - CWE-770

package/skills/policy-exception-gen/skill.md

@@ -81,7 +81,7 @@ Per-framework lag statements for each exception category in this skill:
 | UK NCSC CAF | Principle A2 (Risk Management), A4 (Supply Chain), B4 (System Security) | Outcome-based assessment. NCSC Cloud Security Principles and ZT Architecture Design Principles (NCSC 2024) recognize ephemeral and identity-centric architectures, but the CAF outcome statements do not enumerate ZTA / ephemeral / AI-model-update as explicit deviation classes. Exception language must map the operator's compensating-control bundle to the CAF principle's outcome rather than to a prescriptive control. |
 | UK Cyber Essentials Plus | Patch management + Secure Configuration criteria | 14-day patch SLA assumes persistent assets the operator patches. Ephemeral / immutable / provider-patched runtimes (Lambda, Cloud Run, Cloudflare Workers) fall outside the criterion as written. The CE+ assessor expects a documented justification when a service does not fit the standard model. |
 | AU ASD Essential 8 | Patch Applications + Patch Operating Systems + Application Control (ML1-ML3) | Patch-window language assumes a persistent OS / application installation the operator patches. Ephemeral container workloads with immutable images and serverless runtimes break the model. Application Control (allowlisting) does not contemplate AI-coding-assistant tool-use chains where the AI agent dynamically composes the executed action. |
-| AU ASD ISM | ISM-1493 (vulnerability identification and patching) + ISM-1144 (patching frequency) + ISM-1808 (cloud service consumer responsibilities) | ISM-1808 acknowledges cloud shared-responsibility but does not specify exception language for provider-controlled runtimes. ISM-1493 / ISM-1144 patch-frequency controls assume operator-controlled patching. |
+| AU ASD ISM | ISM-1143 (patch management processes) + ISM-1876 and ISM-1877 (48-hour windows) + ISM-1809 (compensating controls for unsupported products) + ISM-1569 (shared responsibility model) | ISM-1809 is the ISM's own exception mechanism, but it covers only products their vendor no longer supports. ISM-1569 assigns responsibilities between supplier and customer without exception language for a provider-controlled runtime, and the patching windows assume the operator applies the patch. |
 | AU APRA CPS 234 | Para 27 (information security capability) + Para 36 (control testing) | "Capability commensurate with vulnerabilities and threats" language. AI-pipeline and ZTA architectures are not enumerated as in-scope capability classes; an APRA-regulated entity must document the architectural deviation explicitly to avoid a control-testing finding. |
 
 This skill's exceptions exist precisely because the framework language has not caught up to the architecture. The exceptions do not claim the threat goes away — they document the compensating controls that handle the residual TTPs (see TTP Mapping).

package/skills/pqc-first/skill.md

@@ -1,7 +1,7 @@
 ---
 name: pqc-first
 version: "1.0.0"
-description: Post-quantum cryptography first mentality — hard version gates, algorithm sunset tracking, loopback learning for NIST/IETF standards evolution
+description: Post-quantum cryptography first mentality — hard version gates (OpenSSL 3.5+), algorithm sunset tracking, HNDL assessment, loopback learning for NIST/IETF standards evolution
 triggers:
   - pqc
   - post-quantum

package/skills/privacy-consent-ops/skill.md

@@ -36,7 +36,7 @@ framework_gaps:
   - NIST-800-53-SI-2
   - NIS2-Art21-network-security
   - UK-CAF-B4
-  - AU-ISM-1556
+  - AU-ISM-1240
 cwe_refs:
   - CWE-807
   - CWE-345

package/skills/rag-pipeline-security/skill.md

@@ -204,7 +204,7 @@ Descriptions sourced verbatim from `data/atlas-ttps.json` (ATLAS v2026.09, relea
 |---|---|---|---|---|---|
 | AML.T0020 — Vector store / RAG knowledge base poisoning | Yes — public research demonstrations and ATLAS-documented production incidents of poisoned-document injection causing redirected retrieval and attacker-controlled outputs | No (technique class, not vendor CVE) | Yes — adversary use of LLMs to craft adversarial-instruction documents at scale (AML.T0016, PROMPTFLUX class) | No vendor patch — mitigation is architectural: signed ingestion, content scanning at ingest, provenance tracking, embedding-space integrity monitoring | Configuration / pipeline change; no version bump applies |
 | AML.T0043 — Embedding-manipulation exfiltration | Yes — published academic demonstrations of crafted queries landing near sensitive-document embeddings; observed in red-team engagements through 2025-2026 | No | Yes — automated query-crafting against an embedding model is itself an AI-accelerated capability | No vendor patch — mitigation is architectural: classification-aware vector namespaces, retrieval audit logging, output exfiltration scanning | Pipeline reconfiguration |
-| AML.T0051 (and AML.T0051.001 — Indirect Prompt Injection) | Yes — extensively demonstrated; CVE-2025-53773 (GitHub Copilot YOLO-mode RCE, CVSS 7.8 / AV:L) is the direct-injection sibling case where prompt content in any agent-readable source coerces `chat.tools.autoApprove: true`; the RAG-indirect variant has equivalent demonstration evidence where the malicious instructions sit in retrieved corpus documents instead | No | Yes — AI tooling crafts injection payloads; AML.T0016 documents adversary AI capability development | No vendor patch for the architectural class — vendor-side patches (GitHub Copilot fix in 2025-08 Patch Tuesday; Visual Studio 2022 17.14.12) close the specific YOLO-mode path; mitigation for the broader RAG-indirect variant is architectural: treat retrieved content as untrusted data, system-prompt authority hierarchy, behavioral monitoring of LLM tool-use following retrieval | Configuration / system-prompt change |
+| AML.T0051 (and AML.T0051.001 — Indirect Prompt Injection) | Yes — extensively demonstrated; CVE-2025-53773 (GitHub Copilot YOLO-mode RCE, CVSS 7.8 / AV:L) is the direct-injection sibling case where prompt content in any agent-readable source coerces `chat.tools.autoApprove: true`; the RAG-indirect variant has equivalent demonstration evidence where the malicious instructions sit in retrieved corpus documents instead | No | Yes — AI tooling crafts injection payloads; AML.T0016 documents adversary use of obtained generative AI capabilities | No vendor patch for the architectural class — vendor-side patches (GitHub Copilot fix in 2025-08 Patch Tuesday; Visual Studio 2022 17.14.12) close the specific YOLO-mode path; mitigation for the broader RAG-indirect variant is architectural: treat retrieved content as untrusted data, system-prompt authority hierarchy, behavioral monitoring of LLM tool-use following retrieval | Configuration / system-prompt change |
 | AML.T0054 — RAG retrieval filter bypass via adversarial query crafting | Yes — public research demonstrations of post-similarity filter application enabling cross-namespace retrieval | No | Yes — query crafting is automatable and accelerated by LLM-assisted prompt synthesis | No vendor patch — mitigation is architectural: pre-similarity filter application, cryptographic namespace enforcement, never construct ACL decisions from query content | Pipeline reconfiguration |
 | T1565 — Data Manipulation (ATT&CK; cross-cuts RAG attack classes) | Yes — extensive public demonstration across the five RAG attack classes | No | Yes — AI accelerates content generation for poisoning at scale | No vendor patch — covered by ATLAS-mapped mitigations above | Pipeline-level controls |
 

package/skills/ransomware-response/skill.md

@@ -103,7 +103,7 @@ The four ransomware-specific decision properties — sanctions screening, decryp
 | SOC 2 | CC7.4 Security incident response; CC9.2 Vendor / business partner risk | Trust services criteria for incident response and vendor risk. | Names response capability; does not require evidence of ransomware-specific decision tree. Vendor criterion does not surface cyber-insurance carrier policy as a control. |
 | HIPAA (45 CFR 164) | 164.308(a)(7) Contingency Plan; 164.400-414 Breach Notification Rule; 164.402 Breach Risk Assessment | Contingency planning for emergencies damaging ePHI; breach-notification triggers and timelines. | Contingency planning is recovery-shaped; treats the encryption event as the trigger. The dominant 2024-2026 ransomware pattern includes PHI exfiltration before encryption, which is a separate Breach Notification Rule trigger that engages the 164.402 risk assessment independently of the encryption event. The Contingency Plan rule does not naturally surface this parallel obligation, and HIPAA Security Rule NPRM late 2024 → final rule expected 2026 is still pending. |
 | AU Essential Eight | Strategy 8 — Regular Backups | Daily backups of important data, software, and configuration with off-network retention. | "Off-network" is the ML2 maturity gate; immutability is not addressed. Replication targets accessible via the same compromised admin credential as production fail the ransomware blast-radius test without failing E8 Backup compliance. |
-| AU ISM | ISM-1554 Incident response plan is exercised; ISM-1814 Ransomware preparation (in queue 2024-2026) | Tabletop / live exercise of the incident response plan. | Exercise frequency is named; exercise content is not. ISM-1814 (planned) will reference ransomware specifics but is not in force at the time of this writing. |
+| AU ISM | ISM-1784 (incident response plan exercised at least annually) + ISM-1819 (plan enacted once an incident is identified) + ISM-1814 (unprivileged accounts cannot modify or delete backups) | Annual exercise of the incident response plan, and backups protected from the accounts ransomware usually runs as. | The exercise frequency is named but its content is not, so an exercise that never rehearses a payment decision or a sanctions check satisfies ISM-1784. ISM-1814 applies at every Essential Eight maturity level but protects backups from unprivileged accounts only; ISM-1705 extends that to privileged accounts other than backup administrators from Maturity Level Two, which still leaves a compromised backup administrator able to delete them. |
 | UK NCSC CAF | D1 Response and Recovery Planning | Outcome that the org has plans for responding to and recovering from cyber incidents. | Outcome-shaped at IGP/IGP+ level; tabletop exercise is plan-existence proof. Does not test whether plans address ransomware sub-class with immutable-backup viability check or sanctions screening. |
 | US OFAC | 31 CFR 501 + OFAC Ransomware Advisory (2021) | Sanctions list; advisory making clear payment to sanctioned actor is federal-law violation. | Lives in Treasury regulatory tree, not in NIST/ISO/SOC 2 security controls. Cross-walk is operator's responsibility; no security framework names the OFAC SDN list check as a control on the payment posture. |
 | EU | Council Regulation 2014/833 — Cyber Sanctions | EU consolidated cyber sanctions list. | Same structural gap as OFAC — lives in EU sanctions tree, not in NIS2 or DORA control text. |
@@ -127,7 +127,7 @@ Cross-cutting gap: **no security framework treats the four ransomware-specific d
 | **T1078** | Valid Accounts | Initial access via credential reuse from infostealer markets; AD privilege chain mapping pre-encryption; lateral movement via valid accounts to broaden encryption scope. | Identification: anomalous sign-in UEBA, impossible-travel, infostealer-market evidence. Containment: account disable + session revocation + MFA re-enrollment. Eradication: krbtgt double-rotation, OAuth-grant audit, AD admin-group review. |
 | **T1059** | Command and Scripting Interpreter | Living-off-the-land via PowerShell, WMI, PsExec; Cobalt Strike Beacon / Sliver / Brute Ratel as C2 framework. | Identification: EDR script-block-logging, suspicious WMI invocations, JA3 fingerprints. Containment: EDR quarantine, egress block to C2 destinations. Eradication: artifact removal, persistence-mechanism cleanup. |
 
-Shadow Copy deletion and exfil-staging via Web Service align to the parent IR playbook's `T1486` and `T1567` entries; the parent's `AML.T0096 / AML.T0017 / AML.T0051` entries do not apply to ransomware-as-a-class but may apply if AI-system data is exfiltrated within the ransomware operation.
+Shadow Copy deletion and exfil-staging via Web Service align to the parent IR playbook's `T1486` and `T1567` entries; the parent's `AML.T0096 / AML.T0024 / AML.T0051` entries do not apply to ransomware-as-a-class but may apply if AI-system data is exfiltrated within the ransomware operation.
 
 ATLAS pinned to v2026.09 (September 2026). ATT&CK pinned to v19.2 (August 2026). Both are explicit version pins — never silently upgraded.
 

package/skills/researcher/skill.md

@@ -86,13 +86,13 @@ This is a routing skill. The TTP coverage of any specific output equals the TTP
 | ATLAS / ATT&CK Class | Researcher Routes To |
 |---|---|
 | AML.T0010 (AI Supply Chain Compromise) | `mcp-agent-trust`, `ai-attack-surface` |
-| AML.T0016 (Obtain Capabilities: Develop Capabilities — AI-assisted) | `ai-attack-surface`, `kernel-lpe-triage`, `exploit-scoring` |
-| AML.T0017 (Discover ML Model Ontology) | `ai-attack-surface`, `mlops-security`, `api-security` |
+| AML.T0016 / AML.T0017 (Obtain Capabilities / Develop Capabilities, AI-assisted) | `ai-attack-surface`, `kernel-lpe-triage`, `exploit-scoring` |
+| AML.T0013 (Discover AI Model Ontology) | `ai-attack-surface`, `mlops-security`, `api-security` |
 | AML.T0018 (Manipulate AI Model) | `ai-attack-surface` |
 | AML.T0020 (Training Data Poisoning) | `ai-attack-surface`, `rag-pipeline-security` |
 | AML.T0043 (Craft Adversarial Data) / AML.T0054 (LLM Jailbreak) | `ai-attack-surface`, `rag-pipeline-security` |
 | AML.T0051 (LLM Prompt Injection) | `ai-attack-surface`, `mcp-agent-trust` |
-| AML.T0096 (LLM Integration Abuse — C2) | `ai-c2-detection` |
+| AML.T0096 (AI Service API, C2) | `ai-c2-detection` |
 | ATT&CK T1068 / T1548.001 (Privilege Escalation) | `kernel-lpe-triage` |
 | ATT&CK T1195.001 (Supply Chain Compromise) | `mcp-agent-trust` |
 | ATT&CK T1071 / T1102 (Application Layer / Web Service C2) | `ai-c2-detection` |

package/skills/sector-financial/skill.md

@@ -27,7 +27,7 @@ data_deps:
   - framework-control-gaps.json
 atlas_refs:
   - AML.T0096
-  - AML.T0017
+  - AML.T0013
 attack_refs:
   - T1078
   - T1190
@@ -153,7 +153,7 @@ In all three, the SCA evidence chain (the customer's authenticated session, the
 | Ransomware against banking infrastructure | T1486 — Data Encrypted for Impact | ATT&CK Enterprise | LockBit-class, BlackBasta, ALPHV/BlackCat residuals 2024-2026; double-extortion + regulatory-threat-of-disclosure | NYDFS 500.17 ransom-payment notification (72h) + DORA major-incident reporting (Art. 19, 24h initial) + APRA CPS 234 para 26 (72h) — notification cadences harmonising slowly; ransom-payment legality fragmented (NYDFS reporting only, OFAC sanctions-screening, EU sanctions overlay) |
 | Data exfiltration including LLM-channel | T1567 — Exfiltration Over Web Service | ATT&CK Enterprise | LLM API egress (OpenAI, Anthropic, Google) as covert channel; AI-coding-assistant context leaks; KYC-document upload to consumer-grade AI | DLP controls in `data/dlp-controls.json` apply; SWIFT CSCF v2026 1.1 segregation assumption violated when AI-API egress crosses administrative jump zone |
 | AI-as-covert-C2 in trading / treasury systems | AML.T0096 — Use AI for C2 Communications | ATLAS v2026.09 | Steganographic encoding in trading-assistant prompts; LLM response decodes operator instructions; multi-agent covert relay in market-making bots | No ATT&CK Enterprise mapping; ATLAS v2026.09 names the technique but no financial-sector-specific detection. SOC tooling rarely monitors trading-system AI tool-use. |
-| Fraud-detection model extraction | AML.T0017 — Discover ML Model Ontology | ATLAS v2026.09 | Adversarial probing of card-not-present fraud models; chargeback-pattern fingerprinting; transaction-monitoring threshold discovery via test transactions | Fraud-model lifecycle governance under MAS TRM / OSFI B-13 / NYDFS 500.13 (asset management) — model-extraction probes are not classified as a cyber event in most institutions |
+| Fraud-detection model extraction | AML.T0013 (Discover AI Model Ontology) | ATLAS v2026.09 | Adversarial probing of card-not-present fraud models; chargeback-pattern fingerprinting; transaction-monitoring threshold discovery via test transactions | Fraud-model lifecycle governance under MAS TRM / OSFI B-13 / NYDFS 500.13 (asset management) — model-extraction probes are not classified as a cyber event in most institutions |
 | Hard-coded credentials in financial mobile / API clients | CWE-798 | CWE | Mobile-banking apps shipping API keys; partner-integration API tokens checked into Git; treasury-management-system local config | PSD2 RTS-SCA covers customer SCA, silent on partner-API credential hygiene; SWIFT CSCF 5.1/5.2 covers credential management for SWIFT users only |
 | Agent-initiated payment via prompt injection | (No native TTP — closest: T1078 + AML.T0051) | ATT&CK + ATLAS | LLM agent with payment-initiation tool-use receives injected instruction via email / document / web content; transaction executes under customer's authenticated session | RTS-SCA evidence chain is fully compliant; injected intent invisible. Captured in `data/framework-control-gaps.json#PSD2-RTS-SCA`. |
 | AI-generated SWIFT MT/MX message draft poisoning | (No native TTP — closest: T1565 + AML.T0051) | ATT&CK + ATLAS | LLM-assisted operator drafting tool produces subtly-wrong beneficiary BIC or amount; reviewer fatigue lets it pass 4-eyes principle | Captured in `data/framework-control-gaps.json#SWIFT-CSCF-v2026-1.1`. |
@@ -237,7 +237,7 @@ For NY-regulated entities:
 ### Step 6 — Fraud-detection model adversarial-resilience audit
 
 - Pull current fraud-detection model architecture, training data refresh cadence, drift-monitoring posture.
-- Per AML.T0017 (Discover ML Model Ontology): test the institution's ability to detect model-probing — incremental test transactions, threshold-discovery patterns, chargeback-pattern fingerprinting. If detection is "manual review of false-positive rate trends only," the model is functionally undefended against probing.
+- Per AML.T0013 (Discover AI Model Ontology): test the institution's ability to detect model-probing — incremental test transactions, threshold-discovery patterns, chargeback-pattern fingerprinting. If detection is "manual review of false-positive rate trends only," the model is functionally undefended against probing.
 - Validate model retraining cadence: monthly or faster for high-velocity surfaces (card-not-present); quarterly is theater for any adversary-evolving surface (see Theater Test 4).
 - Cross-walk to OSFI E-23 (Enterprise-Wide Model Risk Management) and SR 11-7 equivalents.
 
@@ -363,7 +363,7 @@ Ask: "What is your fraud-detection model retraining cadence, drift-monitoring ca
 
 - If the answer is "quarterly retraining, manual drift review, no adversarial testing": this is theater against any AI-augmented fraud adversary. Mid-2026 adversary capability evolves on a 2-4 week cycle for AI-augmented BEC and on a continuous cycle for card-not-present fraud-pattern adaptation.
 - If "we don't know when adversaries last successfully evaded": detection of evasion is the missing control. Successful evasions show up as chargeback-volume drift weeks later, not as fraud-system alerts.
-- Acceptable: monthly-or-faster retraining for high-velocity surfaces, continuous drift monitoring with alerting, scheduled adversarial-resilience testing (AML.T0017 detection), retrospective audit of evasion patterns from chargeback / customer-complaint signal.
+- Acceptable: monthly-or-faster retraining for high-velocity surfaces, continuous drift monitoring with alerting, scheduled adversarial-resilience testing (AML.T0013 detection), retrospective audit of evasion patterns from chargeback / customer-complaint signal.
 
 ---
 

package/skills/sector-healthcare/skill.md

@@ -23,6 +23,7 @@ data_deps:
 atlas_refs:
   - AML.T0051
   - AML.T0017
+  - AML.T0013
 attack_refs:
   - T1078
   - T1530
@@ -112,12 +113,12 @@ Healthcare has been the most targeted sector for ransomware for three consecutiv
 | Bulk EHR / FHIR / data-warehouse exfiltration | T1530 — Data from Cloud Storage Object | ATT&CK Enterprise | FHIR `$export` Bulk Data over-broad scopes; cloud data warehouse (Snowflake / BigQuery / Redshift) credential theft from clinician laptop; AWS S3 misconfiguration on de-identification staging buckets | HIPAA §164.312(c) integrity controls do not address bulk-API exfil semantics; HITRUST CSF 09.l information-transfer-policies treats bulk data flow at a policy layer. CWE-200 (Information Exposure), CWE-862 (Missing Authorization). |
 | PHI exfiltration via clinician prompt to consumer LLM | T1567 — Exfiltration Over Web Service | ATT&CK Enterprise | Clinician pastes patient note into ChatGPT / Claude / Gemini for differential diagnosis or letter drafting; ambient-doc tool retains and forwards transcript to vendor cloud outside BAA | No HIPAA control specifically names this channel; HHS-OCR Bulletin reasoning applies. Hand off to dlp-gap-analysis. CWE-200 (Information Exposure). |
 | Prompt injection of clinical decision-support copilot | AML.T0051 — LLM Prompt Injection (with .000/.001/.002 sub-techniques) | ATLAS v2026.09 | Indirect prompt injection via referenced lab report PDF, OCR'd intake form, or patient-portal message that exploits an EHR-integrated copilot; instruction to suppress allergy alert, reorder medications, or fabricate trend in vital signs | EU AI Act Art 15 cybersecurity obligation applies but lacks concrete healthcare-AI threshold; HIPAA silent on prompt-injection-as-disclosure-vector. CWE-1426 (Improper Validation of Generative AI Output). |
-| Model extraction / membership inference against clinical AI | AML.T0017 — Discover ML Model Ontology (inference-API probing for system-prompt, guardrail, training-data signal); AML.T0016 — Obtain Capabilities: Develop Capabilities (adversarial-ML weaponization) | ATLAS v2026.09 | Adversarial probing of a clinical-decision-support API to determine whether specific patient records were in training set; reconstruction of de-identified training examples from inference behaviour | EU AI Act Art 10 data-governance applies to training-data quality; does not codify membership-inference defence. CWE-1426 covers output-validation gap. |
+| Model extraction / membership inference against clinical AI | AML.T0013, Discover AI Model Ontology (inference-API probing for system-prompt, guardrail, training-data signal); AML.T0017, Develop Capabilities (adversarial-ML weaponization) | ATLAS v2026.09 | Adversarial probing of a clinical-decision-support API to determine whether specific patient records were in training set; reconstruction of de-identified training examples from inference behaviour | EU AI Act Art 10 data-governance applies to training-data quality; does not codify membership-inference defence. CWE-1426 covers output-validation gap. |
 | Medical-device firmware tamper / exploit | T1190 (IT-side initial access to device-network) chained with vendor-specific device CVEs | ATT&CK Enterprise + ICS where applicable | Insulin pumps, cardiac monitors, infusion pumps (BD Alaris), sequencers (Illumina firmware), patient-monitoring (BD, Philips, GE Healthcare), bedside imaging | FDA 524B PMA/510(k) cyber obligations only apply to devices submitted after March 2023; brownfield fleet pre-dates it. EU MDR Annex I 17.2 silent on AI-augmented devices. Hand off to ot-ics-security for device-network treatment, and coordinated-vuln-disclosure for vendor reporting. |
 | FHIR / SMART on FHIR session token theft | T1078 chained with T1530 | ATT&CK Enterprise | Stolen JWT / OAuth2 bearer for SMART-on-FHIR launch; over-broad scopes (`*/*.read`, `patient/*.read`); refresh-token theft persists access; CWE-287 (improper authentication) and CWE-862 (missing authorization) | RFC-7519 JWT validation must enforce `iss`, `aud`, `exp`, signature algorithm, key rotation; RFC-9421 HTTP message signatures for FHIR API integrity in flight; HL7 FHIR R5 does not mandate either. |
 | EHR over-privileged break-glass / shared-account access | T1078.002 — Valid Accounts: Domain Accounts | ATT&CK Enterprise | Shared "Nurse" account on med-cart Windows; break-glass clinician account auditing gap; service account for EHR-integrated copilot with patient/* scope rather than encounter-bound | HIPAA §164.312(a)(2)(i) unique user identification is met technically by user-account-per-clinician but break-glass and AI-service-principals are commonly outside that boundary. NIST 800-53 AC-2 account management does not codify AI-service-principal scoping. |
 
-**Note on ATLAS coverage.** AML.T0051 (Prompt Injection) covers the direct, indirect, and jailbreak sub-techniques against clinical-decision-support copilots; AML.T0054 (LLM Jailbreak) covers guardrail-bypass crafting; AML.T0017 (Discover ML Model Ontology) covers adversary reconnaissance of the deployed model — system-prompt extraction, guardrail mapping, training-data signal probing — relevant to clinical-AI confidentiality; AML.T0016 (Obtain Capabilities: Develop Capabilities) covers the broader adversarial-ML weaponization pipeline.
+**Note on ATLAS coverage.** AML.T0051 (Prompt Injection) covers the direct, indirect, and jailbreak sub-techniques against clinical-decision-support copilots; AML.T0054 (LLM Jailbreak) covers guardrail-bypass crafting; AML.T0013 (Discover AI Model Ontology) covers adversary reconnaissance of the deployed model — system-prompt extraction, guardrail mapping, training-data signal probing — relevant to clinical-AI confidentiality; AML.T0017 (Develop Capabilities) covers the broader adversarial-ML weaponization pipeline.
 
 ---
 

package/skills/sector-telecom/skill.md

@@ -29,7 +29,7 @@ data_deps:
   - cve-catalog.json
   - framework-control-gaps.json
 atlas_refs:
-  - AML.T0040
+  - AML.T0010
 attack_refs:
   - T1071
   - T1078
@@ -43,7 +43,7 @@ framework_gaps:
   - NIS2-Annex-I-Telecom
   - DORA-Art-21-Telecom-ICT
   - UK-CAF-B5
-  - AU-ISM-1556
+  - AU-ISM-1173-Telecom-NMS
   - GSMA-NESAS-Deployment
   - 3GPP-TR-33.926
   - ITU-T-X.805
@@ -92,15 +92,15 @@ Telecom security mandates lag the current threat reality because the regulatory
 
 | Tactic | ATT&CK | ATLAS | Description |
 |---|---|---|---|
-| Initial Access | T1199 Trusted Relationship | AML.T0040 (Tool/Plugin Compromise) | OEM vendor remote-support tunnel or AI-RAN plugin compromise opens a path into the operator network |
+| Initial Access | T1199 Trusted Relationship | AML.T0010 (AI Supply Chain Compromise) | OEM vendor remote-support tunnel or AI-RAN plugin compromise opens a path into the operator network |
 | Initial Access | T1190 Exploit Public-Facing Application | — | Internet-facing OSS / EMS / NMS exposed services (Salt Typhoon access pattern) |
 | Persistence | T1098 Account Manipulation | — | Persistent admin role grants on NMS / EMS / OSS after initial compromise |
 | Defense Evasion | T1556 Modify Authentication Process | — | LI-gateway credential pivot — operator account credentials forged or replayed against LI provisioning subsystem |
 | Credential Access | T1078 Valid Accounts | — | Stolen LI-gateway operator credentials used directly, no separate exploitation path |
 | Command and Control | T1071 Application Layer Protocol | — | Living-off-the-land C2 over telecom internal management protocols (SNMP, NETCONF, Telco-IP-fabric) |
-| Collection | T1199 (downstream) | AML.T0040 (downstream) | Pulling subscriber call-detail records, location data, and LI feed contents via compromised access |
+| Collection | T1199 (downstream) | AML.T0010 (downstream) | Pulling subscriber call-detail records, location data, and LI feed contents via compromised access |
 
-ATLAS AML.T0040 (Tool / Plugin Compromise) anchors the AI-RAN attack class: plugin-layer compromise of an O-RAN xApp or rApp can route traffic through an adversary-controlled inference path while the NMS believes the legitimate xApp is still in use.
+ATLAS AML.T0010 (AI Supply Chain Compromise) anchors the AI-RAN attack class: plugin-layer compromise of an O-RAN xApp or rApp can route traffic through an adversary-controlled inference path while the NMS believes the legitimate xApp is still in use.
 
 ## Exploit Availability Matrix
 
@@ -111,7 +111,7 @@ ATLAS AML.T0040 (Tool / Plugin Compromise) anchors the AI-RAN attack class: plug
 | SS7 / Diameter signaling abuse | Public (signaling-research community) | Commodity | Low | Pre-dates AI-augmented attack landscape |
 | GTP-U tunneling attacks | Public | Demonstrated | Low | Operator-side defense via signaling firewalls |
 | 5G core N4 abuse (PFCP) | Researcher PoCs | Demonstrated | Low | Defense via N4 isolation per TS 33.501 |
-| AI-RAN xApp tampering | No public PoC | Speculative | High (ATLAS AML.T0040 class) | CTID Secure AI v2 forward-watch |
+| AI-RAN xApp tampering | No public PoC | Speculative | High (ATLAS AML.T0010 class) | CTID Secure AI v2 forward-watch |
 | gNB firmware tampering | Researcher PoCs (vendor-specific) | Demonstrated against vendor pre-prod | Low | GSMA NESAS scope gap |
 | Slice mismapping (cross-slice leak) | Researcher PoCs against test cores | Demonstrated | Low | TS 33.501 control surface |
 
@@ -165,7 +165,7 @@ Walk every indicator's `false_positive_checks_required` list before submitting a
 
 ### Correlation
 
-Match captured artifacts against `data/cve-catalog.json` entries with `attack_class: telecom` or matching `attack_refs`. Cross-reference against `data/framework-control-gaps.json` for FCC-CPNI-4.1, FCC-Cyber-Incident-Notification-2024, NIS2-Annex-I-Telecom, DORA-Art-21-Telecom-ICT, UK-CAF-B5, AU-ISM-1556, GSMA-NESAS-Deployment, 3GPP-TR-33.926, ITU-T-X.805. Score blast-radius based on subscriber count + LI-feed-exposure dimension + AI-RAN slice-mismapping potential.
+Match captured artifacts against `data/cve-catalog.json` entries with `attack_class: telecom` or matching `attack_refs`. Cross-reference against `data/framework-control-gaps.json` for FCC-CPNI-4.1, FCC-Cyber-Incident-Notification-2024, NIS2-Annex-I-Telecom, DORA-Art-21-Telecom-ICT, UK-CAF-B5, AU-ISM-1173-Telecom-NMS, GSMA-NESAS-Deployment, 3GPP-TR-33.926, ITU-T-X.805. Score blast-radius based on subscriber count + LI-feed-exposure dimension + AI-RAN slice-mismapping potential.
 
 ### Priority-sorted remediation
 
@@ -253,4 +253,4 @@ Theater patterns specific to telecom posture:
 - **framework-gap-analysis** — invoke for downstream Hard-Rule-5 gap mapping against catalog framework_gaps.
 - **cred-stores** *(playbook chain, not a skill)* — LI-gateway operator credential storage falls under the `cred-stores` playbook for secret-management depth.
 - **sector-federal-government** — national-security adjacency on LI-system compromise touches federal investigation scope.
-- **mcp-agent-trust** — AI-RAN xApp / rApp compromise (ATLAS AML.T0040 class) crosses into MCP-class agent-tool trust boundaries.
+- **mcp-agent-trust** — AI-RAN xApp / rApp compromise (ATLAS AML.T0010 class) crosses into MCP-class agent-tool trust boundaries.