@blamejs/exceptd-skills 0.20.1 → 0.21.0

package/data/global-frameworks.json

@@ -260,21 +260,21 @@
         "authority": "Australian Signals Directorate (ASD)",
         "source": "https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism",
         "effective_date": "Monthly updates",
-        "version": "2026-03",
+        "version": "2026-09",
         "patch_sla": 48,
-        "patch_sla_note": "ISM-1623: 48h for critical with existing exploit. Best non-CISA-aware SLA of any major framework.",
+        "patch_sla_note": "ISM-1876 and ISM-1877: online services and the operating systems of internet-facing servers and network devices are patched within 48 hours of release when the vendor rates a vulnerability critical or a working exploit exists, at every Essential Eight maturity level. Browsers, office suites, email clients and workstation operating systems get 48 hours only at Maturity Level Three (ISM-1692, ISM-1696).",
         "critical_controls": [
-          "ISM-1623 — Critical patches with exploits: 48h remediation",
-          "ISM-1754 — Patches with existing exploit for extreme risk: emergency patching",
-          "ISM-1698 — Application control (allowlisting)",
-          "ISM-0974 — Multi-factor authentication",
-          "ISM-1585 — Privileged access workstations"
+          "ISM-1876: online services patched within 48 hours of release when critical or a working exploit exists",
+          "ISM-1877: operating systems of internet-facing servers and network devices patched within 48 hours of release when critical or a working exploit exists",
+          "ISM-0843: application control implemented on workstations",
+          "ISM-1173: multi-factor authentication for privileged users",
+          "ISM-1380: privileged users use separate privileged and unprivileged operating environments"
         ],
         "framework_gaps": [
-          "ISM-1623 48h SLA still too long for CISA KEV + deterministic 732-byte PoC",
+          "The 48-hour windows (ISM-1876, ISM-1877) run from the vendor's release, which is still too long for a CISA KEV entry with a deterministic public exploit and does not start at all while no fix exists",
           "Live kernel patching: not a required capability",
-          "AI/ML systems: no ISM controls specifically for AI security",
-          "MCP server trust: not addressed",
+          "AI/ML systems: the ISM has AI application controls (ISM-1924 prompt injection, ISM-2086 to ISM-2088 model and training-data integrity, ISM-2092 and ISM-2093 AI access control) but none is in an Essential Eight maturity profile, so they are not assessed by the maturity model",
+          "MCP server trust: ISM-2156 and ISM-2157 restrict agentic AI to the minimum tools with task-scoped authorization, but no control addresses where an MCP server package came from",
           "PQC: under development; quantum computing risk guidance exists but no mandate"
         ],
         "ai_coverage": "AI systems recommended to apply ISM; no AI-specific controls as of 2026-03",
@@ -2888,10 +2888,10 @@
         "note": "CISA KEV does not set a universal SLA — BOD 22-01 requires 14 days for federal agencies"
       },
       {
-        "framework": "ASD ISM + Essential 8 ML3 (AU)",
+        "framework": "ASD ISM + Essential 8 (AU)",
         "sla_hours": 48,
         "sla_days": 2,
-        "note": "ISM-1623: exploit-confirmed critical patches"
+        "note": "ISM-1876 and ISM-1877: online services and internet-facing operating systems, critical or with a working exploit, at every maturity level; browsers, office suites and workstation operating systems reach 48 hours only at Maturity Level Three"
       },
       {
         "framework": "UK Cyber Essentials (UK)",

package/data/playbooks/ai-api.json

@@ -63,7 +63,7 @@
     "attack_class": "ai-c2",
     "atlas_refs": [
       "AML.T0096",
-      "AML.T0017"
+      "AML.T0016"
     ],
     "attack_refs": [
       "T1071",
@@ -281,9 +281,9 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1841",
-            "designed_for": "Australian Government ISM control on event logging for cloud and SaaS services.",
-            "insufficient_because": "Logging scope assumes the org receives audit logs from the SaaS provider. AI-API providers expose request/response metadata but not prompt content, so the control's detection value collapses on the exfil-via-prompt channel."
+            "control_id": "ISM-2159",
+            "designed_for": "ISM-2159 requires all tool invocations, external requests and outputs generated by agentic AI applications to be centrally logged with enough detail to support incident investigation.",
+            "insufficient_because": "The control covers the organization's own agentic AI applications. Malware or an insider calling an approved AI API from outside those applications produces no ISM-2159 record, and the provider's audit log exposes request and response metadata rather than prompt content, so exfiltration through a prompt leaves nothing the ISM requires anyone to analyse."
           }
         ]
       },
@@ -302,7 +302,7 @@
         "monitor": 40,
         "close": 25
       },
-      "framework_lag_declaration": "NIST 800-53 SI-3/SC-7/AC-2, ISO 27001:2022 A.8.16, SOC 2 CC6/CC7, EU AI Act Art.15 are all structurally insufficient for AI-API C2. The shared failure: each control treats the AI API endpoint as a legitimate authorized SaaS, the service account using it as authorized, and the traffic over it as business-as-usual. The SesameOp pattern operates entirely inside that authorized envelope. Until frameworks add 'AI-API egress baseline + content inspection + bearer-token-to-process attribution' controls, anomaly-detection audit opinions provide zero signal about AI-as-C2 exposure. Companion gap: secrets-management controls (IA-5, A.8.5) focus on repository-committed keys and ignore the dotfile credential surface where most developer keys actually live. Lag = ~190 days behind the SesameOp pattern's first documentation; no framework body has issued draft language as of 2026-05-11. UK CAF Principles B3 (Data Security) and B4 (System Security) treat egress monitoring and trust-boundary enforcement as outcomes without naming AI-API endpoints as a distinct exfiltration channel — B3/B4 evidence passes while authorized-SaaS C2 channels stay invisible. AU Essential 8 ML2 Application Control (E8 M.1) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1546 cover process-lineage and admin-privilege restriction, but Essential 8 does not yet enumerate AI-API endpoints in its allowlist guidance — operators who allow AI SaaS at the proxy retain no per-token attribution.",
+      "framework_lag_declaration": "NIST 800-53 SI-3/SC-7/AC-2, ISO 27001:2022 A.8.16, SOC 2 CC6/CC7, EU AI Act Art.15 are all structurally insufficient for AI-API C2. The shared failure: each control treats the AI API endpoint as a legitimate authorized SaaS, the service account using it as authorized, and the traffic over it as business-as-usual. The SesameOp pattern operates entirely inside that authorized envelope. Until frameworks add 'AI-API egress baseline + content inspection + bearer-token-to-process attribution' controls, anomaly-detection audit opinions provide zero signal about AI-as-C2 exposure. Companion gap: secrets-management controls (IA-5, A.8.5) focus on repository-committed keys and ignore the dotfile credential surface where most developer keys actually live. Lag = ~190 days behind the SesameOp pattern's first documentation; no framework body has issued draft language as of 2026-05-11. UK CAF Principles B3 (Data Security) and B4 (System Security) treat egress monitoring and trust-boundary enforcement as outcomes without naming AI-API endpoints as a distinct exfiltration channel — B3/B4 evidence passes while authorized-SaaS C2 channels stay invisible. AU Essential 8 Application Control (ISM-0843, ISM-1657) and Restrict Administrative Privileges cover what executes on a host and who holds admin rights, but application control governs executables rather than which network services an approved process reaches, so operators who allow AI SaaS at the proxy retain no per-token attribution.",
       "skill_chain": [
         {
           "skill": "ai-c2-detection",

package/data/playbooks/ai-discovered-cve-triage.json

@@ -67,7 +67,7 @@
     "attack_class": "ai-attack-surface",
     "atlas_refs": [
       "AML.T0017",
-      "AML.T0040"
+      "AML.T0016"
     ],
     "attack_refs": [
       "T1068",
@@ -300,9 +300,9 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1493 — Vulnerability management",
-            "designed_for": "Identification + remediation of vulnerabilities in line with Essential 8 ML2/ML3.",
-            "insufficient_because": "Patch-application ladder anchors on advisory date + severity. AI-discovery cycle compression not addressed. ML3 48h SLA still long for a deterministic AI-discovered RCE with public PoC."
+            "control_id": "ISM-1143: patch management processes",
+            "designed_for": "ISM-1143 requires patch management processes and procedures; the Essential Eight windows under it set 48 hours from release when the vendor rates a vulnerability critical or a working exploit exists (ISM-1876 and ISM-1877 at every maturity level, ISM-1692 and ISM-1696 at Maturity Level Three).",
+            "insufficient_because": "The patching windows anchor on the vendor's release and severity rating. AI-discovery cycle compression is not addressed, and 48 hours from release is still long for a deterministic AI-discovered RCE with a public PoC; for browsers, office suites and workstations it applies only at Maturity Level Three."
           }
         ]
       },
