@blamejs/exceptd-skills 0.19.0 → 0.19.2

package/scripts/predeploy.js

@@ -222,6 +222,32 @@ const GATES = [
     args: [path.join(ROOT, "scripts", "check-framework-gap-coverage.js")],
     ciJobName: "Data integrity (catalog + manifest snapshot)",
   },
+  {
+    // TTP reference-integrity gate. The two pinned MITRE catalogs define the
+    // techniques; every other file naming one is referring into them. MITRE
+    // retires and renumbers between releases, and a reference living outside
+    // the source catalogs is never dereferenced at runtime — so a stale id
+    // keeps rendering in operator output, pointing at a page that no longer
+    // resolves and leaving any control mapped to it orphaned (Hard Rule #4).
+    // Resolves against the pin rather than the network, so it can block.
+    name: "TTP reference integrity (no orphaned technique ids)",
+    command: process.execPath,
+    args: [path.join(ROOT, "scripts", "check-ttp-references.js")],
+    ciJobName: "Data integrity (catalog + manifest snapshot)",
+  },
+  {
+    // EPSS pair-consistency gate. A CVE's epss_score and epss_percentile come
+    // from the same daily publication, where the percentile is the score's
+    // rank — so sorting a publication's entries by score must sort them by
+    // percentile too. Refreshing one field without the other leaves an entry
+    // that passes every range and type check while ranking a CVE on a score
+    // that no longer supports it, which is precisely the input operators
+    // prioritise by. The ordering check catches that offline.
+    name: "EPSS score/percentile consistency",
+    command: process.execPath,
+    args: [path.join(ROOT, "scripts", "check-epss-consistency.js")],
+    ciJobName: "Data integrity (catalog + manifest snapshot)",
+  },
   {
     // Version-tag drift gate. Compares the tracked tree against a
     // baseline snapshot of pre-existing `// vX.Y.Z` comments and

package/skills/age-gates-child-safety/skill.md

@@ -125,13 +125,13 @@ Classical security and privacy frameworks (NIST 800-53 r5, ISO/IEC 27001:2022, S
 
 ## TTP Mapping
 
-This skill is primarily a compliance + privacy-engineering skill rather than a technical-exploit skill. There are no ATLAS-catalogued AI-attack TTPs that are child-specific as of v2026.06, and most relevant attacker activity intersects general ATT&CK techniques rather than child-targeted novel TTPs. The relevant mapping is therefore narrower and explicitly flagged as such — `atlas_refs` is empty by design, not omission.
+This skill is primarily a compliance + privacy-engineering skill rather than a technical-exploit skill. There are no ATLAS-catalogued AI-attack TTPs that are child-specific as of v2026.07, and most relevant attacker activity intersects general ATT&CK techniques rather than child-targeted novel TTPs. The relevant mapping is therefore narrower and explicitly flagged as such — `atlas_refs` is empty by design, not omission.
 
 | ID | Source | Technique | Child-Safeguarding Relevance | Gap Flag |
 |---|---|---|---|---|
 | T1078 | ATT&CK Enterprise | Valid Accounts | Account takeover targeting child accounts (compromised parental controls; sextortion via stolen accounts; grooming via account hijack) — child accounts are under-protected because MFA roll-out lags adult user populations. | NIST 800-53 AC-2 + COPPA / AADC / Children's Code silent on MFA-for-child requirement; the AC-2 gap entry in `data/framework-control-gaps.json` covers AI-service-principals not child identities. Hand off to `identity-assurance` for AAL2+ on child accounts where vendor terms permit. |
 | T1567 | ATT&CK Enterprise | Exfiltration Over Web Service | Child PI exfiltrated via AI-tool / SaaS egress — additional liability under COPPA (no behavioral-ad use of under-13 PI), AADC (DPIA failure), GDPR Art. 8 (no lawful basis), DPDPA (default-VPC bypass), CN PIPL Art. 31 (child PI = sensitive PI requiring separate consent). | Hand off to `dlp-gap-analysis` for child-PI as a protected data class; COPPA / AADC / Children's Code do not name DLP technical controls; the SOC2-CC7 anomaly-detection gap entry applies. |
-| AI-generated CSAM creation / distribution | Not catalogued in ATLAS or ATT&CK as of v2026.06 | Generative-AI image / video synthesis depicting children | Direct criminal exposure under 18 U.S.C. §§2251, 2252, 2252A, 2256 (Protect Act / Mash-Up Act framework); mandatory NCMEC reporting per §2258A. Multiple 2024-2025 prosecutions (US v. Anderegg WD-Wis 2024 — first federal AI-CSAM prosecution; UK National Crime Agency campaign 2024-2025). | No formal TTP class. Evidence stream: NCMEC CyberTipline reports + EU IWF reports. Hand off to `ai-attack-surface` for generative-model content-policy red-team and to `incident-response-playbook` for reporting workflow. |
+| AI-generated CSAM creation / distribution | Not catalogued in ATLAS or ATT&CK as of v2026.07 | Generative-AI image / video synthesis depicting children | Direct criminal exposure under 18 U.S.C. §§2251, 2252, 2252A, 2256 (Protect Act / Mash-Up Act framework); mandatory NCMEC reporting per §2258A. Multiple 2024-2025 prosecutions (US v. Anderegg WD-Wis 2024 — first federal AI-CSAM prosecution; UK National Crime Agency campaign 2024-2025). | No formal TTP class. Evidence stream: NCMEC CyberTipline reports + EU IWF reports. Hand off to `ai-attack-surface` for generative-model content-policy red-team and to `incident-response-playbook` for reporting workflow. |
 | AI chatbot grooming / harmful-content engagement with children | Not catalogued | Long-context AI chatbot interactions with children steering toward harm | Research and litigation evidence: Character.ai litigation 2024 (FL wrongful-death suit alleging companion-chatbot contribution to minor suicide; additional 2024-2025 complaints); UK NCA campaign 2024 documenting grooming attempts via AI chatbots; ESRC / RAND research 2024-2025. | No formal TTP class. EU DSA Art. 28 + UK OSA + AU OSA + KOSA-if-enacted all frame this as a platform duty-of-care obligation. Hand off to `ai-risk-management` for AI-product age policy enforcement. |
 
 **Honest scope statement (no fabricated TTP IDs).** This skill does not invent TTP IDs to fill gaps in the ATLAS or ATT&CK matrices. AI-generated CSAM and AI-chatbot-mediated harm to children are real-world threat classes documented through prosecution records, NCMEC / IWF reporting, and litigation — not novel ATLAS techniques. Citation is to the evidence stream, not to a TTP ID.

package/skills/ai-attack-surface/skill.md

@@ -1,7 +1,7 @@
 ---
 name: ai-attack-surface
 version: "1.0.0"
-description: Comprehensive AI/ML attack surface assessment mapped to MITRE ATLAS v2026.06 with explicit framework gap flags
+description: Comprehensive AI/ML attack surface assessment mapped to MITRE ATLAS v2026.07 with explicit framework gap flags
 triggers:
   - ai attack surface
   - prompt injection
@@ -156,7 +156,7 @@ AI-assisted reconnaissance is observed at 36,000 probes per second per campaign.
 | SOC 2 | CC6 (Logical and Physical Access) | Access control via IAM, authentication, authorization. Prompt injection is an access control failure that routes around CC6 entirely — the authorized model account takes the action, not the attacker. Audit trails show the model's service account performed the action. |
 | SOC 2 | CC7 (System Operations) | Anomaly detection for system operations. No guidance for AI API baseline, AI C2 detection, or PROMPTFLUX behavioral patterns. |
 | PCI DSS 4.0 | 6.4.1 | Web application protection (WAF). WAFs operate on HTTP request/response patterns. They have no semantic understanding of prompt injection embedded in JSON `message` fields. |
-| MITRE ATT&CK | Enterprise | Does not include prompt injection as a technique. AI-as-C2 (SesameOp) is not in ATT&CK as of mid-2026. ATLAS v2026.06 covers these but is not part of SOC detection engineering programs that are ATT&CK-mapped. |
+| MITRE ATT&CK | Enterprise | Does not include prompt injection as a technique. AI-as-C2 (SesameOp) is not in ATT&CK as of mid-2026. ATLAS v2026.07 covers these but is not part of SOC detection engineering programs that are ATT&CK-mapped. |
 | NIST AI RMF | MEASURE 2.5 | Measure AI risks during operation. Provides a framework for thinking about AI risk but no specific controls for prompt injection, MCP supply chain, or AI-as-C2. |
 | EU NIS2 | Art. 21(2)(d) (supply-chain security) + Art. 21(2)(e) (security in acquisition, development and maintenance) | "Appropriate and proportionate" supply-chain language. Member-state transpositions (BSI IT-SiG 2.0, ANSSI) do not enumerate MCP servers or LLM API providers as in-scope supply-chain components. An essential entity can meet NIS2 supplier-management obligations with traditional SaaS vendor reviews while having zero coverage of AI-assistant tool ecosystems. |
 | EU DORA | Art. 8 (ICT asset management) + Art. 28 (ICT third-party register) + Art. 30 (key contractual provisions) | Financial-entity ICT third-party language scoped to traditional ICT providers. LLM API providers acting as data processors for prompt content and developer-environment MCP servers are not enumerated as ICT third-party service providers. ESAs RTS on subcontracting (JC 2024/53) is silent on AI/ML SaaS dependency classes. |
@@ -170,7 +170,7 @@ AI-assisted reconnaissance is observed at 36,000 probes per second per campaign.
 
 ---
 
-## TTP Mapping (MITRE ATLAS v2026.06)
+## TTP Mapping (MITRE ATLAS v2026.07)
 
 | ATLAS ID | Technique | Framework Coverage | Gap Description | Exploitation Example |
 |---|---|---|---|---|

package/skills/ai-c2-detection/skill.md

@@ -330,13 +330,13 @@ level: medium
 
 ---
 
-## TTP Mapping (MITRE ATLAS v2026.06 + MITRE ATT&CK)
+## TTP Mapping (MITRE ATLAS v2026.07 + MITRE ATT&CK)
 
 | ID | Source | Technique | C2 Relevance | Gap Flag — Which Detection Control Fails |
 |---|---|---|---|---|
-| AML.T0096 | ATLAS v2026.06 | LLM API as covert C2 / LLM Integration Abuse | Direct: SesameOp encodes commands and exfiltrated data in prompt and completion fields against api.openai.com, api.anthropic.com, generativelanguage.googleapis.com. AI provider domain is the relay, not the attacker C2 endpoint. | NIST-800-53-SC-7 (Boundary Protection) — AI provider domains are allowlisted in most enterprise egress for legitimate developer and product use, so boundary inspection cannot distinguish benign developer prompts from C2-encoded prompts. See SC-7 entry in `data/framework-control-gaps.json` — real requirement is SDK-level prompt logging with identity binding, anomaly detection on prompt-shape and token-volume, and an allowlist that enumerates the sanctioned business reason per identity. Boundary-only SC-7 evidence is incomplete for any org with AI API access in production. |
-| AML.T0017 | ATLAS v2026.06 | Discover ML Model Ontology — adversary maps the deployed LLM's family, system-prompt structure, guardrail surface via inference-API probing | PROMPTFLUX queries public LLMs to generate per-execution evasion code; PROMPTSTEAL uses LLMs to prioritise exfiltration targets — both depend on first discovering what the target model will answer. The inference API is the discovery surface. | NIST-800-53-SI-3 fails — there is no static signature for code generated per-event by a public LLM. NIST-800-53-SI-4 fails as commonly deployed — no AI-API behavioural baseline per process/identity. |
-| AML.T0016 | ATLAS v2026.06 | Obtain Capabilities: Develop Capabilities — adversary use of inference APIs to generate / refine malware, evasion, phishing payloads | PROMPTFLUX and PROMPTSTEAL both consume public LLMs as a real-time capability-development service. The inference API is doing weaponization work for the adversary. | NIST-800-53-SI-3 fails for the same reason. SC-7 boundary control treats the AI provider as allowlisted SaaS. |
+| AML.T0096 | ATLAS v2026.07 | LLM API as covert C2 / LLM Integration Abuse | Direct: SesameOp encodes commands and exfiltrated data in prompt and completion fields against api.openai.com, api.anthropic.com, generativelanguage.googleapis.com. AI provider domain is the relay, not the attacker C2 endpoint. | NIST-800-53-SC-7 (Boundary Protection) — AI provider domains are allowlisted in most enterprise egress for legitimate developer and product use, so boundary inspection cannot distinguish benign developer prompts from C2-encoded prompts. See SC-7 entry in `data/framework-control-gaps.json` — real requirement is SDK-level prompt logging with identity binding, anomaly detection on prompt-shape and token-volume, and an allowlist that enumerates the sanctioned business reason per identity. Boundary-only SC-7 evidence is incomplete for any org with AI API access in production. |
+| AML.T0017 | ATLAS v2026.07 | Discover ML Model Ontology — adversary maps the deployed LLM's family, system-prompt structure, guardrail surface via inference-API probing | PROMPTFLUX queries public LLMs to generate per-execution evasion code; PROMPTSTEAL uses LLMs to prioritise exfiltration targets — both depend on first discovering what the target model will answer. The inference API is the discovery surface. | NIST-800-53-SI-3 fails — there is no static signature for code generated per-event by a public LLM. NIST-800-53-SI-4 fails as commonly deployed — no AI-API behavioural baseline per process/identity. |
+| AML.T0016 | ATLAS v2026.07 | Obtain Capabilities: Develop Capabilities — adversary use of inference APIs to generate / refine malware, evasion, phishing payloads | PROMPTFLUX and PROMPTSTEAL both consume public LLMs as a real-time capability-development service. The inference API is doing weaponization work for the adversary. | NIST-800-53-SI-3 fails for the same reason. SC-7 boundary control treats the AI provider as allowlisted SaaS. |
 | T1071 | ATT&CK | Application Layer Protocol (C2) | AI C2 traffic is standard HTTPS REST to api.openai.com or equivalent. Application-protocol C2 detection that looks for DGA, unusual TLS, or beaconing does not fire. | SC-7 boundary control sees only the destination domain (allowlisted) — no protocol anomaly to alert on. Detection requires identity-bound prompt content inspection, which SC-7 as written does not require. |
 | T1102 | ATT&CK | Web Service (C2 via legitimate web service) | AI API endpoints are exactly the "legitimate web service used as C2" pattern that T1102 describes — but at scale and pre-allowlisted in nearly every enterprise. | SOC 2 CC7 anomaly-detection control: AI API traffic shares the SaaS blind spot — typically not baselined per process or identity. ISO 27001 A.8.16 monitoring activities: no guidance for AI-API-shaped traffic. |
 | T1568 | ATT&CK | Dynamic Resolution | AI provider responses can carry encoded instructions that dynamically determine the next-hop behaviour for the malware (effectively model-mediated dynamic resolution of the next attacker instruction). | No standard DNS-tunnelling or DGA detection applies — the "resolution" happens inside an HTTPS payload to a trusted endpoint. SC-7 cannot see it without SDK-level prompt + response logging. |

package/skills/api-security/skill.md

@@ -126,7 +126,7 @@ APIs are now the integration substrate of every non-trivial system. The mid-2026
 
 ---
 
-## TTP Mapping (MITRE ATT&CK Enterprise + ATLAS v2026.06)
+## TTP Mapping (MITRE ATT&CK Enterprise + ATLAS v2026.07)
 
 | TTP ID | Technique | API Manifestation | CWE Root-Causes | Framework Coverage |
 |---|---|---|---|---|

package/skills/attack-surface-pentest/skill.md

@@ -115,17 +115,17 @@ A pen test scoped to layers 1 and (partly) 7 — i.e. "web app + network + nomin
 | CBEST (Bank of England / PRA / FCA) | Whole framework | UK equivalent to TIBER-EU for systemically important financial firms. Same lag pattern as TIBER-EU. CBEST-certified providers are not required to demonstrate competence in AI-surface attack emulation as of mid-2026. |
 | Australian ISM (Information Security Manual) + ACSC Essential 8 | ISM controls on penetration testing; Essential 8 Maturity Level 3 testing requirements | Essential 8 mandates regular testing of mitigation strategies (patching, app control, MFA, etc.). The testing requirements do not extend to AI-API egress as C2, MCP trust, or RAG poisoning. ISM control set is network/endpoint centric. |
 | ISO/IEC 27001:2022 | A.5.34 (Privacy and protection of PII) — note: the actually relevant clause for independent review is **A.5.35 (Independent review of information security)** and **A.8.29 (Security testing in development and acceptance)** | A.5.35 requires independent review of the information security approach at planned intervals or when significant changes occur. The clause is methodology-agnostic — auditors accept a network/web pen test as evidence even when AI surfaces are in production. A.8.29 mandates security testing of new and changed information systems, but does not define what an adequate test of an AI system looks like. |
-| MITRE ATT&CK Enterprise (v19.1) | Whole matrix | The enterprise matrix does not contain prompt-injection as a technique. AI-as-C2 (SesameOp pattern) is absent from ATT&CK as of mid-2026. Adversary emulation programs that are ATT&CK-only and not ATLAS-extended will not include the mid-2026 dominant new tradecraft in their playbooks. ATLAS v2026.06 covers it — but ATLAS is not yet a standard requirement for pen testing certification or scoping. |
+| MITRE ATT&CK Enterprise (v19.2) | Whole matrix | The enterprise matrix does not contain prompt-injection as a technique. AI-as-C2 (SesameOp pattern) is absent from ATT&CK as of mid-2026. Adversary emulation programs that are ATT&CK-only and not ATLAS-extended will not include the mid-2026 dominant new tradecraft in their playbooks. ATLAS v2026.07 covers it — but ATLAS is not yet a standard requirement for pen testing certification or scoping. |
 
 > Global coverage note: the above table spans US (NIST 800-115, ATT&CK), EU (NIS2, TIBER-EU under DORA), UK (CBEST), AU (ISM/Essential 8), and ISO 27001:2022. US-only pen test scoping is incomplete.
 
 ---
 
-## TTP Mapping (MITRE ATLAS v2026.06 + MITRE ATT&CK v19.1)
+## TTP Mapping (MITRE ATLAS v2026.07 + MITRE ATT&CK v19.2)
 
 Pen testers must emulate both classical and AI-class chains. The table below maps the kill-chain phases a mid-2026 adversary emulation engagement must cover.
 
-| Phase | Classical TTP (ATT&CK v19.1) | AI-Class TTP (ATLAS v2026.06) | Framework Gap Flag |
+| Phase | Classical TTP (ATT&CK v19.2) | AI-Class TTP (ATLAS v2026.07) | Framework Gap Flag |
 |---|---|---|---|
 | Reconnaissance | T1595 (Active Scanning) — implied by T1190 setup | AML.TA0002 (Reconnaissance tactic) — model card / dataset / API endpoint discovery, system-prompt probing | NIST 800-115 §3.x recon guidance is network-only |
 | Initial Access | T1190 (Exploit Public-Facing Application) | AML.T0051 (LLM Prompt Injection) — entered via PR description, support ticket, retrieved doc | OWASP WSTG covers webapp; not prompt-injection as entry vector |

package/skills/audit-log-integrity/skill.md

@@ -31,7 +31,7 @@ atlas_refs: []
 attack_refs:
   - T1070
   - T1565.001
-  - T1562.008
+  - T1685.002
 framework_gaps:
   - NIST-800-53-SI-2
   - ISO-27001-2022-A.8.15
@@ -57,7 +57,7 @@ Organisational logging controls require that events are recorded, protected, and
 
 ## TTP Mapping
 
-The audit-log integrity failures map to MITRE ATT&CK: **T1070 (Indicator Removal)** for deleting/rotating/truncating the trail, defeated by compliance-WORM + writer/custodian separation + honeytokens; **T1565.001 (Stored Data Manipulation)** for rewriting entries, defeated by verified hash-chaining + off-host signing; and **T1562.008 (Disable or Modify Cloud Logs / abuse of privileged access)** for break-glass misuse, defeated by dual control + independent alerting. The weakness classes are CWE-345 (insufficient verification of data authenticity — unverified chain), CWE-347 (improper signature verification — co-located/absent signing), CWE-284 (improper access control — governance-WORM, writer-can-delete), and CWE-778 (insufficient logging/detection — absent or untriaged honeytokens).
+The audit-log integrity failures map to MITRE ATT&CK: **T1070 (Indicator Removal)** for deleting/rotating/truncating the trail, defeated by compliance-WORM + writer/custodian separation + honeytokens; **T1565.001 (Stored Data Manipulation)** for rewriting entries, defeated by verified hash-chaining + off-host signing; and **T1685.002 (Disable or Modify Cloud Logs / abuse of privileged access)** for break-glass misuse, defeated by dual control + independent alerting. The weakness classes are CWE-345 (insufficient verification of data authenticity — unverified chain), CWE-347 (improper signature verification — co-located/absent signing), CWE-284 (improper access control — governance-WORM, writer-can-delete), and CWE-778 (insufficient logging/detection — absent or untriaged honeytokens).
 
 ## Exploit Availability Matrix
 
@@ -77,4 +77,4 @@ The recurring theater is "we log everything, so we have an audit trail," "our st
 
 ## Defensive Countermeasure Mapping
 
-Map findings to MITRE D3FEND: verified hash-chaining and off-host signing realise Message Authentication and Log Integrity (countering T1565.001); compliance-mode WORM and writer/custodian separation realise File Access Pattern Analysis and Access Modeling against deletion (countering T1070); dual-control + alerting on break-glass realises Administrative Account Monitoring (countering T1562.008); honeytokens realise Decoy Object / Connected Honeynet detection (high-fidelity evidence of the foraging access). Pair an external WORM/notary anchor with the on-host chain so even host compromise cannot rewrite history unobserved. The residual risk after these controls is multi-party collusion or compromise of the signing key / WORM authority itself, accepted at the CISO level with key-management oversight.
+Map findings to MITRE D3FEND: verified hash-chaining and off-host signing realise Message Authentication and Log Integrity (countering T1565.001); compliance-mode WORM and writer/custodian separation realise File Access Pattern Analysis and Access Modeling against deletion (countering T1070); dual-control + alerting on break-glass realises Administrative Account Monitoring (countering T1685.002); honeytokens realise Decoy Object / Connected Honeynet detection (high-fidelity evidence of the foraging access). Pair an external WORM/notary anchor with the on-host chain so even host compromise cannot rewrite history unobserved. The residual risk after these controls is multi-party collusion or compromise of the signing key / WORM authority itself, accepted at the CISO level with key-management oversight.

package/skills/cloud-iam-incident/skill.md

@@ -154,7 +154,7 @@ The playbook `cloud-iam-incident` operationalises this skill into a seven-phase
 | Wildcard federated trust policy abuse | (No native TTP — closest T1078.004) | ATT&CK Enterprise | GitHub Actions OIDC role with `repo:*` subject claim; fork-PR-to-takeover | No framework enumerates trust-policy condition specificity as a sub-control. UK CAF B2 outcome treats this as "control specification"; AU ISM-1546 is silent. |
 | Crypto-mining workload deployment post-compromise | (No native TTP — closest T1580 + T1496) | ATT&CK Enterprise | GPU instance spike in unused region; outbound traffic to known mining-pool ASNs | Detectable via billing + region anomaly + GPU-instance-family selection. No framework enumerates billing anomaly as a security signal. |
 | Help-desk social engineering for MFA reset | (Social engineering — no MITRE TTP for the SE step itself; result T1078) | ATT&CK Enterprise | Voice-clone + impersonation of authorised user; SE'd help-desk agent resets MFA | OOB-callback policy + voice-channel deepfake-resistant verification is operational; coverage fragmentary. Companion skill `identity-assurance` for AAL/FAL framing. |
-| Audit-log disablement for defence evasion | (No precise mapping — closest T1562.008 Cloud Logs) | ATT&CK Enterprise | StopLogging / DeleteTrail / DiagnosticSettingsDelete; sink redirection to attacker-controlled bucket | Detected via meta-event firing on the disable action. Absence-is-evidence: any account with logging currently disabled is a finding regardless of an observable disable event. |
+| Audit-log disablement for defence evasion | (No precise mapping — closest T1685.002 Cloud Logs) | ATT&CK Enterprise | StopLogging / DeleteTrail / DiagnosticSettingsDelete; sink redirection to attacker-controlled bucket | Detected via meta-event firing on the disable action. Absence-is-evidence: any account with logging currently disabled is a finding regardless of an observable disable event. |
 
 **Note on TTP coverage.** ATT&CK Enterprise covers cloud-IAM compromise reasonably well at the technique level. The gap is the chain shape — multi-step cross-account chains are not represented as first-class objects in either ATT&CK or ATLAS. Detection-strategy support (ATT&CK DSxxxx) for cloud techniques improves with v18-v19 releases but lags behavioural-graph monitoring.
 

package/skills/cloud-security/skill.md

@@ -131,8 +131,8 @@ Cloud is where AI runs. Every consequential AI service — OpenAI, Anthropic, Go
 | Cloud data exfiltration | T1530 — Data from Cloud Storage Object | ATT&CK Enterprise | Public S3 / GCS / Blob storage discovery via Wiz-style external attack-surface scan; legitimate IAM principal exfil via federated workload; cross-tenant boundary failure on SaaS | NIST 800-53 SC-28 (encryption at rest) does not address access-policy errors; CWE-200, CWE-732, CWE-862 |
 | Cloud-facing application | T1190 — Exploit Public-Facing Application | ATT&CK Enterprise | API Gateway / Load Balancer / managed-WAF-bypass; managed-database exposure (RDS / SQL DB / Cloud SQL public IP); container-registry public image abuse; Lambda / Cloud Functions / Azure Functions endpoint exploit | NIST 800-53 SC-7 perimeter assumption inadequate; CSA CCM AIS-04 and IVS-08 partial; CWE-1188 (Insecure Default Initialization) |
 | Cloud-credential exposure | T1552 — Unsecured Credentials (incl. T1552.001 Files, T1552.005 Cloud Instance Metadata API, T1552.007 Container API) | ATT&CK Enterprise | IMDSv1 SSRF on EC2 / GCE; static cloud credentials in git / images / env vars; container API and kubeconfig theft; workload-identity-federation trust-policy abuse | CWE-798 (hardcoded credentials), CWE-200; NIST 800-53 IA-5 method-neutral |
-| AI model registry / cloud-hosted model | AML.T0010 — ML Supply Chain Compromise | ATLAS v2026.06 | Bedrock / SageMaker custom model from poisoned upstream; Azure ML model registry tampering; Vertex Model Garden mirror tampering; HF model pulled into Bedrock / SageMaker / Vertex with weights backdoor | CSA CCM CCC-09 (vendor / supply chain) silent on model-supply-chain specifics; SLSA / in-toto / Sigstore for models still maturing |
-| Cloud inference API abuse / model extraction | AML.T0017 — Discover ML Model Ontology (inference-API probing for system-prompt, guardrail, model-family signal against cloud-hosted endpoints); AML.T0016 — Obtain Capabilities: Develop Capabilities (downstream weaponization) | ATLAS v2026.06 | Programmatic query of Bedrock / Azure OpenAI / Vertex endpoint to extract model behaviour, training-data inference, system-prompt leakage | No cloud-specific ATLAS control mapping for inference-API rate-limit / anomaly detection; chain to `ai-attack-surface` |
+| AI model registry / cloud-hosted model | AML.T0010 — ML Supply Chain Compromise | ATLAS v2026.07 | Bedrock / SageMaker custom model from poisoned upstream; Azure ML model registry tampering; Vertex Model Garden mirror tampering; HF model pulled into Bedrock / SageMaker / Vertex with weights backdoor | CSA CCM CCC-09 (vendor / supply chain) silent on model-supply-chain specifics; SLSA / in-toto / Sigstore for models still maturing |
+| Cloud inference API abuse / model extraction | AML.T0017 — Discover ML Model Ontology (inference-API probing for system-prompt, guardrail, model-family signal against cloud-hosted endpoints); AML.T0016 — Obtain Capabilities: Develop Capabilities (downstream weaponization) | ATLAS v2026.07 | Programmatic query of Bedrock / Azure OpenAI / Vertex endpoint to extract model behaviour, training-data inference, system-prompt leakage | No cloud-specific ATLAS control mapping for inference-API rate-limit / anomaly detection; chain to `ai-attack-surface` |
 
 **Note on ATT&CK Enterprise cloud-platform sub-techniques.** ATT&CK Enterprise has cloud-platform-specific matrices (IaaS, SaaS, Office 365, Azure AD / Entra ID, Google Workspace). T1078.004 (Cloud Accounts), T1552.005 (Cloud Instance Metadata API), T1552.007 (Container API), T1190 with cloud-service variants, T1530 with managed-storage variants are the most operationally relevant. The frontmatter pins the parent IDs; analysis should descend to the sub-technique appropriate to the cloud(s) in scope.
 

package/skills/compliance-theater/skill.md

@@ -78,7 +78,7 @@ The pre-analyzed gaps for these controls live in the framework-gap-analysis skil
 
 ---
 
-## TTP Mapping (MITRE ATLAS v2026.06 and ATT&CK)
+## TTP Mapping (MITRE ATLAS v2026.07 and ATT&CK)
 
 Each theater pattern below maps to one or more attacker TTPs in `data/atlas-ttps.json` and MITRE ATT&CK Enterprise. The mapping is what distinguishes theater from genuine compliance: a control claimed as compensating must map to a TTP it actually disrupts.
 
@@ -92,7 +92,7 @@ Each theater pattern below maps to one or more attacker TTPs in `data/atlas-ttps
 | Vendor/Third-Party Risk Theater — AI APIs (Pattern 6) | AML.T0010 (ML Supply Chain Compromise) | MCP servers and LLM APIs sit outside the vendor-management scope |
 | Security Awareness Theater — AI Phishing (Pattern 7) | T1566 (Phishing), AML.T0016 (Obtain Capabilities: Develop Capabilities — misuse of public AI APIs for payload crafting) | AI-generated content evades grammar/style heuristics and template-matching detectors |
 
-Source-of-truth TTP catalog: `data/atlas-ttps.json` (pinned to MITRE ATLAS v2026.06, May 2026). Any theater claim in an assessment must cite at least one TTP ID from that catalog or an ATT&CK Enterprise ID — claims without a mapped TTP are orphaned controls and are rejected.
+Source-of-truth TTP catalog: `data/atlas-ttps.json` (pinned to MITRE ATLAS v2026.07, May 2026). Any theater claim in an assessment must cite at least one TTP ID from that catalog or an ATT&CK Enterprise ID — claims without a mapped TTP are orphaned controls and are rejected.
 
 ---
 

package/skills/container-runtime-security/skill.md

@@ -124,9 +124,9 @@ State of standards baselines:
 | Container escape to host | T1611 — Escape to Host | ATT&CK Enterprise | Kernel LPE (Copy Fail CVE-2026-31431, Dirty Frag CVE-2026-43284 family); historical runc CVE-2024-21626 LeakyVessels family; cgroup v1 release_agent legacy abuses; abuse of overly permissive capabilities (`CAP_SYS_ADMIN`, `CAP_SYS_MODULE`) | NIST 800-190 predates kernel-LPE-as-container-escape as the dominant vector. Defense requires kernel patching cadence (hand off to `kernel-lpe-triage`) plus seccomp default profile, capability drops, read-only rootfs, and runtime detection. None of these are framework-mandated. |
 | Privilege escalation within the container | T1068 — Exploitation for Privilege Escalation | ATT&CK Enterprise | In-container kernel LPE (yields host root via T1611 chain); abuse of writable hostPath; abuse of mounted Docker socket | Method-neutral framework controls; the actual control is seccomp + dropped capabilities + read-only rootfs + non-root runAsUser, all enforced by PSS-Restricted profile |
 | Exploit public-facing K8s component | T1190 — Exploit Public-Facing Application | ATT&CK Enterprise | Exposed kube-apiserver (rare but seen on self-managed clusters); exposed kubelet read-only port (10255) or read/write port (10250) without authentication; exposed Kubernetes Dashboard with no auth; exposed Argo CD or Jenkins on the cluster; ingress controller CVEs (ingress-nginx CVE-2025 family) | NSA/CISA Hardening Guide v1.2 addresses control-plane exposure; managed services close this by default; self-managed clusters in CI/government still expose these |
-| Compromised container image at a public/private registry | AML.T0010 — ML Supply Chain Compromise (umbrella) | ATLAS v2026.06 | Poisoned base image; backdoored model-serving image; typosquatted MCP server in a sidecar; AI-pipeline-specific (KServe / vLLM / Triton image with embedded malicious payload) | ATLAS classifies; no framework mandates signature verification at admission. Hand off the build-side provenance to `supply-chain-integrity`; the container-runtime control is `ClusterImagePolicy` enforcement |
+| Compromised container image at a public/private registry | AML.T0010 — ML Supply Chain Compromise (umbrella) | ATLAS v2026.07 | Poisoned base image; backdoored model-serving image; typosquatted MCP server in a sidecar; AI-pipeline-specific (KServe / vLLM / Triton image with embedded malicious payload) | ATLAS classifies; no framework mandates signature verification at admission. Hand off the build-side provenance to `supply-chain-integrity`; the container-runtime control is `ClusterImagePolicy` enforcement |
 
-ATT&CK Containers matrix (sub-matrix, since 2021) and ATT&CK for Kubernetes (Microsoft's threat matrix, 2020, since absorbed conceptually into ATT&CK Containers) are both relevant prior art. The Enterprise IDs above are canonical in ATLAS v2026.06 alignment and pass the linter regex `^T\d{4}(\.\d{3})?$`.
+ATT&CK Containers matrix (sub-matrix, since 2021) and ATT&CK for Kubernetes (Microsoft's threat matrix, 2020, since absorbed conceptually into ATT&CK Containers) are both relevant prior art. The Enterprise IDs above are canonical in ATLAS v2026.07 alignment and pass the linter regex `^T\d{4}(\.\d{3})?$`.
 
 CWE cross-walk (see `data/cwe-catalog.json`):
 

package/skills/coordinated-vuln-disclosure/skill.md

@@ -106,7 +106,7 @@ This skill is meta — it is the upstream input pipeline that feeds the downstre
 |---|---|
 | `data/cve-catalog.json` | **Downstream product.** Every CVE in this catalog is the output of a CVD process (someone's, somewhere). When this org receives a report covering one of its own products, the resulting CVE enters this catalog via the same schema. |
 | `data/zeroday-lessons.json` | **Downstream consumer.** Every disclosed CVE feeds the zero-day learning loop run by `zeroday-gap-learn`. A CVD program with no entries here is not learning from its own disclosures. |
-| `data/atlas-ttps.json` (MITRE ATLAS v2026.06) | **Lookup for AI-class disclosures.** When a report covers an AI vulnerability, map the attack mechanism to an ATLAS TTP (e.g., AML.T0051 LLM Prompt Injection, AML.T0096 LLM Plugin Compromise) for advisory tagging. |
+| `data/atlas-ttps.json` (MITRE ATLAS v2026.07) | **Lookup for AI-class disclosures.** When a report covers an AI vulnerability, map the attack mechanism to an ATLAS TTP (e.g., AML.T0051 LLM Prompt Injection, AML.T0096 LLM Plugin Compromise) for advisory tagging. |
 | `data/framework-control-gaps.json` | **Lookup for regulator-notification routing.** Each disclosure intersects one or more framework controls; this skill writes new gaps when a disclosure exposes one. |
 | `data/cwe-catalog.json` | **Required taxonomy for advisories.** Per CVE-Numbering-Authority practice, every CVE advisory cites a CWE. `CWE-1357 Reliance on Insufficiently Trustworthy Component` is invoked for supply-chain disclosures (MCP servers, AI dependencies); other CWEs per the specific class. |
 | `data/d3fend-catalog.json` | **Defensive mapping for advisory recommendations.** Advisories that recommend mitigations should cite D3FEND IDs so blue teams can map the recommendation to existing control surfaces. See Defensive Countermeasure Mapping section. |

package/skills/defensive-countermeasure-mapping/skill.md

@@ -215,7 +215,7 @@ The skill produces a Defensive Countermeasure Map per input (CVE ID, ATLAS / ATT
 Example: "CVE — Linux kernel LPE. Canonical: CVE-2026-31431 (Copy Fail)."
 
 ## Offensive technique set (input to D3FEND query)
-- <AML.T0001-or-similar / T0001-or-similar / CWE-<id> list, with one-line descriptions>
+- <AML.T####-or-similar / T####-or-similar / CWE-<id> list, with one-line descriptions>
 
 ## Defensive-coverage map
 | D3FEND ID | Name | Tactic (DiD layer) | Privilege scope | ZT posture | Deployed? | AI-pipeline applicable? | Framework controls partially mapped | Live-tunable? |

package/skills/dlp-gap-analysis/skill.md

@@ -124,13 +124,13 @@ A DLP gap analysis that maps only to NIST 800-53 SC-7, ISO 27001:2022 A.8.16, HI
 
 ---
 
-## TTP Mapping (MITRE ATLAS v2026.06 + MITRE ATT&CK)
+## TTP Mapping (MITRE ATLAS v2026.07 + MITRE ATT&CK)
 
 | ID | Source | Technique | DLP Relevance | Gap Flag — Which DLP Control Fails |
 |---|---|---|---|---|
-| AML.T0096 | ATLAS v2026.06 | AI API as Covert C2 Channel | Direct: prompt and completion bodies as covert exfil. The same SesameOp pattern that is a C2 channel is also a DLP exfil channel — prompts encode payloads against allowlisted AI provider domains. Cross-references `DLP-CHAN-LLM-PROMPT` and `DLP-CHAN-LLM-CONTEXT` in `data/dlp-controls.json`. | Legacy email/web/USB DLP (`DLP-CHAN-EMAIL-OUT`, `DLP-CHAN-WEB-UPLOAD`, `DLP-CHAN-USB-REMOVABLE`) sees nothing. AI-aware DLP (`DLP-CHAN-LLM-PROMPT`) is the only effective control category. SC-7 boundary controls allowlist the AI provider domain — no protocol or destination anomaly fires. |
-| AML.T0017 | ATLAS v2026.06 | Discover ML Model Ontology | Indirect but DLP-relevant: model inversion and membership-inference attacks against embedding stores and fine-tuned models extract training-corpus content (which is itself a protected surface — see `DLP-SURFACE-TRAINING-DATA`, `DLP-SURFACE-EMBEDDING-STORE`). | No legacy DLP control category exists. Modern controls: embedding-similarity classification at retrieval boundary (`DLP-CLASS-EMBEDDING-MATCH`), differential-privacy fine-tuning, query-rate limits on inference APIs. None of these are named in any compliance framework. |
-| AML.T0051 | ATLAS v2026.06 | LLM Prompt Injection | Direct: prompt-injection-induced data extraction. A malicious document in a RAG corpus or a poisoned tool output (MCP) coerces the model into emitting protected content in a subsequent response. Cross-references `DLP-CHAN-LLM-CONTEXT` and `DLP-CHAN-MCP-TOOL-ARG`. | Egress-side classification on model output catches some cases but is fundamentally retroactive. Retrieval-time classification (`DLP-SURFACE-RAG-CORPUS`) and MCP tool-call argument inspection (`DLP-CHAN-MCP-TOOL-ARG`) are the primary controls. No compliance framework names either. |
+| AML.T0096 | ATLAS v2026.07 | AI API as Covert C2 Channel | Direct: prompt and completion bodies as covert exfil. The same SesameOp pattern that is a C2 channel is also a DLP exfil channel — prompts encode payloads against allowlisted AI provider domains. Cross-references `DLP-CHAN-LLM-PROMPT` and `DLP-CHAN-LLM-CONTEXT` in `data/dlp-controls.json`. | Legacy email/web/USB DLP (`DLP-CHAN-EMAIL-OUT`, `DLP-CHAN-WEB-UPLOAD`, `DLP-CHAN-USB-REMOVABLE`) sees nothing. AI-aware DLP (`DLP-CHAN-LLM-PROMPT`) is the only effective control category. SC-7 boundary controls allowlist the AI provider domain — no protocol or destination anomaly fires. |
+| AML.T0017 | ATLAS v2026.07 | Discover ML Model Ontology | Indirect but DLP-relevant: model inversion and membership-inference attacks against embedding stores and fine-tuned models extract training-corpus content (which is itself a protected surface — see `DLP-SURFACE-TRAINING-DATA`, `DLP-SURFACE-EMBEDDING-STORE`). | No legacy DLP control category exists. Modern controls: embedding-similarity classification at retrieval boundary (`DLP-CLASS-EMBEDDING-MATCH`), differential-privacy fine-tuning, query-rate limits on inference APIs. None of these are named in any compliance framework. |
+| AML.T0051 | ATLAS v2026.07 | LLM Prompt Injection | Direct: prompt-injection-induced data extraction. A malicious document in a RAG corpus or a poisoned tool output (MCP) coerces the model into emitting protected content in a subsequent response. Cross-references `DLP-CHAN-LLM-CONTEXT` and `DLP-CHAN-MCP-TOOL-ARG`. | Egress-side classification on model output catches some cases but is fundamentally retroactive. Retrieval-time classification (`DLP-SURFACE-RAG-CORPUS`) and MCP tool-call argument inspection (`DLP-CHAN-MCP-TOOL-ARG`) are the primary controls. No compliance framework names either. |
 | T1567 | ATT&CK | Exfiltration Over Web Service | LLM and AI API endpoints are exactly the "legitimate web service used for exfil" pattern, pre-allowlisted in nearly every enterprise. | SC-7 sees only the destination domain (allowlisted). SDK-level prompt logging with identity binding is the only practical control. |
 | T1530 | ATT&CK | Data from Cloud Storage Object | Includes vector stores and model registries — embedding stores (Pinecone, Weaviate, Qdrant, pgvector, Vertex AI Matching Engine) and model artifacts in cloud object stores are 2026's high-value crown-jewel surface. See `DLP-SURFACE-EMBEDDING-STORE` and `DLP-SURFACE-TRAINING-DATA`. | Cloud DLP scanning of object stores is mature for files but not for vector indexes — index payloads are not classifiable as files. Vector-store-native ACL audit is the practical control. |
 | T1213 | ATT&CK | Data from Information Repositories | RAG corpora are exactly information repositories (SharePoint, Confluence, GitHub, Drive) ingested into vector indexes. Cross-cleared retrieval is a confused-deputy exfil channel. See `DLP-SURFACE-RAG-CORPUS`. | Repository-side ACL enforcement does not propagate to RAG context. Retrieval-time classification with user-clearance check is required (`DLP-CHAN-LLM-CONTEXT`). |

package/skills/exploit-scoring/skill.md

@@ -76,7 +76,7 @@ This skill is meta — it does not pin to a single TTP class. RWEP is the cross-
 | Catalog | Role for RWEP |
 |---|---|
 | `data/cve-catalog.json` | Source of factor values: CISA KEV flag, PoC availability, AI-discovery flag, active-exploitation status, patch and live-patch availability per CVE |
-| `data/atlas-ttps.json` (MITRE ATLAS v2026.06) | Provides the AI/ML TTP context where AI-discovery and AI-acceleration factors apply (e.g., AML.T0016 Obtain Capabilities: Develop Capabilities, AML.T0017 Discover ML Model Ontology) |
+| `data/atlas-ttps.json` (MITRE ATLAS v2026.07) | Provides the AI/ML TTP context where AI-discovery and AI-acceleration factors apply (e.g., AML.T0016 Obtain Capabilities: Develop Capabilities, AML.T0017 Discover ML Model Ontology) |
 | `data/exploit-availability.json` | Authoritative PoC + KEV + last-verified date snapshot — drives factor freshness |
 | `data/zeroday-lessons.json` | Closes the loop: zero-day's lesson entry feeds back the framework gap that RWEP's score implied |
 

package/skills/framework-gap-analysis/skill.md

@@ -66,14 +66,14 @@ The global-first requirement binds against the full expanded catalog, not the EU
 - **China (CN):** PIPL, DSL, CSL, Cybersecurity Review Measures (2022).
 - **Brazil (BR):** LGPD + ANPD guidance.
 - **Saudi Arabia (KSA):** PDPL + SDAIA Implementing Regulation 2023.
-- **Global standards:** ISO 27001:2022 / 27002:2022, ISO/IEC 42001:2023, CSA CCM v4, CIS Controls v8, MITRE ATLAS v2026.06.
+- **Global standards:** ISO 27001:2022 / 27002:2022, ISO/IEC 42001:2023, CSA CCM v4, CIS Controls v8, MITRE ATLAS v2026.07.
 - **US sub-national:** NYDFS 23 NYCRR 500 (amended Nov 2023, phased through Nov 2025); state privacy laws (CA CCPA/CPRA, CO CPA, CT CTDPA, IL BIPA, NY SHIELD, TX DPSA, VA CDPA).
 
 A gap declaration that closes section 6 (Global coverage check) without referencing at least the EU, UK, AU, ISO, and a representative selection from {IL, CH, HK, TW, ID, VN, JP-expanded, KR, CN, BR, NYDFS} for any org operating in those jurisdictions is incomplete: a global-first analysis must cover every applicable jurisdiction, not a US-centric subset. The exact set required depends on the org's footprint — but the analyst must consult `data/global-frameworks.json` to enumerate it rather than defaulting to the legacy four-jurisdiction shorthand.
 
-## TTP Mapping (MITRE ATLAS v2026.06 and ATT&CK)
+## TTP Mapping (MITRE ATLAS v2026.07 and ATT&CK)
 
-This skill maps framework controls to attacker TTPs on demand rather than statically. The authoritative TTP catalog is `data/atlas-ttps.json` (pinned to MITRE ATLAS v2026.06, May 2026) supplemented by MITRE ATT&CK Enterprise IDs for non-AI threats. The mapping convention used in every gap declaration this skill produces:
+This skill maps framework controls to attacker TTPs on demand rather than statically. The authoritative TTP catalog is `data/atlas-ttps.json` (pinned to MITRE ATLAS v2026.07, May 2026) supplemented by MITRE ATT&CK Enterprise IDs for non-AI threats. The mapping convention used in every gap declaration this skill produces:
 
 | Built-in gap | Primary TTP(s) | Gap flag |
 |---|---|---|

package/skills/fuzz-testing-strategy/skill.md

@@ -87,7 +87,7 @@ By mid-2026 the asymmetry between offensive and defensive fuzzing has flipped. T
 
 ---
 
-## TTP Mapping (MITRE ATLAS v2026.06 + MITRE ATT&CK Enterprise)
+## TTP Mapping (MITRE ATLAS v2026.07 + MITRE ATT&CK Enterprise)
 
 Fuzz is a pre-exploit control: it surfaces weaknesses before they leave the build pipeline. Mapping is via the weakness root cause (CWE) rather than the post-exploit technique.
 

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

@@ -62,7 +62,7 @@ last_threat_review: "2026-06-10"
 
 Incident response (IR) is the operational closure of every other skill in this catalog. A vulnerability becomes a CVE through `coordinated-vuln-disclosure`; a CVE becomes a lesson through `zeroday-gap-learn`; a lesson becomes a control through `framework-gap-analysis`; an attack on that control becomes an incident — and the incident handler runs the playbook this skill defines. If the playbook is wrong, every preceding investment leaks at the last yard.
 
-This skill operationalizes NIST SP 800-61r3 (Computer Security Incident Handling Guide, 2025 update integrating ATT&CK and Cyber Kill Chain), ISO/IEC 27035-1:2023 (principles and process) + ISO/IEC 27035-2:2023 (guidelines for incident response planning), and the SANS PICERL phases (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned). It threads the Diamond Model and the MITRE Unified Kill Chain for adversary-narrative reconstruction, anchors detection engineering to MITRE ATT&CK v19.1 (May 2026), and treats three incident classes that the legacy IR literature predates: AI-class incidents (prompt-injection breach, model exfiltration, AI-API as C2 channel, AI-agent-initiated unauthorized action), AI-generated supply-chain compromise, and regulator-mandated notification under cross-jurisdiction clocks running in parallel.
+This skill operationalizes NIST SP 800-61r3 (Computer Security Incident Handling Guide, 2025 update integrating ATT&CK and Cyber Kill Chain), ISO/IEC 27035-1:2023 (principles and process) + ISO/IEC 27035-2:2023 (guidelines for incident response planning), and the SANS PICERL phases (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned). It threads the Diamond Model and the MITRE Unified Kill Chain for adversary-narrative reconstruction, anchors detection engineering to MITRE ATT&CK v19.2 (May 2026), and treats three incident classes that the legacy IR literature predates: AI-class incidents (prompt-injection breach, model exfiltration, AI-API as C2 channel, AI-agent-initiated unauthorized action), AI-generated supply-chain compromise, and regulator-mandated notification under cross-jurisdiction clocks running in parallel.
 
 ---
 
@@ -91,7 +91,7 @@ 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 / T0096 / T0017. |
+| 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. |
 | 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. |
@@ -128,7 +128,7 @@ This skill is response-shaped — the TTPs below name the incident classes the p
 | **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.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.06 (June 2026). ATT&CK pinned to v19.1 (May 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.
+ATLAS pinned to v2026.07 (August 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.
 
 ---
 
@@ -162,7 +162,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 / T0017 / 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.T0017 / 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`.
@@ -192,7 +192,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/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.T0017. 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
@@ -500,7 +500,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 / T0017 / 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.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 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.
 
@@ -521,7 +521,7 @@ IR consumes defensive controls across multiple D3FEND categories; the four cited
 | **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-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 / T0017 / 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.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.
 
 **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.
 

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

@@ -165,7 +165,7 @@ Every MCP server listed in popular registries (MCP Hub, npm `@modelcontextprotoc
 |---|---|---|---|
 | AML.T0010 | ML 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.06 |
+| 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.07 |
 | 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 |

package/skills/mlops-security/skill.md

@@ -60,7 +60,7 @@ forward_watch:
   - OpenSSF model-signing emergence to v1.0 — Sigstore-based model-weight signing; track for production adoption and admission-control integration
   - SLSA v1.1 ML profile (draft) — model-provenance extension for training-run attestation chains; track ID and section changes
   - EU AI Act high-risk technical-file implementing acts (2026-2027) — operational requirements for Article 10 / 13 / 15 documentation may pin ML-BOM or model-signing
-  - MITRE ATLAS v2026.06 (released June 2026) is additive over v2026.05 — it adds AML.T0113 (Steal Web Session Cookie), AML.T0091.001 (Use Alternate Authentication Material: Web Session Cookie), and AML.T0114 (AI Service Web Interface) and refreshes AML.T0054 (LLM Jailbreak), with no technique-ID removals. Earlier releases shipped the AML.T0010 sub-technique expansion and agentic-AI techniques ("Publish Poisoned AI Agent Tool", "Escape to Host") this forecast tracked. Forward watch: subsequent monthly ATLAS releases — track next-cadence updates to agentic-AI TTPs and MLOps-pipeline-specific techniques
+  - MITRE ATLAS v2026.07 (released June 2026) is additive over v2026.05 — it adds AML.T0113 (Steal Web Session Cookie), AML.T0091.001 (Use Alternate Authentication Material: Web Session Cookie), and AML.T0114 (AI Service Web Interface) and refreshes AML.T0054 (LLM Jailbreak), with no technique-ID removals. Earlier releases shipped the AML.T0010 sub-technique expansion and agentic-AI techniques ("Publish Poisoned AI Agent Tool", "Escape to Host") this forecast tracked. Forward watch: subsequent monthly ATLAS releases — track next-cadence updates to agentic-AI TTPs and MLOps-pipeline-specific techniques
 last_threat_review: "2026-06-10"
 discovery_mode: "standalone"  # operator-reached via `exceptd brief mlops-security` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
 ---
@@ -111,13 +111,13 @@ This skill is distinct from `rag-pipeline-security` (which is retrieval-side of
 
 ## TTP Mapping
 
-Descriptions sourced from `data/atlas-ttps.json` (ATLAS v2026.06, released 2026-06-30).
+Descriptions sourced from `data/atlas-ttps.json` (ATLAS v2026.07, released 2026-06-30).
 
 | ATLAS / ATT&CK ID | Technique | MLOps Lifecycle Stage | Gap |
 |---|---|---|---|
 | AML.T0010 | ML Supply Chain Compromise (sub-techniques: GPU Firmware, ML Framework, Model Repository, MCP Server) | Cross-cutting — touches every ingestion point: dependencies in training environment (AML.T0010.001), model pulls from Hugging Face / vendor registries (AML.T0010.002), MCP plugins in dev tooling (AML.T0010.003) | No framework mandates registry-side cryptographic verification of all ingested artifacts; the SLSA-style attestation chain for ML artifacts is draft, not required |
 | 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. Sub-technique AML.T0020.002 is RAG-side (see `rag-pipeline-security`); AML.T0020.000 / 001 are MLOps-side. | 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.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) |
 | 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 |

package/skills/ot-ics-security/skill.md

@@ -24,7 +24,7 @@ data_deps:
 atlas_refs:
   - AML.T0010
 attack_refs:
-  - T0855
+  - T1692.001
   - T0883
   - T1190
   - T1068
@@ -93,18 +93,18 @@ ATT&CK for ICS is a separate matrix from Enterprise. Many IT-rooted SOCs do not
 | Surface | TTP | Matrix | Variant in mid-2026 | Gap Flag |
 |---|---|---|---|---|
 | Internet-exposed control-system asset | T0883 — Internet Accessible Device | ATT&CK for ICS | HMI/PLC reachable via Shodan/Censys; default-cred VNC; vendor remote-support tooling exposed | IEC 62443-3-3 SR 5.1 (network segmentation) presumes a perimeter that does not exist for vendor-mediated remote access |
-| Unauthorized control command | T0855 — Unauthorized Command Message | ATT&CK for ICS | Modbus/TCP, DNP3, S7, EtherNet/IP write to coil/register without authentication | CWE-306 (Missing Authentication) and CWE-287 (Improper Authentication) baked into protocols; IEC 62443-3-3 SR 1.1/1.2 (identification & authentication) cannot be enforced at L1 protocol layer |
+| Unauthorized control command | T1692.001 — Unauthorized Command Message | ATT&CK for ICS | Modbus/TCP, DNP3, S7, EtherNet/IP write to coil/register without authentication | CWE-306 (Missing Authentication) and CWE-287 (Improper Authentication) baked into protocols; IEC 62443-3-3 SR 1.1/1.2 (identification & authentication) cannot be enforced at L1 protocol layer |
 | Lateral movement within OT | T0867 — Lateral Tool Transfer | ATT&CK for ICS | Engineering workstation → HMI → PLC programming-software pivot | NIST 800-82r3 segmentation guidance does not specify L2/L1 micro-segmentation; AESCSF MIL-1 tolerates flat L2 |
 | OT scripting | T0853 — Scripting | ATT&CK for ICS | PowerShell on engineering workstation; vendor-tool macro; LLM-generated PLC code reviewed only by overworked engineer | No framework requires diff-review of AI-generated control logic |
 | IT-side initial access pivoting to OT | T1190 — Exploit Public-Facing Application | ATT&CK Enterprise | Historian (PI Vision), MES web UI, vendor remote-portal web app | NIST 800-53 SC-7 perimeter assumption does not address IT→OT pivot chain |
 | HMI host LPE | T1068 — Exploitation for Privilege Escalation | ATT&CK Enterprise | Windows 7/10 HMI host; un-rebootable; Copy Fail (CVE-2026-31431) on any Linux HMI; Print Spooler / win32k LPE family on Windows HMIs | IT patch SLAs (30 day) inapplicable to HMI hosts; no compensating-control baseline in NIST 800-82r3 |
 | Hard-coded / shared credentials | CWE-798 | CWE | Vendor default creds on PLC web UI; shared "operator" account across HMI fleet | IEC 62443-3-3 SR 1.5 (authenticator management) cannot land on devices that lack per-user accounts; NERC CIP-007-6 R5 password-management partially addresses but exempts cyber-asset classes lacking user-account features |
 | Firmware-image integrity | CWE-1037 (Processor Optimization Removal or Modification of Security-Critical Code) and CWE-345 family (insufficient verification of data authenticity, captured via cve-catalog supply-chain entries) | CWE | Unsigned firmware accepted by L1 device; vendor-side build pipeline compromise | NERC CIP-010 baseline-change management does not require firmware-image signature verification at install time |
-| AI-assistant prompt injection in HMI/engineering workflow | AML.T0010 — ML Supply Chain Compromise (closest existing ATLAS entry) | ATLAS v2026.06 | Crafted historian tag value or vendor PDF poisons context; LLM proposes unsafe setpoint or misleads operator | No ATT&CK for ICS technique for AI-mediated operator deception; no IEC 62443 control on AI conduit; NIST 800-82r3 silent |
+| AI-assistant prompt injection in HMI/engineering workflow | AML.T0010 — ML Supply Chain Compromise (closest existing ATLAS entry) | ATLAS v2026.07 | Crafted historian tag value or vendor PDF poisons context; LLM proposes unsafe setpoint or misleads operator | No ATT&CK for ICS technique for AI-mediated operator deception; no IEC 62443 control on AI conduit; NIST 800-82r3 silent |
 
-**Note on ATT&CK for ICS ID format.** ATT&CK for ICS uses `T0xxx` IDs (e.g., T0855, T0883, T0867). The linter regex `^T\d{4}(\.\d{3})?$` accepts this shape. For IT/OT convergence techniques (the IT side of the pivot), ATT&CK Enterprise IDs (T1190, T1068, T1078) are cited alongside.
+**Note on ATT&CK for ICS ID format.** ATT&CK for ICS uses `T0xxx` IDs (e.g., T1692.001, T0883, T0867). The linter regex `^T\d{4}(\.\d{3})?$` accepts this shape. For IT/OT convergence techniques (the IT side of the pivot), ATT&CK Enterprise IDs (T1190, T1068, T1078) are cited alongside.
 
-**Note on ATLAS coverage.** AML.T0010 (ML Supply Chain Compromise) is the closest current ATLAS v2026.06 mapping for AI-augmented-HMI threats; it does not specifically cover prompt-injection-as-operator-deception in a control room. This is a tracked ATLAS gap — see `forward_watch`.
+**Note on ATLAS coverage.** AML.T0010 (ML Supply Chain Compromise) is the closest current ATLAS v2026.07 mapping for AI-augmented-HMI threats; it does not specifically cover prompt-injection-as-operator-deception in a control room. This is a tracked ATLAS gap — see `forward_watch`.
 
 ---
 

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

@@ -88,7 +88,7 @@ This skill's exceptions exist precisely because the framework language has not c
 
 ---
 
-## TTP Mapping (MITRE ATLAS v2026.06 and ATT&CK)
+## TTP Mapping (MITRE ATLAS v2026.07 and ATT&CK)
 
 A granted exception does not remove the threat — it shifts the burden onto compensating controls. For each exception in this skill, the residual TTPs the compensating controls MUST still disrupt:
 
@@ -99,7 +99,7 @@ A granted exception does not remove the threat — it shifts the burden onto com
 | Exception 3 — Zero Trust Architecture Network Segmentation | T1021 (Remote Services), T1570 (Lateral Tool Transfer), T1078 (Valid Accounts), T1199 (Trusted Relationship) | Workload identity (SPIFFE/SPIRE), per-request mTLS, device-posture verification, east-west behavioral analytics |
 | Exception 4 — Critical Systems No-Reboot Kernel Patching | T1068 (Exploitation for Privilege Escalation — Copy Fail class), T1548.001 (Setuid and Setgid), T1611 (Escape to Host) | Live kernel patch deployed and verified (`kpatch list` / `canonical-livepatch status`), eBPF/auditd exploitation-pattern rules, network-layer isolation if no live patch available, scheduled reboot window |
 
-The TTP source-of-truth is `data/atlas-ttps.json` (MITRE ATLAS v2026.06, May 2026) supplemented by ATT&CK Enterprise. No orphaned controls: no exception in this skill is granted without an enumerated residual-TTP set; an exception with no listed residual is theater.
+The TTP source-of-truth is `data/atlas-ttps.json` (MITRE ATLAS v2026.07, May 2026) supplemented by ATT&CK Enterprise. No orphaned controls: no exception in this skill is granted without an enumerated residual-TTP set; an exception with no listed residual is theater.
 
 ---
 

package/skills/pqc-first/skill.md

@@ -140,7 +140,7 @@ This skill addresses a **future-state attack class** that is not yet represented
 |---|---|---|
 | MITRE ATT&CK T1557 (Adversary-in-the-Middle) | Partial — operational family | T1557 covers AitM credential capture and traffic interception. The capture half of HNDL falls into T1557 operationally; the later decrypt phase has no ATT&CK technique. |
 | MITRE ATT&CK T1040 (Network Sniffing) | Partial — capture phase | Covers passive traffic capture. Does not cover the strategic-archive intent of HNDL, where the captured data has no immediate use and is stored for future decryption. |
-| MITRE ATT&CK — "Cryptanalysis via CRQC" | **MISSING** | No technique presently captures CRQC-enabled decryption of previously-captured ciphertext. Known gap through ATT&CK v19.1 (May 2026). |
+| MITRE ATT&CK — "Cryptanalysis via CRQC" | **MISSING** | No technique presently captures CRQC-enabled decryption of previously-captured ciphertext. Known gap through ATT&CK v19.2 (May 2026). |
 | MITRE ATLAS | **MISSING (out of scope)** | ATLAS scope is ML/AI system attacks. CRQC cryptanalysis is not in ATLAS scope. |
 | CAPEC-114 (Authentication Abuse) | Indirect | Forged signatures via broken signature scheme would manifest as authentication abuse, but CAPEC does not enumerate "signature scheme broken by CRQC" as a precondition. |
 | CAPEC-475 (Signature Spoofing by Improper Validation) | Indirect | Same — the post-CRQC equivalent has no CAPEC entry. |

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

@@ -182,13 +182,13 @@ This attack requires:
 
 ---
 
-## TTP Mapping (MITRE ATLAS v2026.06)
+## TTP Mapping (MITRE ATLAS v2026.07)
 
-Descriptions sourced verbatim from `data/atlas-ttps.json` (ATLAS v2026.06, released 2026-06-30). Partial-coverage controls from `data/framework-control-gaps.json`.
+Descriptions sourced verbatim from `data/atlas-ttps.json` (ATLAS v2026.07, released 2026-06-30). Partial-coverage controls from `data/framework-control-gaps.json`.
 
 | ATLAS ID | ATLAS Name | RAG Attack Class | Control Gap That Lets It Land | Controls That Partially Cover It |
 |---|---|---|---|---|
-| AML.T0020 | Poison Training Data (incl. sub-technique AML.T0020.002 — RAG Knowledge Base Poisoning) | Vector store poisoning (Attack Class 2): adversary injects malicious documents into the retrieval corpus — either behavioral instructions or false facts | Data integrity controls (SI-7, SI-12) are designed for traditional structured data. No framework requires integrity monitoring of vector store contents, embedding distribution shift detection, or hash-based verification of knowledge-base documents. Ingestion pipelines accept unstructured content by design. | NIST-800-53-SI-7, NIST-800-53-SI-12 (both partial — neither covers embedding-space integrity); ALL-AI-PIPELINE-INTEGRITY (universal gap, no framework has the control) |
+| AML.T0020 | Poison Training Data — ATLAS carries no sub-technique for the RAG knowledge-base variant, which this skill treats as its own attack class | Vector store poisoning (Attack Class 2): adversary injects malicious documents into the retrieval corpus — either behavioral instructions or false facts | Data integrity controls (SI-7, SI-12) are designed for traditional structured data. No framework requires integrity monitoring of vector store contents, embedding distribution shift detection, or hash-based verification of knowledge-base documents. Ingestion pipelines accept unstructured content by design. | NIST-800-53-SI-7, NIST-800-53-SI-12 (both partial — neither covers embedding-space integrity); ALL-AI-PIPELINE-INTEGRITY (universal gap, no framework has the control) |
 | AML.T0043 | Craft Adversarial Data | Embedding manipulation for data exfiltration (Attack Class 1): adversary crafts queries whose embeddings land near sensitive document embeddings, forcing retrieval | No framework requires adversarial-robustness testing for retrieval engines. SI-3 (malicious code protection) does not contemplate adversarial inputs to embedding models. Access control models (AC-3) operate on identified resources, not embedding-similarity-fragments. | NIST-800-53-SI-3, NIST-AI-RMF-MEASURE-2.5 (both partial — neither covers retrieval-engine adversarial robustness) |
 | AML.T0051 | LLM Prompt Injection (incl. AML.T0051.001 — Indirect Prompt Injection) | Indirect prompt injection via retrieved documents (Attack Class 5): adversarial instructions stored in the knowledge base execute in the LLM's context when retrieved | No framework has a control for prompt injection as an access control failure. The AI agent's service account is properly authorized — AC-2's perspective sees the access as legitimate. ATLAS documents the technique; no framework implements controls. Universal gap `ALL-PROMPT-INJECTION-ACCESS-CONTROL` is open. | NIST-800-53-AC-2 (partial — does not surface model-mediated unauthorized action); ISO-27001-2022-A.8.28 (partial — secure coding scope does not include semantic vulnerabilities); ALL-PROMPT-INJECTION-ACCESS-CONTROL (universal gap) |
 | AML.T0054 | LLM Jailbreak / Craft Adversarial Data — NLP | Retrieval filter bypass (Attack Class 4) and chunking exploitation (Attack Class 3): semantic border crossing, namespace confusion, split-and-reassemble of sensitive content across chunks | No framework requires safety-guardrail testing for retrieval-augmented systems. NIST AI RMF recommends adversarial testing but does not require it. Filter-application-order (pre-similarity vs. post-similarity) is not addressed by any control. | NIST-AI-RMF-GOVERN-1.7 (partial — recommends but does not require red-team testing); NIST-800-53-SI-12 (partial — retention only, not retrieval scope) |
@@ -198,7 +198,7 @@ Descriptions sourced verbatim from `data/atlas-ttps.json` (ATLAS v2026.06, relea
 
 ## Exploit Availability Matrix
 
-**No CVE catalog entry as of 2026-05 maps directly to RAG embedding manipulation, vector store poisoning, or RAG indirect prompt injection.** These attack classes are tracked via MITRE ATLAS TTPs (v2026.06) and public incident reporting rather than vendor CVEs, because they exploit architectural properties of the RAG pattern rather than a single vendor's implementation flaw. `data/exploit-availability.json` therefore has no RAG-specific rows; the rows below source ATLAS `real_world_instances` and the framework-gap entries.
+**No CVE catalog entry as of 2026-05 maps directly to RAG embedding manipulation, vector store poisoning, or RAG indirect prompt injection.** These attack classes are tracked via MITRE ATLAS TTPs (v2026.07) and public incident reporting rather than vendor CVEs, because they exploit architectural properties of the RAG pattern rather than a single vendor's implementation flaw. `data/exploit-availability.json` therefore has no RAG-specific rows; the rows below source ATLAS `real_world_instances` and the framework-gap entries.
 
 | ATLAS Technique | PoC / Public Demo Available? | CISA KEV? | AI-Accelerated? | Patch Available? | Reboot / Version Bump Required? |
 |---|---|---|---|---|---|