@blamejs/exceptd-skills 0.19.1 → 0.19.2

package/scripts/check-version-tags.js

@@ -104,18 +104,32 @@ const COMMENT_EXEMPT = new Set([
 // need to name individual local-only files. Untracked-but-NOT-ignored files
 // ARE still scanned: a new file a contributor is about to commit is exactly
 // what the gate must catch. Computed via `git check-ignore` over the walked set.
+// Returns the ignored subset, or NULL when git cannot answer.
+//
+// "No path matched" and "the question could not be asked" are different
+// results and must not collapse into the same empty set. Without a repository
+// — a build context that omits .git/, or git not installed — an empty set
+// silently reclassifies every local-only file as part of the shipped surface,
+// so the gate reports violations in files a clone never contains. Returning
+// null lets the caller say it could not determine the surface instead of
+// asserting a wrong one.
 function gitIgnoredSet(relPaths) {
   if (!relPaths.length) return new Set();
   try {
     const out = execFileSync("git", ["check-ignore", "--stdin"], {
       cwd: ROOT, input: relPaths.join("\n"), encoding: "utf8", maxBuffer: 64 * 1024 * 1024,
+      stdio: ["pipe", "pipe", "pipe"],
     });
     return new Set(out.split(/\r?\n/).filter(Boolean));
   } catch (e) {
-    // `git check-ignore --stdin` exits 1 when NO path is ignored (not an
-    // error); any paths it did match are on stdout. Absent that, none ignored.
+    // Exit 1 with no stderr is git's way of saying "no path matched" — a real
+    // answer, and an empty set is correct. Anything else (git missing, not a
+    // repository, .git absent) means the question went unanswered.
+    const status = e && typeof e.status === "number" ? e.status : null;
+    const stderr = e && e.stderr ? String(e.stderr).trim() : "";
     const out = e && e.stdout ? String(e.stdout) : "";
-    return new Set(out.split(/\r?\n/).filter(Boolean));
+    if (status === 1 && !stderr) return new Set(out.split(/\r?\n/).filter(Boolean));
+    return null;
   }
 }
 
@@ -185,12 +199,16 @@ function countLineViolations(rel) {
 function scanCurrent() {
   const files = walk(ROOT);
   const ignored = gitIgnoredSet(files);
+  // Without git the shipped surface is unknowable: local-only files are
+  // indistinguishable from tracked ones, so any result would be a guess.
+  // Report that rather than emit findings the baseline cannot be compared to.
+  if (ignored === null) return { byFile: {}, filenameViolations: [], surfaceUnknown: true };
   const byFile = {};
   const filenameViolations = [];
   for (const rel of files) {
-    // Skip git-ignored, local-only files (a contributor's private working notes
-    // that `git clone` never ships). Untracked-but-not-ignored files are still
-    // scanned — a new file about to be committed is what the gate guards.
+    // Skip git-ignored, local-only files that `git clone` never ships.
+    // Untracked-but-not-ignored files are still scanned — a new file about to
+    // be committed is exactly what the gate guards.
     if (ignored.has(rel)) continue;
     if (FILENAME_VERSION_RE.test(rel)) filenameViolations.push(rel);
     const n = countLineViolations(rel);
@@ -229,6 +247,32 @@ function main() {
   const wantUpdate = process.argv.includes("--update-baseline");
   const current = scanCurrent();
 
+  if (current.surfaceUnknown) {
+    // Never write a baseline from a scan that could not tell shipped files from
+    // local ones — that would bake the wrong surface in permanently.
+    //
+    // Automation is the one place this must not degrade to a skip. This gate
+    // runs inside predeploy, and predeploy guards the publish job, so a
+    // silently-skipped run there stops enforcing on exactly the path that
+    // ships. Locally — a container built without .git, a tarball inspection —
+    // skipping is the honest answer, because the shipped surface genuinely is
+    // not knowable there and failing would only punish the harness.
+    const inAutomation = process.env.CI === "true" || !!process.env.GITHUB_ACTIONS;
+    if (inAutomation) {
+      console.error("[check-version-tags] FAIL — no git repository available, so the shipped");
+      console.error("  surface cannot be determined. In automation this is a failure, not a skip:");
+      console.error("  this gate runs inside predeploy, which guards publishing. Ensure the job");
+      console.error("  checks out git metadata (actions/checkout provides it by default).");
+      process.exitCode = 2;
+      return;
+    }
+    console.error("[check-version-tags] SKIPPED — no git repository available, so the shipped");
+    console.error("  surface cannot be determined. This is not a pass; run it where git metadata");
+    console.error("  is present. In CI the same condition fails instead.");
+    process.exitCode = 0;
+    return;
+  }
+
   if (wantUpdate) {
     writeBaseline(current);
     process.exitCode = 0;

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/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/incident-response-playbook/skill.md

@@ -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. |
@@ -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/mlops-security/skill.md

@@ -117,7 +117,7 @@ Descriptions sourced from `data/atlas-ttps.json` (ATLAS v2026.07, released 2026-
 |---|---|---|---|
 | 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/rag-pipeline-security/skill.md

@@ -188,7 +188,7 @@ Descriptions sourced verbatim from `data/atlas-ttps.json` (ATLAS v2026.07, relea
 
 | 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) |

package/skills/ransomware-response/skill.md

@@ -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 / T0017 / 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.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.
 
 ATLAS pinned to v2026.07 (August 2026). ATT&CK pinned to v19.2 (August 2026). Both are explicit version pins — never silently upgraded.