@@ -323,7 +323,7 @@
         "monitor": 50,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-53 RA-5 + RA-7 + SI-2 + SI-5, ISO 27001 A.5.7 + A.8.8, NIS2 Art.21(2)(c), DORA Art.10, EU CRA Art.14, SOC 2 CC7.1, UK CAF B4, AU ISM-1493 are all structurally insufficient for AI-discovered CVE triage. None require AI-discovery to be a tracked input to vulnerability management. None require subscription to AI-discovery vendor feeds (Theori, depthfirst, Zellic, GTIG). None require SLA tightening for the AI-discovered class. The framework cadence is ~540 days behind the operational AI-discovery wave (FIPS-style AI auditing landed mid-2024; 41% AI-zero-day attribution landed early 2026). Compensating controls (AI-discovery feed subscription + AI-discovery RWEP factor enforcement + tightened SLA tier for AI-discovered class + AI-attribution verification process) must close the gap before SLA-only compliance can be accepted. None of the frameworks in scope require any of those four controls.",
+      "framework_lag_declaration": "NIST 800-53 RA-5 + RA-7 + SI-2 + SI-5, ISO 27001 A.5.7 + A.8.8, NIS2 Art.21(2)(c), DORA Art.10, EU CRA Art.14, SOC 2 CC7.1, UK CAF B4, AU ISM-1143 are all structurally insufficient for AI-discovered CVE triage. None require AI-discovery to be a tracked input to vulnerability management. None require subscription to AI-discovery vendor feeds (Theori, depthfirst, Zellic, GTIG). None require SLA tightening for the AI-discovered class. The framework cadence is ~540 days behind the operational AI-discovery wave (FIPS-style AI auditing landed mid-2024; 41% AI-zero-day attribution landed early 2026). Compensating controls (AI-discovery feed subscription + AI-discovery RWEP factor enforcement + tightened SLA tier for AI-discovered class + AI-attribution verification process) must close the gap before SLA-only compliance can be accepted. None of the frameworks in scope require any of those four controls.",
       "skill_chain": [
         {
           "skill": "ai-attack-surface",
@@ -743,7 +743,7 @@
         {
           "finding_id": "ai-discovered-cve-triage-gap",
           "framework": "au-ism",
-          "claimed_control": "ISM-1493 — Vulnerability management",
+          "claimed_control": "ISM-1143: patch management processes",
           "actual_gap": "Patch-application ladder on advisory date + severity. AI-discovery cycle compression not addressed.",
           "required_control": "ACSC ISM update binding AI-discovered CVE class to a tighter SLA than ML3 48h; AI-discovered + deterministic + public PoC = 4h immediate-action."
         }
@@ -1019,7 +1019,7 @@
         "lesson_template": {
           "attack_vector": "AI-discovered CVE class triage failure — the operator processes AI-discovered CVEs at non-AI tempo because the vulnerability-management programme has no ai_discovered axis. Adversary with access to the same AI tooling that found the bug develops the exploit faster than the operator's deployment SLA closes.",
           "control_gap": "Vulnerability management treats discovery-mechanism as undifferentiated. No feed coverage of AI-discovery vendor sources. No SLA-tier differentiation. No attribution verification before triage. No tempo metric segmented by ai_discovered.",
-          "framework_gap": "NIST RA-5 + RA-7 + SI-2 + SI-5, ISO A.5.7 + A.8.8, NIS2 Art.21(2)(c), DORA Art.10, EU CRA Art.14, SOC 2 CC7.1, UK CAF B4, AU ISM-1493 all permit AI-blind vulnerability-management programmes as compliant. Framework cadence ~540 days behind operational AI-discovery wave.",
+          "framework_gap": "NIST RA-5 + RA-7 + SI-2 + SI-5, ISO A.5.7 + A.8.8, NIS2 Art.21(2)(c), DORA Art.10, EU CRA Art.14, SOC 2 CC7.1, UK CAF B4, AU ISM-1143 all permit AI-blind vulnerability-management programmes as compliant. Framework cadence ~540 days behind operational AI-discovery wave.",
           "new_control_requirement": "Add an 'AI-discovery aware vulnerability management' sub-control across the framework set requiring: (a) AI-discovery vendor feed subscription with ingestion attested, (b) ai_discovered SLA tier in policy aligned to RWEP-derived window, (c) attribution-verification process producing band classification, (d) deployment-tempo metric segmented by ai_discovered, (e) annual review against GTIG zero-day report and named-source publication cadence."
         },
         "feeds_back_to_skills": [

package/data/playbooks/cicd-pipeline-compromise.json

@@ -67,8 +67,7 @@
     "name": "CI/CD pipeline + runner + OIDC + signing-key trust boundary",
     "attack_class": "supply-chain",
     "atlas_refs": [
-      "AML.T0010",
-      "AML.T0016"
+      "AML.T0010"
     ],
     "attack_refs": [
       "T1195.002",

package/data/playbooks/cloud-iam-incident.json

@@ -17,7 +17,7 @@
           "SOC2-CC6-Access-Key-Leak-Public-Repo",
           "AWS-Security-Hub-Coverage-Gap",
           "UK-CAF-B2-Cloud-IAM",
-          "AU-ISM-1546-Cloud-Service-Account"
+          "AU-ISM-1685-Cloud-Service-Account"
         ]
       }
     ],
@@ -284,7 +284,7 @@
         }
       ],
       "framework_context": {
-        "gap_summary": "Cloud-IAM frameworks (NIST 800-53 AC-2 Account Management, ISO/IEC 27017 cloud-services controls, SOC 2 CC6 logical-access criteria, FedRAMP IL5 baseline, AWS Security Hub control library, GCP CIS, Azure Security Benchmark) target conventional account lifecycle and resource-policy posture. They were authored against single-account, single-principal models. The dominant 2024-2026 cloud-account-compromise vectors — cross-account assume-role chains initiated from a compromised principal, federated SAML / OIDC trust abuse, long-lived access-key exfiltration from public repositories, managed-identity token replay against the metadata API — are session-based and cross-boundary. Account-lifecycle controls cannot see them. CISA's Snowflake AA24 advisory (June 2024) documented the third-party-IdP-to-cloud-IAM credential reuse chain as a class of compromise; no framework names this chain as a distinct control class. FedRAMP IL5 baseline assumes single-cloud-tenant deployments and does not contemplate federated IL6 sovereign-cloud trust patterns. UK CAF Principle B2 (Identity and Access Control) is outcome-based on credential lifecycle and treats cloud-IAM as a sub-case of conventional IAM. AU ISM-1546 covers MFA on privileged human users; cloud service-account access keys (which now hold the actual operational privileges) are out of scope. SCOPE: this playbook investigates a specific cloud account (or account-set) for IAM-compromise indicators in CloudTrail / Cloud Audit Logs / Activity Logs over the last 90 days, plus current IAM-principal posture (long-lived keys, federated trust configuration, SCP/Org-Policy state, recently-modified resource policies).",
+        "gap_summary": "Cloud-IAM frameworks (NIST 800-53 AC-2 Account Management, ISO/IEC 27017 cloud-services controls, SOC 2 CC6 logical-access criteria, FedRAMP IL5 baseline, AWS Security Hub control library, GCP CIS, Azure Security Benchmark) target conventional account lifecycle and resource-policy posture. They were authored against single-account, single-principal models. The dominant 2024-2026 cloud-account-compromise vectors — cross-account assume-role chains initiated from a compromised principal, federated SAML / OIDC trust abuse, long-lived access-key exfiltration from public repositories, managed-identity token replay against the metadata API — are session-based and cross-boundary. Account-lifecycle controls cannot see them. CISA's Snowflake AA24 advisory (June 2024) documented the third-party-IdP-to-cloud-IAM credential reuse chain as a class of compromise; no framework names this chain as a distinct control class. FedRAMP IL5 baseline assumes single-cloud-tenant deployments and does not contemplate federated IL6 sovereign-cloud trust patterns. UK CAF Principle B2 (Identity and Access Control) is outcome-based on credential lifecycle and treats cloud-IAM as a sub-case of conventional IAM. AU ISM-1173 covers MFA on privileged human users; cloud service-account access keys (which now hold the actual operational privileges) fall under ISM-1685, which a long, unique key satisfies even though it works from anywhere once it leaks. SCOPE: this playbook investigates a specific cloud account (or account-set) for IAM-compromise indicators in CloudTrail / Cloud Audit Logs / Activity Logs over the last 90 days, plus current IAM-principal posture (long-lived keys, federated trust configuration, SCP/Org-Policy state, recently-modified resource policies).",
         "lag_score": 60,
         "per_framework_gaps": [
           {
@@ -325,9 +325,9 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1546",
-            "designed_for": "Multi-factor authentication for privileged users and remote access.",
-            "insufficient_because": "ISM-1546 covers human-principal authentication. Cloud service-account access keys, IAM-role assume-role chains initiated by service principals, and managed-identity tokens never cross the human-MFA gate. Captured in `data/framework-control-gaps.json#AU-ISM-1546-Cloud-Service-Account`."
+            "control_id": "ISM-1173 / ISM-1685",
+            "designed_for": "ISM-1173 requires multi-factor authentication for privileged human users; ISM-1685 requires break glass, local administrator and service-account credentials to be long, unique, unpredictable and managed; ISM-2141 prefers short-lived, dynamically issued workload credentials.",
+            "insufficient_because": "ISM-1173 covers human principals, and ISM-1685 is met by a long, unique key that still works from anywhere once it leaks. Cloud service-account access keys, IAM-role assume-role chains initiated by service principals, and managed-identity tokens never cross the human-MFA gate. Captured in `data/framework-control-gaps.json#AU-ISM-1685-Cloud-Service-Account`."
           },
           {
             "framework": "au-essential-8",
@@ -364,7 +364,7 @@
         "monitor": 70,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-53 AC-2 (Account Management) does not model cross-account assume-role chains — each link is a valid AC-2-compliant action; the compromise is the chain. ISO/IEC 27001:2022 A.5.15-A.5.18 cover account lifecycle, not session-based IAM observability. ISO/IEC 27017 cloud-specific controls (A.5.23 equivalent) lag on managed-identity token replay — A.9.2.1 'Managing user registration and de-registration' and Annex A cloud controls do not enumerate token-binding to instance identity. SOC 2 CC6 logical-access criteria treat the authenticated session as the access boundary; access-key-leak-to-public-repo produces a fully-authenticated session whose CC6 evidence is satisfied. CISA's Snowflake AA24 advisory documented the third-party-IdP-to-cloud-IAM credential-reuse chain as a class; no framework names this chain as a distinct control class — captured in `data/framework-control-gaps.json#CISA-Snowflake-AA24-IdP-Cloud`. AWS Security Hub / GCP Security Command Center / Azure Defender for Cloud are coverage-based posture tools, not breach detection; 'all green' attestations have ~0 correlation with absence of behavioural anomalies (captured in `data/framework-control-gaps.json#AWS-Security-Hub-Coverage-Gap`). UK CAF Principle B2 is outcome-based on credential-lifecycle hygiene and lacks cloud-IAM specificity (captured in `UK-CAF-B2-Cloud-IAM`). AU Essential 8 ML2 Strategy 4 (MFA) covers human MFA; cloud service-account access keys, OIDC federation tokens, SAML assertions are bearer credentials that bypass MFA entirely (captured in `AU-ISM-1546-Cloud-Service-Account`). FedRAMP IL5 baseline is insufficient for federated cloud / IL6 sovereign-trust patterns (captured in `FedRAMP-IL5-IAM-Federated`). CIS Controls v8 align conceptually but lack a cloud-specific maturity ladder. PCI DSS 4.0 Req.7-8 cover access-control objectives generically; cloud-IAM-specific requirements are not enumerated. Practical gap = ~90 days between audit-cycle evidence (quarterly access review) and adversary timeline (hours-to-days). Every framework in scope assumes the audit cadence; the threat model assumes continuous behavioural monitoring.",
+      "framework_lag_declaration": "NIST 800-53 AC-2 (Account Management) does not model cross-account assume-role chains — each link is a valid AC-2-compliant action; the compromise is the chain. ISO/IEC 27001:2022 A.5.15-A.5.18 cover account lifecycle, not session-based IAM observability. ISO/IEC 27017 cloud-specific controls (A.5.23 equivalent) lag on managed-identity token replay — A.9.2.1 'Managing user registration and de-registration' and Annex A cloud controls do not enumerate token-binding to instance identity. SOC 2 CC6 logical-access criteria treat the authenticated session as the access boundary; access-key-leak-to-public-repo produces a fully-authenticated session whose CC6 evidence is satisfied. CISA's Snowflake AA24 advisory documented the third-party-IdP-to-cloud-IAM credential-reuse chain as a class; no framework names this chain as a distinct control class — captured in `data/framework-control-gaps.json#CISA-Snowflake-AA24-IdP-Cloud`. AWS Security Hub / GCP Security Command Center / Azure Defender for Cloud are coverage-based posture tools, not breach detection; 'all green' attestations have ~0 correlation with absence of behavioural anomalies (captured in `data/framework-control-gaps.json#AWS-Security-Hub-Coverage-Gap`). UK CAF Principle B2 is outcome-based on credential-lifecycle hygiene and lacks cloud-IAM specificity (captured in `UK-CAF-B2-Cloud-IAM`). AU Essential 8 ML2 Strategy 4 (MFA) covers human MFA; cloud service-account access keys, OIDC federation tokens, SAML assertions are bearer credentials that bypass MFA entirely (captured in `AU-ISM-1685-Cloud-Service-Account`). FedRAMP IL5 baseline is insufficient for federated cloud / IL6 sovereign-trust patterns (captured in `FedRAMP-IL5-IAM-Federated`). CIS Controls v8 align conceptually but lack a cloud-specific maturity ladder. PCI DSS 4.0 Req.7-8 cover access-control objectives generically; cloud-IAM-specific requirements are not enumerated. Practical gap = ~90 days between audit-cycle evidence (quarterly access review) and adversary timeline (hours-to-days). Every framework in scope assumes the audit cadence; the threat model assumes continuous behavioural monitoring.",
       "skill_chain": [
         {
           "skill": "cloud-security",
@@ -378,7 +378,7 @@
         },
         {
           "skill": "framework-gap-analysis",
-          "purpose": "Map findings to which framework controls claim to address cloud-IAM hygiene and where the gap is (NIST AC-2 cross-account, ISO 27017, SOC 2 CC6, FedRAMP IL5, UK CAF B2, AU ISM-1546).",
+          "purpose": "Map findings to which framework controls claim to address cloud-IAM hygiene and where the gap is (NIST AC-2 cross-account, ISO 27017, SOC 2 CC6, FedRAMP IL5, UK CAF B2, AU ISM-1173 and ISM-1685).",
           "required": true
         },
         {
@@ -930,9 +930,9 @@
         {
           "finding_id": "cloud-service-account-mfa-gap",
           "framework": "au-ism",
-          "claimed_control": "ISM-1546 — Multi-factor authentication for privileged users",
-          "actual_gap": "ISM-1546 covers human-principal MFA. Cloud service-account access keys, IAM-role assume-role chains initiated by service principals, and managed-identity tokens bypass MFA entirely.",
-          "required_control": "ISM-1546 extension enumerating cloud non-human-principal credential hygiene with explicit bearer-token TTL ceilings + audience binding + per-action audit logging. Captured in `data/framework-control-gaps.json#AU-ISM-1546-Cloud-Service-Account`."
+          "claimed_control": "ISM-1173: multi-factor authentication for privileged users",
+          "actual_gap": "ISM-1173 covers human-principal MFA. Cloud service-account access keys, IAM-role assume-role chains initiated by service principals, and managed-identity tokens bypass MFA entirely.",
+          "required_control": "ISM-1685 extension enumerating cloud non-human-principal credential hygiene with explicit bearer-token TTL ceilings + audience binding + per-action audit logging. Captured in `data/framework-control-gaps.json#AU-ISM-1685-Cloud-Service-Account`."
         },
         {
           "finding_id": "uk-caf-b2-cloud-iam",
@@ -1211,7 +1211,7 @@
         "lesson_template": {
           "attack_vector": "Cloud-IAM compromise via $vector ($csp): root-login-from-new-ASN / cross-account-assume-role-chain / leaked-access-key-from-public-repo / managed-identity-token-replay / federated-trust-wildcard-subject / IMDSv1-SSRF / mass-IAM-creation-outside-IaC.",
           "control_gap": "Account-lifecycle controls (NIST AC-2, ISO A.5.15, SOC 2 CC6) treat principals individually and miss cross-boundary chains. Posture tools (Security Hub / SCC / Defender for Cloud) are coverage-based and miss behavioural anomalies. Federated-trust hygiene is not enumerated in any framework's evidence surface.",
-          "framework_gap": "NIST 800-53 AC-2 + ISO/IEC 27001:2022 A.5.15-A.5.18 + SOC 2 CC6 + FedRAMP IL5 baseline + UK CAF B2 + AU ISM-1546 + AU Essential 8 Strategy 4 collectively cover account lifecycle + human MFA + posture-tool deployment. None name cross-account assume-role chains, federated-trust wildcard-subject claims, managed-identity token replay, or IMDS-version-hardening as distinct control classes.",
+          "framework_gap": "NIST 800-53 AC-2 + ISO/IEC 27001:2022 A.5.15-A.5.18 + SOC 2 CC6 + FedRAMP IL5 baseline + UK CAF B2 + AU ISM-1173 and ISM-1685 + AU Essential 8 Strategy 4 collectively cover account lifecycle + human MFA + posture-tool deployment. None name cross-account assume-role chains, federated-trust wildcard-subject claims, managed-identity token replay, or IMDS-version-hardening as distinct control classes.",
           "new_control_requirement": "Continuous behavioural CloudTrail / audit-log analytics keyed off the detect.indicators in this playbook; federated-trust hygiene attestation (non-wildcard subject claims, audience-pinned); IMDSv2-required SCP / Org Policy enforced org-wide; cross-account assume-role graph monitoring over rolling 24h windows; managed-identity / service-account credential TTL ceilings with audience binding; cross-system credential-reuse mapping for every federated IdP."
         },
         "feeds_back_to_skills": [

package/data/playbooks/containers.json

@@ -236,8 +236,8 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1417",
-            "designed_for": "Australian Government ISM control on hardening operating system and platform configurations.",
+            "control_id": "ISM-1409",
+            "designed_for": "ISM-1409 requires operating systems to be hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when they conflict.",
             "insufficient_because": "Control evidences platform-level hardening at deployment. Per-manifest container security context (Pod Security Standards, runAsNonRoot, readOnlyRootFilesystem) is outside the standard ISM evidence model for the host."
           }
         ]
@@ -257,7 +257,7 @@
         "monitor": 65,
         "close": 35
       },
-      "framework_lag_declaration": "NIST 800-190 + CIS K8s Benchmark + NIST 800-53 CM-7 + ISO A.8.9 + PCI Req.2.2 collectively cover container hardening but accept cluster-wide attestation as evidence. None require per-manifest analysis as a control. Manifest drift in GitOps repos can introduce privileged: true / hostPID / unscoped capabilities faster than any attestation cadence. EU CRA + NIST SSDF + SLSA cover supply-chain posture but most orgs are at SLSA L1-L2 without digest pinning. Gap = ~21 days between manifest drift and review cadence; per-CVE gap (e.g. Leaky Vessels) is hours from public PoC to weaponization vs. weeks of node-staging windows. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat container-runtime hardening as an outcome assessable via attestation, without binding evidence to per-manifest privileged-flag or host-namespace exposure. AU Essential 8 Strategy 1 (Application Control, E8 M.1 ML2) covers execution allowlisting on workstations/servers but does not bind to Kubernetes admission-controller policy: privileged-pod denial via OPA/Kyverno or PodSecurity `restricted` admission is the operational analogue, and Essential 8 has no maturity-level requirement enforcing it. ACSC ISM-1546 and ISM-1683 (workload isolation) name workload separation but stop short of banning privileged + hostPID + hostNetwork in cluster manifests as an attested admission-time gate.",
+      "framework_lag_declaration": "NIST 800-190 + CIS K8s Benchmark + NIST 800-53 CM-7 + ISO A.8.9 + PCI Req.2.2 collectively cover container hardening but accept cluster-wide attestation as evidence. None require per-manifest analysis as a control. Manifest drift in GitOps repos can introduce privileged: true / hostPID / unscoped capabilities faster than any attestation cadence. EU CRA + NIST SSDF + SLSA cover supply-chain posture but most orgs are at SLSA L1-L2 without digest pinning. Gap = ~21 days between manifest drift and review cadence; per-CVE gap (e.g. Leaky Vessels) is hours from public PoC to weaponization vs. weeks of node-staging windows. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat container-runtime hardening as an outcome assessable via attestation, without binding evidence to per-manifest privileged-flag or host-namespace exposure. AU Essential 8 Strategy 1 (Application Control, E8 M.1 ML2) covers execution allowlisting on workstations/servers but does not bind to Kubernetes admission-controller policy: privileged-pod denial via OPA/Kyverno or PodSecurity `restricted` admission is the operational analogue, and Essential 8 has no maturity-level requirement enforcing it. ACSC ISM-1409 (operating systems hardened to ASD and vendor guidance) and ISM-1380 (separate privileged and unprivileged operating environments) address hosts and administrators, and no ISM control addresses container workloads, so nothing in the ISM bans privileged + hostPID + hostNetwork in cluster manifests as an attested admission-time gate.",
       "skill_chain": [
         {
           "skill": "container-runtime-security",

package/data/playbooks/cred-stores.json

@@ -229,9 +229,9 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1546",
-            "designed_for": "Australian Government ISM control on managing authentication credentials, including their secure storage.",
-            "insufficient_because": "Secure-storage requirement is met by any credential vault. Co-resident plaintext credential files on developer machines (npmrc, pip.conf, aws/credentials) are not exhaustively enumerated by the control's audit method."
+            "control_id": "ISM-2142",
+            "designed_for": "ISM-2142 requires static credentials used by applications and workloads to be centrally managed using a credential or secrets management solution; ISM-2141 prefers short-lived, dynamically issued credentials over long-lived static ones.",
+            "insufficient_because": "The storage requirement is met once a secrets manager holds the workload credentials. Co-resident plaintext credential files on developer machines (npmrc, pip.conf, aws/credentials) are not exhaustively enumerated by the control's audit method."
           }
         ]
       },
@@ -249,7 +249,7 @@
         "monitor": 60,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-63b AAL specs, NIST 800-53 IA-2/IA-5, ISO A.5.16/A.5.17, NIS2 Art.21(2)(j), PCI-DSS Req.8 collectively specify target authenticator properties (phishing-resistant, short-lived, MFA-gated). They do not require enumeration of credentials actually present on developer endpoints. SSO + MFA attestation is accepted as evidence even when local credential stores hold long-lived bearer tokens that bypass SSO. Gap = ~25 days between credential-store drift (new PAT issued, new long-lived AWS key created) and any framework's review cadence. UK CAF Principle B2 (Identity and Access Control) defines authentication outcomes and credential-management practice, but does not require enumeration of credentials persisted in local credential stores outside the SSO/IdP envelope. AU Essential 8 ML2 MFA (E8 M.4) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1546 cover authenticator strength and admin-privilege scope but treat long-lived bearer tokens stored in dotfiles / OS keychains as out of frame — Essential 8 evidence passes while landed-attacker credential harvest stays trivial.",
+      "framework_lag_declaration": "NIST 800-63b AAL specs, NIST 800-53 IA-2/IA-5, ISO A.5.16/A.5.17, NIS2 Art.21(2)(j), PCI-DSS Req.8 collectively specify target authenticator properties (phishing-resistant, short-lived, MFA-gated). They do not require enumeration of credentials actually present on developer endpoints. SSO + MFA attestation is accepted as evidence even when local credential stores hold long-lived bearer tokens that bypass SSO. Gap = ~25 days between credential-store drift (new PAT issued, new long-lived AWS key created) and any framework's review cadence. UK CAF Principle B2 (Identity and Access Control) defines authentication outcomes and credential-management practice, but does not require enumeration of credentials persisted in local credential stores outside the SSO/IdP envelope. AU Essential 8 MFA + Restrict Admin Privileges and ACSC ISM-2141 and ISM-2142 (short-lived workload credentials preferred; static ones held in a secrets manager) cover authenticator strength, admin-privilege scope and workload credentials, but none of them reaches long-lived bearer tokens a developer leaves in dotfiles or an OS keychain, so Essential 8 evidence passes while a landed attacker's credential harvest stays trivial.",
       "skill_chain": [
         {
           "skill": "identity-assurance",

package/data/playbooks/crypto-codebase.json

@@ -325,7 +325,7 @@
         "monitor": 45,
         "close": 25
       },
-      "framework_lag_declaration": "Frameworks structurally bind the OPERATING organization, not the library author. NIST 800-53 SC-13, ISO 27001:2022 A.8.24/A.8.28, PCI DSS 4.0 §3.6/§8.3.2 all push obligations downstream to consumers who inherit the shipped defaults. EU CRA Annex I §1 is the first framework with direct upstream obligations on manufacturers of products with digital elements, but its binding date for vulnerability-handling and SBOM provisions is 2026-09-11 (four months from now) with full compliance 2027-12-11. NIS2 Art.21(2)(g) exerts indirect pressure via essential-entity consumers. UK CAF C.5 + UK PSTI covers connected products only. ISO 27001:2022 A.8.28 'secure coding' is silent on PQC, KDF iteration minimums, RNG-source requirements, constant-time-implementation requirements — the longest structural laggard. NIST IR 8547 + OMB M-23-02 + CNSA 2.0 push federal-system PQC migration through 2030 but rely on procurement pressure to flow upstream. Gap = ~365 days from operational PQC readiness (2024-08-13 FIPS finalization) to binding library-author obligations (2026-09-11 EU CRA partial bind). Compensating controls (downstream-consumer adoption pressure, supply-chain auditing tools, voluntary SECURITY.md disclosure of cryptographic provenance) must close this gap pending EU CRA enforcement. AU Essential 8 ML2 Patch Applications (E8 M.2) plus ACSC ISM-1138 (cryptographic-algorithm transition), ISM-0467 (approved cryptographic algorithms), and ISM-0471 (cryptographic protocol selection) reference downstream consumer migration but place no obligation on upstream library authors to ship PQC-by-default, KDF iteration minima, or constant-time implementations — Essential 8 evidence flows from operating-org posture, not from library-publisher posture. UK CAF Principle C.5 (System Security — outcome-tested cryptographic deployments) and UK PSTI together lag because CAF C.5 mandates outcome-tested cryptographic deployments at the operator but does not require library authors to ship PQC-by-default, constant-time implementations, or KDF iteration minima; PSTI scope is connected products only and excludes upstream library distribution entirely. The library-author surface therefore sits in a coverage seam between CAF (operator-side) and PSTI (finished-product-side) — neither binds the upstream publisher.",
+      "framework_lag_declaration": "Frameworks structurally bind the OPERATING organization, not the library author. NIST 800-53 SC-13, ISO 27001:2022 A.8.24/A.8.28, PCI DSS 4.0 §3.6/§8.3.2 all push obligations downstream to consumers who inherit the shipped defaults. EU CRA Annex I §1 is the first framework with direct upstream obligations on manufacturers of products with digital elements, but its binding date for vulnerability-handling and SBOM provisions is 2026-09-11 (four months from now) with full compliance 2027-12-11. NIS2 Art.21(2)(g) exerts indirect pressure via essential-entity consumers. UK CAF C.5 + UK PSTI covers connected products only. ISO 27001:2022 A.8.28 'secure coding' is silent on PQC, KDF iteration minimums, RNG-source requirements, constant-time-implementation requirements — the longest structural laggard. NIST IR 8547 + OMB M-23-02 + CNSA 2.0 push federal-system PQC migration through 2030 but rely on procurement pressure to flow upstream. Gap = ~365 days from operational PQC readiness (2024-08-13 FIPS finalization) to binding library-author obligations (2026-09-11 EU CRA partial bind). Compensating controls (downstream-consumer adoption pressure, supply-chain auditing tools, voluntary SECURITY.md disclosure of cryptographic provenance) must close this gap pending EU CRA enforcement. AU ISM-1917 (new cryptographic equipment, applications and libraries support ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by 2030), ISM-2073 (post-quantum transition plan) and ISM-0471 (only ASD-Approved Cryptographic Algorithms or high assurance algorithms used) bind the organization that develops or procures the software, but place no obligation on an upstream open-source library author to ship PQC-by-default, KDF iteration minima, or constant-time implementations — Essential 8 evidence flows from operating-org posture, not from library-publisher posture. UK CAF Principle C.5 (System Security — outcome-tested cryptographic deployments) and UK PSTI together lag because CAF C.5 mandates outcome-tested cryptographic deployments at the operator but does not require library authors to ship PQC-by-default, constant-time implementations, or KDF iteration minima; PSTI scope is connected products only and excludes upstream library distribution entirely. The library-author surface therefore sits in a coverage seam between CAF (operator-side) and PSTI (finished-product-side) — neither binds the upstream publisher.",
       "skill_chain": [
         {
           "skill": "pqc-first",

package/data/playbooks/crypto.json

@@ -277,9 +277,9 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-0457",
-            "designed_for": "Australian Government ISM control on approved cryptographic algorithms for protecting government information.",
-            "insufficient_because": "Quarterly publishing cadence lags FIPS 203/204/205 finalization. Approved-algorithm list mixes classical and PQC entries without binding migration deadlines; classical-only stacks remain ISM-compliant for the lag window."
+            "control_id": "ISM-1917",
+            "designed_for": "Australian Government ISM control requiring the development and procurement of new cryptographic equipment, applications and libraries to support ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030, alongside ISM-2073, which requires a post-quantum cryptography transition plan.",
+            "insufficient_because": "ISM-1917 binds new development and procurement only, so systems already deployed with classical key exchange meet the ISM until they are replaced, and its 2030 date does not address data captured now for decryption later. ISM-2073 requires a transition plan but sets no date by which deployed systems must move."
           }
         ]
       },
@@ -298,7 +298,7 @@
         "monitor": 45,
         "close": 25
       },
-      "framework_lag_declaration": "Every framework in scope is structurally insufficient for HNDL. NIST 800-53 SC-8/SC-13, ISO 27001:2022 A.8.24/A.8.25, PCI DSS 4.0 §3.6/§4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I all permit fully-classical cryptographic posture as 'strong cryptography'. NIST itself is the exception: FIPS 203/204/205 are finalized, NIST IR 8547 is a published migration roadmap, OMB M-23-02 mandates federal PQC inventory — but the 800-53 control catalog is unchanged. ISO 27001:2022 was published before PQC finalization and has no scheduled amendment. PCI Council and EU regulators are publicly aware but have not amended binding controls. Lag = ~180 days behind operational readiness (PQC has been production-ready since 2024-08-13) and 4-8+ years behind the CRQC horizon that drives the harvest-now-decrypt-later attack. Compensating controls (crypto-agility, hybrid algorithms, layered encryption envelopes) must close this gap before SLA-only compliance can be accepted. UK CAF Principles B3 (Data Security) and B4 (System Security) treat cryptography as an outcome (data-in-transit + data-at-rest protection) without naming PQC migration or HNDL exposure as a B3/B4 requirement — CAF evidence passes against fully-classical posture. AU Essential 8 ML2 Patch Applications + Patch Operating Systems (E8 M.2) plus ACSC ISM-1138 (cryptographic-algorithm transition) and ISM-0467 (approved cryptographic algorithms) reference algorithm-suite policy, but ISM transition guidance remains advisory in 2026-05 and Essential 8 maturity levels do not bind PQC inventory + migration deadlines.",
+      "framework_lag_declaration": "Every framework in scope is structurally insufficient for HNDL. NIST 800-53 SC-8/SC-13, ISO 27001:2022 A.8.24/A.8.25, PCI DSS 4.0 §3.6/§4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I all permit fully-classical cryptographic posture as 'strong cryptography'. NIST itself is the exception: FIPS 203/204/205 are finalized, NIST IR 8547 is a published migration roadmap, OMB M-23-02 mandates federal PQC inventory — but the 800-53 control catalog is unchanged. ISO 27001:2022 was published before PQC finalization and has no scheduled amendment. PCI Council and EU regulators are publicly aware but have not amended binding controls. Lag = ~180 days behind operational readiness (PQC has been production-ready since 2024-08-13) and 4-8+ years behind the CRQC horizon that drives the harvest-now-decrypt-later attack. Compensating controls (crypto-agility, hybrid algorithms, layered encryption envelopes) must close this gap before SLA-only compliance can be accepted. UK CAF Principles B3 (Data Security) and B4 (System Security) treat cryptography as an outcome (data-in-transit + data-at-rest protection) without naming PQC migration or HNDL exposure as a B3/B4 requirement — CAF evidence passes against fully-classical posture. AU ISM-1917 requires new cryptographic equipment, applications and libraries to support ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030, and ISM-2073 requires a post-quantum transition plan, but neither sets a date for systems already deployed, neither is in an Essential Eight maturity profile, and ISM-0471 still accepts classical ASD-Approved Cryptographic Algorithms in the meantime.",
       "skill_chain": [
         {
           "skill": "pqc-first",

package/data/playbooks/hardening.json

@@ -209,8 +209,8 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1417",
-            "designed_for": "Australian Government ISM control on hardening operating system configurations.",
+            "control_id": "ISM-1409",
+            "designed_for": "ISM-1409 requires operating systems to be hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when they conflict.",
             "insufficient_because": "Control evidences a hardened baseline at deployment. Post-deployment sysctl drift, manual override during incident response, or fleet-management config-push regressions are not detected by the ISM's evidence model."
           }
         ]
@@ -230,7 +230,7 @@
         "monitor": 65,
         "close": 30
       },
-      "framework_lag_declaration": "NIST CM-6, ISO A.8.9, Essential 8 OS Hardening, CMMC CM.L2-3.4.1/2 all permit baseline + change-management evidence without requiring continuous attestation of the specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement mode) that determine whether a vulnerable kernel is actually exploitable. Gap = ~21 days at typical orgs between drift event and review. For environments using GitOps-deployed kernel parameters, drift can occur faster than monitoring catches. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat OS hardening as a system-security outcome assessable via baseline-and-change-management evidence, without binding to continuous attestation of specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement) — CAF evidence passes against a host whose flags drifted hours after the last review. AU Essential 8 ML2 Patch Operating Systems (E8 M.2) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1144 / ISM-1493 (vulnerability management) reference OS-hardening posture but do not enumerate the per-sysctl flag set whose state determines whether a vulnerable kernel is actually exploitable. EU NIS2 Art.21(2)(c) `secure development lifecycle` and DORA Art.9(4) `secure configuration` both reference hardening posture obligation but stop short of requiring per-flag kernel-hardening attestation; the gap is that operators can claim compliance with `vm.mmap_min_addr` defaulted-but-not-attested, because neither framework requires the per-sysctl evidence that distinguishes a hardened kernel from a default-shipped one.",
+      "framework_lag_declaration": "NIST CM-6, ISO A.8.9, Essential 8 OS Hardening, CMMC CM.L2-3.4.1/2 all permit baseline + change-management evidence without requiring continuous attestation of the specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement mode) that determine whether a vulnerable kernel is actually exploitable. Gap = ~21 days at typical orgs between drift event and review. For environments using GitOps-deployed kernel parameters, drift can occur faster than monitoring catches. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat OS hardening as a system-security outcome assessable via baseline-and-change-management evidence, without binding to continuous attestation of specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement) — CAF evidence passes against a host whose flags drifted hours after the last review. AU Essential 8 ML2 Patch Operating Systems (E8 M.2) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1409 (operating systems hardened to ASD and vendor guidance) reference OS-hardening posture but do not enumerate the per-sysctl flag set whose state determines whether a vulnerable kernel is actually exploitable. EU NIS2 Art.21(2)(c) `secure development lifecycle` and DORA Art.9(4) `secure configuration` both reference hardening posture obligation but stop short of requiring per-flag kernel-hardening attestation; the gap is that operators can claim compliance with `vm.mmap_min_addr` defaulted-but-not-attested, because neither framework requires the per-sysctl evidence that distinguishes a hardened kernel from a default-shipped one.",
       "skill_chain": [
         {
           "skill": "kernel-lpe-triage",

package/data/playbooks/identity-sso-compromise.json

@@ -69,7 +69,8 @@
     "name": "Identity-provider in-progress compromise detection (SSO / federated-trust plane)",
     "attack_class": "identity-abuse",
     "atlas_refs": [
-      "AML.T0048",
+      "AML.T0053",
+      "AML.T0098",
       "AML.T0096"
     ],
     "attack_refs": [
@@ -255,13 +256,13 @@
       ]
     },
     "direct": {
-      "threat_context": "Q1-Q2 2026 IdP-compromise-in-progress landscape. Salt Typhoon's telecom intrusions in 2024-2025 included tenant-admin-tier persistence inside Entra ID + Okta tenants belonging to critical-infrastructure carriers — the attacker held the IdP plane for weeks before lateral movement, and the detection signal that surfaced compromise was IdP-control-plane (admin-role grant out of normal change window) rather than endpoint or network. Scattered Spider's 2024-2025 SaaS-supply-chain attacks routinely abused OAuth-app-consent grants to access mailboxes + repositories + SaaS data without triggering MFA prompts on the victim user. The 2023 Okta customer-support session-theft incident remains a foundational reminder: vendor-tier admin access is in-scope for monitoring, and the attacker did not need to pass MFA at the customer tenant — they used vendor-side session material. Golden-SAML technique (signing-certificate theft from AD FS or Entra ID federation trust) is operational since 2020 (Solarigate origin) and remains in active use; the detection signature is federation-trust-config modification + sudden signed-assertion volume increase. Primary Refresh Token (PRT) theft, primarily via TokenBroker or seamless-SSO endpoints on a compromised endpoint, gives the attacker indefinite tenant access without re-authentication. The AI-attack dimension: AML.T0048 (model exfiltration) + AML.T0096 (LLM plugin compromise) cross into the IdP plane when an attacker abuses an LLM tool's OAuth grant against the IdP itself — refresh-token hoarding by an OAuth app is a credible AI-C2 fingerprint. This playbook detects compromise IN PROGRESS; the post-incident IR workflow lives in idp-incident.",
+      "threat_context": "Q1-Q2 2026 IdP-compromise-in-progress landscape. Salt Typhoon's telecom intrusions in 2024-2025 included tenant-admin-tier persistence inside Entra ID + Okta tenants belonging to critical-infrastructure carriers — the attacker held the IdP plane for weeks before lateral movement, and the detection signal that surfaced compromise was IdP-control-plane (admin-role grant out of normal change window) rather than endpoint or network. Scattered Spider's 2024-2025 SaaS-supply-chain attacks routinely abused OAuth-app-consent grants to access mailboxes + repositories + SaaS data without triggering MFA prompts on the victim user. The 2023 Okta customer-support session-theft incident remains a foundational reminder: vendor-tier admin access is in-scope for monitoring, and the attacker did not need to pass MFA at the customer tenant — they used vendor-side session material. Golden-SAML technique (signing-certificate theft from AD FS or Entra ID federation trust) is operational since 2020 (Solarigate origin) and remains in active use; the detection signature is federation-trust-config modification + sudden signed-assertion volume increase. Primary Refresh Token (PRT) theft, primarily via TokenBroker or seamless-SSO endpoints on a compromised endpoint, gives the attacker indefinite tenant access without re-authentication. The AI-attack dimension: AML.T0053 (AI Agent Tool Invocation) and AML.T0098 (AI Agent Tool Credential Harvesting) cross into the IdP plane when an attacker abuses an LLM tool's OAuth grant against the IdP itself, and refresh-token hoarding by an OAuth app is a credible AI-C2 (AML.T0096) fingerprint. This playbook detects compromise IN PROGRESS; the post-incident IR workflow lives in idp-incident.",
       "rwep_threshold": {
         "escalate": 85,
         "monitor": 65,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-53 AC-2(11) + IA-5, ISO 27001 A.8.16, SOC 2 CC7.2 + CC6.6, NIS2 Art.21(2)(f), UK CAF C1, AU Essential 8 ML3, AU ISM-1559 collectively underspecify in-progress IdP-control-plane compromise detection. None mandate the specific IdP-plane signals: admin-role grant outside change-management window, refresh-token hoarding per service principal, conditional-access exclusion-group membership changes, federation signing-certificate additions or rotations, OAuth-app-consent grants with high-impact scopes (Mail.ReadWrite, Files.ReadWrite.All, full_access_as_app). MFA enforcement (Art.21(2)(f), Strategy 6) coexists with active control-plane bypass. The Salt Typhoon, Scattered Spider, and 2023 Okta cases each satisfied literal framework readings while the attacker held the IdP plane.",
+      "framework_lag_declaration": "NIST 800-53 AC-2(11) + IA-5, ISO 27001 A.8.16, SOC 2 CC7.2 + CC6.6, NIS2 Art.21(2)(f), UK CAF C1, AU Essential 8 ML3, AU ISM-1685 collectively underspecify in-progress IdP-control-plane compromise detection. None mandate the specific IdP-plane signals: admin-role grant outside change-management window, refresh-token hoarding per service principal, conditional-access exclusion-group membership changes, federation signing-certificate additions or rotations, OAuth-app-consent grants with high-impact scopes (Mail.ReadWrite, Files.ReadWrite.All, full_access_as_app). MFA enforcement (Art.21(2)(f), Strategy 6) coexists with active control-plane bypass. The Salt Typhoon, Scattered Spider, and 2023 Okta cases each satisfied literal framework readings while the attacker held the IdP plane.",
       "skill_chain": [
         {
           "skill": "identity-assurance",

package/data/playbooks/idp-incident.json

@@ -8,13 +8,13 @@
       {
         "version": "1.0.0",
         "date": "2026-05-15",
-        "summary": "Initial seven-phase identity-provider incident-response playbook covering Okta / Entra ID / Auth0 / Ping / OneLogin tenant compromise, federated-trust abuse, OAuth app consent abuse, and the Midnight Blizzard / Scattered Spider TTPs against IdP control-plane. Walks the tenant's audit-log API + consent inventory + federated-trust configuration + privileged-role assignments + service-account state + management-API-token inventory to surface compromise indicators; closes the GRC loop with IdP-specific framework gap mapping (NIST IA-5 federated lag, ISO A.5.16/A.5.17 federated lag, SOC 2 CC6 OAuth-consent lag, UK CAF B2 tenant-plane lag, AU ISM-1559 IdP-plane lag) and jurisdiction-aware notification drafts.",
+        "summary": "Initial seven-phase identity-provider incident-response playbook covering Okta / Entra ID / Auth0 / Ping / OneLogin tenant compromise, federated-trust abuse, OAuth app consent abuse, and the Midnight Blizzard / Scattered Spider TTPs against IdP control-plane. Walks the tenant's audit-log API + consent inventory + federated-trust configuration + privileged-role assignments + service-account state + management-API-token inventory to surface compromise indicators; closes the GRC loop with IdP-specific framework gap mapping (NIST IA-5 federated lag, ISO A.5.16/A.5.17 federated lag, SOC 2 CC6 OAuth-consent lag, UK CAF B2 tenant-plane lag, AU ISM-1685 IdP-plane lag) and jurisdiction-aware notification drafts.",
         "framework_gaps_updated": [
           "NIST-800-53-IA-5-Federated",
           "ISO-27001-2022-A.5.16-Federated",
           "SOC2-CC6-OAuth-Consent",
           "UK-CAF-B2-IdP-Tenant",
-          "AU-ISM-1559-IdP",
+          "AU-ISM-1685-IdP",
           "NIS2-Art-21-Federated-Identity",
           "DORA-Art-19-IdP-4h"
         ]
@@ -257,7 +257,7 @@
         }
       ],
       "framework_context": {
-        "gap_summary": "Identity-provider tenant compromise is the dominant 2023-2026 cloud-incident root cause: Okta's October 2023 support-system breach exposed customer HAR files with session tokens; Microsoft's January 2024 Midnight Blizzard incident saw a Russian state actor compromise a legacy non-MFA test tenant and escalate via OAuth-app consent abuse to corporate-mail exfiltration; the Snowflake credential-database compromise 2024 hit AT&T / Ticketmaster / Santander through stolen IdP service-account credentials; Scattered Spider's 2023-2026 campaigns against MGM, Caesars, Twilio, and dozens of others use help-desk social engineering to mint replacement MFA factors. The framework controls that purport to govern this surface — NIST 800-53 IA-5 (Authenticator Management), ISO/IEC 27001:2022 A.5.16 + A.5.17 (Identity Management + Authentication Information), SOC 2 CC6.x (Logical and Physical Access Controls), UK CAF Principle B2 (Identity and Access Control), AU Essential 8 Strategy 4 (MFA), AU ISM-1559 (Privileged Account Credential Management), and NIS2 Art.21(2)(j) (cryptography + access control) — were authored under a model where the IdP tenant itself is a trust anchor: the framework's evidence surface stops at the IdP's published authentication outcomes (was MFA required, was the session authenticated, did the role assignment match policy) and does not extend to the IdP's control plane (who modified the federated-trust configuration, who issued an OAuth consent to which app, who rotated the token-signing certificate). The result is that an attacker with IdP-control-plane access produces audit trails that are fully compliant against every relevant framework, because the framework's evidence model treats the IdP as oracle.",
+        "gap_summary": "Identity-provider tenant compromise is the dominant 2023-2026 cloud-incident root cause: Okta's October 2023 support-system breach exposed customer HAR files with session tokens; Microsoft's January 2024 Midnight Blizzard incident saw a Russian state actor compromise a legacy non-MFA test tenant and escalate via OAuth-app consent abuse to corporate-mail exfiltration; the Snowflake credential-database compromise 2024 hit AT&T / Ticketmaster / Santander through stolen IdP service-account credentials; Scattered Spider's 2023-2026 campaigns against MGM, Caesars, Twilio, and dozens of others use help-desk social engineering to mint replacement MFA factors. The framework controls that purport to govern this surface — NIST 800-53 IA-5 (Authenticator Management), ISO/IEC 27001:2022 A.5.16 + A.5.17 (Identity Management + Authentication Information), SOC 2 CC6.x (Logical and Physical Access Controls), UK CAF Principle B2 (Identity and Access Control), AU Essential 8 Strategy 4 (MFA), AU ISM-1685 (break glass, local administrator and service-account credentials managed), and NIS2 Art.21(2)(j) (cryptography + access control) — were authored under a model where the IdP tenant itself is a trust anchor: the framework's evidence surface stops at the IdP's published authentication outcomes (was MFA required, was the session authenticated, did the role assignment match policy) and does not extend to the IdP's control plane (who modified the federated-trust configuration, who issued an OAuth consent to which app, who rotated the token-signing certificate). The result is that an attacker with IdP-control-plane access produces audit trails that are fully compliant against every relevant framework, because the framework's evidence model treats the IdP as oracle.",
         "lag_score": 60,
         "per_framework_gaps": [
           {
@@ -286,15 +286,15 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1559",
-            "designed_for": "Privileged account credential management — storage, rotation, monitoring of privileged credentials.",
-            "insufficient_because": "ISM-1559 reaches privileged credentials at the system layer (admin password vault, server-side admin accounts). It does not reach IdP-tenant control-plane operations (modifying federated trust, granting tenant-wide application permissions, rotating the token-signing certificate). The IdP tenant is the privileged-credential source-of-truth for every downstream system; ISM-1559 audits the downstream systems and treats the IdP tenant as oracle."
+            "control_id": "ISM-1685",
+            "designed_for": "ISM-1685 requires credentials for break glass accounts, local administrator accounts and service accounts to be long, unique, unpredictable and managed.",
+            "insufficient_because": "ISM-1685 reaches privileged credentials at the system layer (admin password vault, server-side admin accounts). It does not reach IdP-tenant control-plane operations (modifying federated trust, granting tenant-wide application permissions, rotating the token-signing certificate). The IdP tenant is the privileged-credential source-of-truth for every downstream system; ISM-1685 audits the downstream systems and treats the IdP tenant as oracle."
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1546",
-            "designed_for": "Multi-factor authentication for privileged users and remote access.",
-            "insufficient_because": "ISM-1546 covers human-initiated authentication. IdP-tenant control-plane operations are frequently performed by management-API tokens (Okta API tokens, Entra ID app secrets, Auth0 management API tokens) that never cross the human-MFA gate. A leaked management API token grants identical blast radius without ever triggering ISM-1546's evidence path."
+            "control_id": "ISM-1173",
+            "designed_for": "ISM-1173 requires multi-factor authentication for privileged human users of systems.",
+            "insufficient_because": "ISM-1173 covers human-initiated authentication. IdP-tenant control-plane operations are frequently performed by management-API tokens (Okta API tokens, Entra ID app secrets, Auth0 management API tokens) that never cross the human-MFA gate. A leaked management API token grants identical blast radius without ever triggering ISM-1173's evidence path."
           },
           {
             "framework": "nis2",
@@ -328,7 +328,7 @@
         "monitor": 70,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-53 IA-5 (Authenticator Management) and IA-2 (Identification and Authentication) do not reach federated-trust modification at the IdP control plane; IA-5 evidence is satisfied by a quarterly authenticator inventory while an attacker who modifies the federation in week 5 produces eight weeks of compliant audit trail. ISO/IEC 27001:2022 A.5.16 (Identity Management) and A.5.17 (Authentication Information) cover static identity state; they do not name federated-state transitions (OAuth consent, federated-trust modification, cross-tenant access settings). SOC 2 CC6 logical-access controls treat the authenticated session as the access boundary and are blind to consent-mediated lateral movement. UK CAF Principle B2.b is an outcome-based test against the IdP's published authentication outcomes; the IdP control plane is outside B2.b's typical evidence surface. AU Essential 8 Strategy 4 (MFA, E8 M.4) defends the interactive authentication flow; IdP-tenant control-plane operations performed by management-API tokens, OAuth client credentials, or workload identity federations never cross M.4's evidence path. AU ISM-1559 (Privileged Account Credential Management) and ISM-1546 (MFA for Privileged Users) reach privileged credentials at the system layer and the human-MFA surface respectively; both treat the IdP tenant as oracle and do not require auditable controls on the IdP tenant's own control plane. NIS2 Art.21(2)(j) names cryptography and access control as required risk-management measures but the supporting implementing-act guidance does not enumerate federated-identity control-plane operations. DORA Art.19's 4-hour major-ICT-incident clock applies — the IdP is a critical ICT third-party — but financial entities frequently classify IdP incidents under Art.28 concentration risk and miss the Art.19 clock. The aggregate gap is ~60 days between IdP control-plane attack and quarterly-cadence framework evidence; real-world adversary dwell time is days, not quarters.",
+      "framework_lag_declaration": "NIST 800-53 IA-5 (Authenticator Management) and IA-2 (Identification and Authentication) do not reach federated-trust modification at the IdP control plane; IA-5 evidence is satisfied by a quarterly authenticator inventory while an attacker who modifies the federation in week 5 produces eight weeks of compliant audit trail. ISO/IEC 27001:2022 A.5.16 (Identity Management) and A.5.17 (Authentication Information) cover static identity state; they do not name federated-state transitions (OAuth consent, federated-trust modification, cross-tenant access settings). SOC 2 CC6 logical-access controls treat the authenticated session as the access boundary and are blind to consent-mediated lateral movement. UK CAF Principle B2.b is an outcome-based test against the IdP's published authentication outcomes; the IdP control plane is outside B2.b's typical evidence surface. AU Essential 8 Strategy 4 (MFA, E8 M.4) defends the interactive authentication flow; IdP-tenant control-plane operations performed by management-API tokens, OAuth client credentials, or workload identity federations never cross M.4's evidence path. AU ISM-1685 (break glass, local administrator and service-account credentials managed) and ISM-1173 (MFA for privileged human users) reach privileged credentials at the system layer and the human-MFA surface respectively; both treat the IdP tenant as oracle and do not require auditable controls on the IdP tenant's own control plane. NIS2 Art.21(2)(j) names cryptography and access control as required risk-management measures but the supporting implementing-act guidance does not enumerate federated-identity control-plane operations. DORA Art.19's 4-hour major-ICT-incident clock applies — the IdP is a critical ICT third-party — but financial entities frequently classify IdP incidents under Art.28 concentration risk and miss the Art.19 clock. The aggregate gap is ~60 days between IdP control-plane attack and quarterly-cadence framework evidence; real-world adversary dwell time is days, not quarters.",
       "skill_chain": [
         {
           "skill": "idp-incident-response",
@@ -863,9 +863,9 @@
         {
           "finding_id": "idp-tenant-plane-au-uncovered",
           "framework": "au-ism",
-          "claimed_control": "ISM-1559 — Privileged Account Credential Management",
-          "actual_gap": "ISM-1559 reaches privileged credentials at the system layer; it does not reach IdP-tenant control-plane operations. The IdP tenant is the privileged-credential source-of-truth for every downstream system but ISM-1559 audits the downstream systems and treats the IdP tenant as oracle.",
-          "required_control": "Extend ISM-1559 scope to the IdP tenant's own control plane: management-API-token inventory, consent-grant inventory, federated-trust integrity, with continuous alerting."
+          "claimed_control": "ISM-1685: credentials for break glass, local administrator and service accounts",
+          "actual_gap": "ISM-1685 reaches privileged credentials at the system layer; it does not reach IdP-tenant control-plane operations. The IdP tenant is the privileged-credential source-of-truth for every downstream system but ISM-1685 audits the downstream systems and treats the IdP tenant as oracle.",
+          "required_control": "Extend ISM-1685 scope to the IdP tenant's own control plane: management-API-token inventory, consent-grant inventory, federated-trust integrity, with continuous alerting."
         },
         {
           "finding_id": "idp-incident-nis2-clock",
@@ -1099,7 +1099,7 @@
         "enabled": true,
         "lesson_template": {
           "attack_vector": "Identity-provider tenant compromise via $entry_vector (residential-proxy password-spray, help-desk social engineering, leaked management-API token, OAuth-app consent abuse, federated-trust modification, cross-tenant trust abuse, dormant-service-account reactivation).",
-          "control_gap": "Framework controls (NIST IA-5, ISO A.5.16/A.5.17, SOC 2 CC6, UK CAF B2.b, AU ISM-1559, AU E8 M.4) treat the IdP tenant as oracle. IdP-tenant control-plane operations (consent grants, federated-trust modification, cross-tenant access, management-API tokens) are outside the framework's evidence surface.",
+          "control_gap": "Framework controls (NIST IA-5, ISO A.5.16/A.5.17, SOC 2 CC6, UK CAF B2.b, AU ISM-1685, AU E8 M.4) treat the IdP tenant as oracle. IdP-tenant control-plane operations (consent grants, federated-trust modification, cross-tenant access, management-API tokens) are outside the framework's evidence surface.",
           "framework_gap": "Aggregate ~60-day lag between IdP control-plane attack and quarterly-cadence framework evidence cycles. DORA Art.19 4-hour clock applies but tenant operators frequently classify IdP incidents under Art.28 concentration risk and miss the clock.",
           "new_control_requirement": "Continuous consent-grant alerting on high-risk scope + unverified publisher; federated-trust modification alerting with change-control cross-reference; service-account rotation enforcement with IP allowlist; break-glass authentication alerting with on-call paging; management-API token inventory with TTL + scope + source-IP enforcement; cross-tenant access-settings continuous review. IdP-tenant control plane becomes its own control class with quarterly attestation requirement."
         },

package/data/playbooks/kernel.json

@@ -210,8 +210,8 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1493",
-            "designed_for": "Australian Government ISM control for applying patches, updates, or vendor mitigations within 48 hours of release when an exploit exists.",
+            "control_id": "ISM-1877 / ISM-1696",
+            "designed_for": "ISM-1877 requires patches for the operating systems of internet-facing servers and network devices within 48 hours of release when the vendor rates a vulnerability critical or a working exploit exists, at every Essential Eight maturity level; ISM-1696 applies the same 48-hour window to workstations and internal servers at Maturity Level Three only, with one month below it (ISM-1695).",
             "insufficient_because": "48-hour clock anchors to vendor patch availability, not KEV listing. Kernels with live-patch capability go undocumented as a deployed mitigation; the control does not require live-patching as a fallback when reboot windows exceed 48 hours."
           }
         ]
@@ -231,7 +231,7 @@
         "monitor": 70,
         "close": 30
       },
-      "framework_lag_declaration": "NIST SI-2 + ISO A.8.8 + NIS2 Art.21(2)(c) permit 30-day patch SLAs that are inadequate for KEV-listed kernel LPEs with confirmed exploitation. NIST 800-53 Rev. 5.1.1 does not require KEV-aware prioritization, only risk-based — leaving it to implementer interpretation. Real-world tempo: weaponization in hours, patch SLA in weeks. Gap = ~28 days. Compensating controls (live-patch, MAC, kernel hardening) MUST close this gap before SLA-only compliance can be accepted. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat patching as an outcome without binding to KEV-aware tempo; CAF evidence passes against the 30-day SLA that real-world weaponization beats. AU Essential 8 ML2 / ML3 Patch Operating Systems (E8 M.2) sets a 48-hour patch target for internet-facing services with known exploitation, and ACSC ISM-1144 / ISM-1493 (vulnerability management + critical patching) name kernel patching specifically — but Essential 8 maturity adoption surveys show ML3 attainment <15% across regulated AU entities, leaving the structural gap operational even where the framework anticipates it.",
+      "framework_lag_declaration": "NIST SI-2 + ISO A.8.8 + NIS2 Art.21(2)(c) permit 30-day patch SLAs that are inadequate for KEV-listed kernel LPEs with confirmed exploitation. NIST 800-53 Rev. 5.1.1 does not require KEV-aware prioritization, only risk-based — leaving it to implementer interpretation. Real-world tempo: weaponization in hours, patch SLA in weeks. Gap = ~28 days. Compensating controls (live-patch, MAC, kernel hardening) MUST close this gap before SLA-only compliance can be accepted. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat patching as an outcome without binding to KEV-aware tempo; CAF evidence passes against the 30-day SLA that real-world weaponization beats. AU Essential 8 Patch Operating Systems sets a 48-hour patch target for internet-facing servers with a working exploit at every maturity level (ISM-1877), but workstations and internal servers get 48 hours only at Maturity Level Three (ISM-1696) and one month below it (ISM-1695), so a kernel LPE with a public exploit on an internal host stays within compliance for up to a month at Maturity Levels One and Two.",
       "skill_chain": [
         {
           "skill": "kernel-lpe-triage",

package/data/playbooks/llm-tool-use-exfil.json

@@ -70,7 +70,7 @@
       "AML.T0051",
       "AML.T0096",
       "AML.T0024",
-      "AML.T0048"
+      "AML.T0086"
     ],
     "attack_refs": [
       "T1041",

package/data/playbooks/mcp.json

@@ -103,7 +103,7 @@
     "attack_class": "mcp-supply-chain",
     "atlas_refs": [
       "AML.T0010",
-      "AML.T0016",
+      "AML.T0110",
       "AML.T0096"
     ],
     "attack_refs": [
@@ -322,8 +322,8 @@
           },
           {
             "framework": "au-ism",
-            "control_id": "ISM-1546",
-            "designed_for": "Australian Government ISM control on software supply-chain risk management for sourced software.",
+            "control_id": "ISM-1452",
+            "designed_for": "ISM-1452 requires a supply chain risk assessment for suppliers of operating systems, applications, IT equipment, OT equipment and services, to assess their impact on a system's security risk profile.",
             "insufficient_because": "Targets sourced software with a procurement trail. Developer-initiated MCP plugin installation produces no procurement artefact, so the control's evidence requirements cannot bind."
           }
         ]
@@ -344,7 +344,7 @@
         "monitor": 50,
         "close": 25
       },
-      "framework_lag_declaration": "Every framework in scope (NIST 800-53 SA-12/CM-7, ISO 27001:2022 A.5.19/A.5.20/A.8.30, SOC 2 CC9, NIS2 Art.21(2)(d), EU AI Act Art.15, EU CRA Art.13) is structurally insufficient. The shared structural failure: every control treats third-party software risk as a procurement event with a discrete vendor list, while MCP servers are continuously sideloaded by developers from package registries with no procurement signal, no enforced signing, and no allowlist that survives version drift. Until frameworks add a 'developer-installed AI tool plugin' control category with mandatory manifest signature verification + version pinning with integrity hash + provenance attestation, vendor-management audit opinions provide zero signal about MCP exposure. Gap = ~210 days behind operational reality; no framework body has issued draft language as of 2026-05-11. UK CAF Principles B3 (Data Security) and B4 (System Security) treat third-party tooling as a procurement-and-supply-chain assurance outcome, with no Principle that names developer-installed AI tool plugins as a distinct surface — CAF B3/B4 evidence remains silent on MCP-server sideload. AU Essential 8 ML2 Application Control (E8 M.1) + Restrict Admin Privileges (E8 M.5) plus ACSC ISM-1490 (application control) and ISM-1657 (supply chain) cover application-execution allowlisting in principle, but Essential 8 maturity guidance assumes a discrete vendor list and does not enumerate registry-pulled MCP servers as application-control scope.",
+      "framework_lag_declaration": "Every framework in scope (NIST 800-53 SA-12/CM-7, ISO 27001:2022 A.5.19/A.5.20/A.8.30, SOC 2 CC9, NIS2 Art.21(2)(d), EU AI Act Art.15, EU CRA Art.13) is structurally insufficient. The shared structural failure: every control treats third-party software risk as a procurement event with a discrete vendor list, while MCP servers are continuously sideloaded by developers from package registries with no procurement signal, no enforced signing, and no allowlist that survives version drift. Until frameworks add a 'developer-installed AI tool plugin' control category with mandatory manifest signature verification + version pinning with integrity hash + provenance attestation, vendor-management audit opinions provide zero signal about MCP exposure. Gap = ~210 days behind operational reality; no framework body has issued draft language as of 2026-05-11. UK CAF Principles B3 (Data Security) and B4 (System Security) treat third-party tooling as a procurement-and-supply-chain assurance outcome, with no Principle that names developer-installed AI tool plugins as a distinct surface — CAF B3/B4 evidence remains silent on MCP-server sideload. AU Essential 8 ML2 Application Control (E8 M.1) + Restrict Admin Privileges (E8 M.5) plus ACSC ISM-1657 (application control restricts executables, scripts and installers to an approved set) and ISM-1452 (supply chain risk assessment) cover application-execution allowlisting and supplier assessment in principle, but both assume a discrete vendor list and neither enumerates registry-pulled MCP servers. ISM-2156 and ISM-2157 restrict which tools an agent may call, but not where an MCP server package came from.",
       "skill_chain": [
         {
           "skill": "mcp-agent-trust",