@blamejs/exceptd-skills 0.9.1

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

@@ -0,0 +1,303 @@
+---
+name: kernel-lpe-triage
+version: "1.0.0"
+description: Assess Linux kernel LPE exposure — Copy Fail, Dirty Frag, live-patch vs. reboot remediation paths, framework gap declarations
+triggers:
+  - kernel lpe
+  - privilege escalation
+  - copy fail
+  - dirty frag
+  - cve-2026-31431
+  - cve-2026-43284
+  - linux root
+  - kernel patch
+  - live kernel patch
+data_deps:
+  - cve-catalog.json
+  - exploit-availability.json
+atlas_refs: []
+attack_refs:
+  - T1068
+  - T1548.001
+framework_gaps:
+  - NIST-800-53-SI-2
+  - ISO-27001-2022-A.8.8
+  - PCI-DSS-4.0-6.3.3
+  - NIS2-Art21-patch-management
+  - NIST-800-53-SC-8
+  - CIS-Controls-v8-Control7
+rfc_refs:
+  - RFC-4301
+  - RFC-4303
+  - RFC-7296
+cwe_refs:
+  - CWE-125
+  - CWE-362
+  - CWE-416
+  - CWE-672
+  - CWE-787
+d3fend_refs:
+  - D3-ASLR
+  - D3-EAL
+  - D3-PHRA
+  - D3-PSEP
+last_threat_review: "2026-05-01"
+---
+
+# Kernel LPE Triage
+
+## Threat Context (mid-2026)
+
+### Copy Fail — CVE-2026-31431
+
+**Classification:** Local Privilege Escalation | CISA KEV | AI-Discovered  
+**CVSS:** 7.8 (High) | **RWEP:** 90/100
+
+An AI system discovered this vulnerability in approximately one hour. It is a page-cache copy-on-write (CoW) primitive in the Linux kernel affecting all major distributions since kernel 4.14 (2017). Every major Linux distribution is affected: RHEL 7–9, Ubuntu 18.04–24.04, Debian 9–12, CentOS, Fedora, Amazon Linux 2/2023, SUSE 12/15, Alpine, and derivatives.
+
+Key characteristics that make this exceptional:
+- **Deterministic exploitation** — no race condition, no heap spray, no timing sensitivity
+- **Single-stage** — 732-byte script achieves root from unprivileged user in one step
+- **No privileges required** — accessible from any unprivileged container or local user
+- **No user interaction** — fully automated
+- **CISA KEV listed** — active exploitation confirmed in the wild
+
+The attack abuses a write primitive in the copy-on-write path of the page cache. An attacker with any local code execution can reliably escalate to root. In containerized environments without proper namespace isolation, this means container escape.
+
+**What SI-2 says:** "Identify, report, and correct information system flaws; install security-relevant software updates within organizationally defined time periods."  
+**Why SI-2 fails here:** The control is operationalized as a patch cycle (typically 30 days for High, 7 days for Critical). Copy Fail has a public PoC, is CISA KEV listed, and takes 732 bytes and zero expertise to exploit. The 30-day window is not a security window — it is an exploitation window.
+
+---
+
+### Dirty Frag — CVE-2026-43284 + CVE-2026-43500
+
+**Classification:** Local Privilege Escalation Chain | Breaks IPsec Mitigations  
+**CVSS:** 7.8 (High) | **RWEP:** 38/100
+
+Discovered by Hyunwoo Kim. A two-CVE chain exploiting page-cache write primitives in:
+- ESP/IPsec subsystem (CVE-2026-43284)
+- RxRPC subsystem (CVE-2026-43500)
+
+Key characteristics:
+- **Disclosed before patches existed** — no coordinated disclosure window observed
+- **Single command** — root access via one-line invocation
+- **Breaks IPsec** — the exploit path runs through the IPsec subsystem, meaning the exploit actively compromises the IPsec subsystem as it runs. Controls that rely on IPsec for network isolation cannot be considered mitigating controls for this vulnerability.
+- **Chained primitive** — more sophisticated than Copy Fail; requires kernel version fingerprinting to select the right gadget chain
+
+The IPsec dimension is critical: organizations with network segmentation controls implemented via IPsec tunnels cannot claim those controls mitigate Dirty Frag exposure. The exploitation path breaks those controls.
+
+**What SC-8 (Transmission Confidentiality and Integrity) says:** Implement cryptographic mechanisms to prevent unauthorized disclosure during transmission.  
+**Why SC-8 fails here:** Dirty Frag exploits the IPsec implementation itself. SC-8 compliance via IPsec does not mitigate an LPE that runs through the IPsec subsystem.
+
+---
+
+## Framework Lag Declaration
+
+| Framework | Control | Designed For | Fails Because |
+|---|---|---|---|
+| NIST 800-53 Rev 5 | SI-2 Flaw Remediation | Network-centric patch cycles, 2013–2020 era | "Timely" is undefined for instant-root deterministic LPEs with public PoC. 30-day window = exploitation window. |
+| NIST 800-53 Rev 5 | SC-8, SC-28 | Network/storage encryption via standard protocols | Dirty Frag exploits IPsec implementation — SC-8 controls via IPsec are not compensating controls for CVE-2026-43284 |
+| ISO 27001:2022 | A.8.8 Management of technical vulnerabilities | Patch management timelines defined by risk classification | No framework for kernel-specific live patching vs. reboot requirement. "Appropriate timescales" undefined for CISA KEV + public PoC. |
+| PCI DSS 4.0 | 6.3.3 | Critical patches within 1 month, all others within 3 months | 1-month window for a 732-byte public PoC is operationally indefensible. No guidance for live kernel patching on PCI-scoped systems. |
+| NIS2 Directive | Art. 21 (vulnerability handling) | Systematic patch management for essential/important entities | No guidance on live kernel patching as a required capability. "Appropriate measures" undefined for CISA KEV LPEs. |
+| CIS Controls v8 | Control 7 (Continuous Vulnerability Management) | Regular vulnerability scanning and patching | IG1/IG2/IG3 all recommend "remediate within one month" for critical — same problem as PCI. No live-patch framework. |
+| ASD Essential 8 | Patch Operating Systems (Maturity 1–3) | Maturity 3: "within 48 hours" for critical with public exploit | Closest to adequate. ML3 "48 hours" with public exploit is approaching the right frame. Still no live-patch operationalization. |
+
+**Spec layer vs. implementation layer.** Dirty Frag (CVE-2026-43284, CVE-2026-43500) exploits the Linux kernel's IPsec ESP implementation, not the underlying protocol specifications. The spec layer is defined by RFC 4301 (IPsec architecture), RFC 4303 (ESP datagram format), and RFC 7296 (IKEv2) — see `data/rfc-references.json` for status and errata. NIST 800-53 SC-8 and equivalent transmission-confidentiality controls implicitly cite this RFC family but do not operationalize the gap between *spec compliance* and *kernel-implementation safety*: an IPsec deployment can be fully RFC-conformant and still expose root via the ESP path. Auditors evaluating IPsec controls must ask whether the kernel is patched against CVE-2026-43284/-43500, not just whether the spec is followed.
+
+---
+
+## TTP Mapping (MITRE ATT&CK Enterprise, mid-2026)
+
+Each CVE class in this skill maps to ATT&CK technique IDs declared in frontmatter (`T1068`, `T1548.001`). Gap flags identify which standard controls fail against the specific TTP variant — these are the controls a compliance-passing org will rely on, and which the exploit walks past.
+
+| CVE Class | ATT&CK Technique | Sub-Technique / Variant | Gap Flag (Controls That Fail) |
+|---|---|---|---|
+| CVE-2026-31431 (Copy Fail) | T1068 — Exploitation for Privilege Escalation | Page-cache CoW write primitive; deterministic, single-stage; no race | NIST 800-53 SI-2 30-day SLA (exploitation window for 732-byte public PoC); ISO 27001:2022 A.8.8 "appropriate timescales" undefined for CISA KEV; PCI DSS 4.0 6.3.3 1-month critical window is indefensible; CIS Controls v8 Control 7 IG3 "within one month" identical failure |
+| CVE-2026-31431 (Copy Fail — container escape variant) | T1611 — Escape to Host | Privileged container or shared host namespace + Copy Fail = host root | NIST 800-53 SC-39 (Process Isolation) assumes kernel boundary is intact; Copy Fail breaks it. No framework requires kernel CVE status be tracked as a precondition for container isolation claims. |
+| CVE-2026-43284 (Dirty Frag — ESP/IPsec) | T1068 — Exploitation for Privilege Escalation | Chained page-cache write through ESP/IPsec; requires kernel fingerprinting | NIST 800-53 SC-8 (Transmission Confidentiality) when implemented via IPsec — control runs through the vulnerable subsystem and cannot be claimed as compensating; NIS2 Art. 21 "appropriate measures" silent on crypto-subsystem-CVE → control-degradation linkage |
+| CVE-2026-43500 (Dirty Frag — RxRPC) | T1068 — Exploitation for Privilege Escalation | Chain component via RxRPC subsystem | ISO 27001:2022 A.8.8 — no requirement to inventory loaded kernel modules against active CVE chains; ASD Essential 8 ML3 48h-with-exploit window still long for chained public PoC |
+| Both classes (post-exploit token abuse) | T1548.001 — Abuse Elevation Control Mechanism: Setuid and Setgid | Setuid binary or capability abuse following LPE foothold | NIST 800-53 AC-6 (Least Privilege) assumes UID boundary holds; after T1068 root, AC-6 audit trail shows legitimate root actions — control surface is gone |
+| Both classes (detection gap) | T1068 (detection) | auditd/eBPF coverage for `userfaultfd`, `/proc/self/mem` writes, unprivileged-userns-clone | Missing entirely — no framework (NIST, ISO, PCI, NIS2, CIS, Essential 8) requires kernel-LPE exploitation-pattern detection rules. Detection-as-compensating-control claims are unverifiable without these rules. |
+
+Note: ATLAS refs are intentionally empty in frontmatter — these are Linux kernel LPEs, not AI/ML TTPs. Cross-cutting AI-discovery context (Copy Fail was AI-found in ~1h) is captured in the Threat Context section, not via an ATLAS TTP ID.
+
+---
+
+## Exploit Availability Matrix
+
+| CVE | CVSS | RWEP | CISA KEV | PoC Public | AI-Discovered | Active Exploitation | Patch Available | Live Patch | Reboot Required |
+|---|---|---|---|---|---|---|---|---|---|
+| CVE-2026-31431 (Copy Fail) | 7.8 | 90 | Yes (2026-03-15) | Yes — 732-byte script | Yes | Confirmed | Yes | Yes (kpatch/livepatch/kGraft) | Yes |
+| CVE-2026-43284 (Dirty Frag ESP) | 7.8 | 38 | No | Yes | No | Suspected | Yes | No (kpatch RHEL-only) | Yes |
+| CVE-2026-43500 (Dirty Frag RxRPC) | 7.6 | 81 | No | Yes (chain component) | No | Suspected | Yes | Partial (kpatch) | Yes if no live patch |
+
+---
+
+## Analysis Procedure
+
+When a user invokes this skill, perform this assessment in order:
+
+### Step 1: Inventory the environment
+
+Ask for or assess:
+- Linux distribution and version
+- Kernel version (`uname -r`)
+- Deployment model: bare metal / VM / container / serverless
+- Existing live-patching capability: kpatch (RHEL), livepatch (Ubuntu), kGraft (SUSE), or none
+- Whether IPsec is used for any network segmentation or encryption controls
+- Current patch management SLA (how many days for Critical/High CVEs)
+- Whether systems can tolerate a reboot (and when)
+
+### Step 2: Determine exposure
+
+**Copy Fail (CVE-2026-31431):**
+```
+Exposed if: kernel >= 4.14 AND kernel < [patched version for distribution]
+Patched versions:
+  RHEL 8/9:        kernel-4.18.0-553.xx.el8 / kernel-5.14.0-427.xx.el9
+  Ubuntu 22.04:    linux-image-5.15.0-xxx (check USN-7xxx)
+  Ubuntu 24.04:    linux-image-6.8.0-xxx (check USN-7xxx)
+  Debian 12:       6.1.xxx (check DSA-5xxx)
+  Amazon Linux 2:  kernel 5.10.xxx (check ALAS-2026-xxx)
+  SUSE 15:         kernel 5.14.xxx (check SUSE-SU-2026:xxx)
+```
+
+**Dirty Frag (CVE-2026-43284/43500):**
+```
+Exposed if: IPsec or RxRPC modules loaded AND kernel < patched version
+Check: lsmod | grep -E 'esp|xfrm|rxrpc'
+Additional exposure: any IPsec-based network control becomes unreliable
+```
+
+### Step 3: Score exposure level
+
+| Condition | Exposure Level |
+|---|---|
+| Kernel unpatched + no live patch + public internet access | Critical |
+| Kernel unpatched + no live patch + internal only | High |
+| Kernel unpatched + live patch deployed | Medium (verify live patch applied: `kpatch list` or `canonical-livepatch status`) |
+| Kernel patched but reboot pending | Medium |
+| Kernel patched + rebooted | Low |
+| Containerized + privileged mode or host PID namespace | Add one severity level |
+| IPsec used for network controls + CVE-2026-43284 unpatched | Add: "IPsec controls not compensating for Dirty Frag" |
+
+### Step 4: Generate remediation path
+
+**If live patching is available and system cannot tolerate reboot:**
+1. Deploy live kernel patch immediately (kpatch/livepatch/kGraft)
+2. Verify patch applied: `kpatch list` / `canonical-livepatch status`
+3. Schedule reboot at next maintenance window to apply full kernel update
+4. Document: "Live patch deployed YYYY-MM-DD; full patch pending reboot at [maintenance window]"
+
+**If no live patching available and system cannot tolerate reboot:**
+1. Compensating controls (reduce blast radius, do not eliminate exposure):
+   - Seccomp profile restricting `userfaultfd`, `TIOCCONS`, and page-cache-adjacent syscalls
+   - User namespace restrictions (`sysctl -w kernel.unprivileged_userns_clone=0` where supported)
+   - Network-level isolation of affected hosts
+   - Enhanced monitoring: eBPF/auditd rules for exploitation patterns (see detection section)
+2. Document as open risk with compensating controls and reboot timeline
+3. CISA KEV listing requires documented remediation or mitigation with timeline
+
+**If system can tolerate reboot:**
+1. Apply kernel update immediately
+2. Reboot to load new kernel
+3. Verify: `uname -r` shows patched version
+
+**For containerized workloads:**
+- The container host kernel determines exposure — container image patching is irrelevant
+- Privileged containers with Copy Fail exposed = host root exposure
+- Apply host kernel patch or live patch
+- Remove `--privileged` and shared host namespaces from containers where possible
+
+### Step 5: Compliance theater check
+
+Run this check for any org claiming patch management compliance:
+
+> "Your patch management control (SI-2 / A.8.8 / PCI 6.3.3) documents a 30-day remediation window for Critical/High CVEs. CVE-2026-31431 (Copy Fail) is CISA KEV listed with a public 732-byte exploit script requiring no privileges. What is the actual time between CISA KEV listing (2026-03-15) and confirmed patch-or-mitigate? If it exceeds 72 hours without live patching as a deployed capability, the patch management control is theater for CISA KEV class vulnerabilities."
+
+### Step 6: Assess IPsec dependency
+
+If the organization uses IPsec for any of the following, flag explicitly:
+- Network segmentation between security zones
+- Encryption of inter-host traffic
+- VPN tunnels for site-to-site connectivity
+- Compliance with SC-8 or equivalent
+
+Flag: "Dirty Frag (CVE-2026-43284) exploits the IPsec implementation. Network controls relying on IPsec cannot be claimed as compensating controls for this vulnerability. These controls should be noted in the risk assessment as providing reduced assurance until CVE-2026-43284 is fully patched."
+
+---
+
+## Output Format
+
+Produce this structure:
+
+```
+## Kernel LPE Exposure Assessment
+
+**Assessment Date:** YYYY-MM-DD  
+**Kernel Version:** x.x.x  
+**Distribution:** [name + version]
+
+### Exposure Summary
+| CVE | Status | Severity |
+|-----|--------|----------|
+| CVE-2026-31431 (Copy Fail) | [Exposed / Live-patched / Patched] | [Critical/High/Medium/Low] |
+| CVE-2026-43284 (Dirty Frag ESP) | [Exposed / Patched] | [Critical/High/Medium/Low] |
+| CVE-2026-43500 (Dirty Frag RxRPC) | [Exposed / Patched] | [Critical/High/Medium/Low] |
+
+### IPsec Control Impact
+[If applicable: which network controls are affected by Dirty Frag]
+
+### Remediation Path
+[Live patch or full patch instructions for this specific distro/version]
+
+### Compensating Controls (if no-reboot required)
+[Specific sysctl settings, seccomp profiles, monitoring rules]
+
+### Framework Gap Declaration
+[Per-framework statement of what the org's patch management control covers and where it falls short]
+
+### Compliance Theater Check Result
+[Date of CISA KEV listing vs. date of remediation — theater flag if > 72h without live patch capability]
+
+### RWEP Scores
+CVE-2026-31431: CVSS 7.8 / RWEP 90 — immediate action required (4h)
+CVE-2026-43284: CVSS 7.8 / RWEP 38 — remediate within 7 days; disable RxRPC/IPsec chain if not required
+CVE-2026-43500: CVSS 7.6 / RWEP 32 — remediate within 7 days; consider disabling RxRPC module
+```
+
+---
+
+## Detection Rules
+
+If patching is delayed, deploy these detection rules:
+
+**auditd — Copy Fail exploitation pattern:**
+```
+-a always,exit -F arch=b64 -S userfaultfd -k lpe_attempt
+-a always,exit -F arch=b64 -S process_vm_writev -k lpe_attempt
+-w /proc/self/mem -p w -k lpe_mem_write
+```
+
+**sysctl hardening (reduce attack surface, not a full mitigation):**
+```
+kernel.unprivileged_userns_clone = 0
+kernel.perf_event_paranoid = 3
+kernel.kptr_restrict = 2
+vm.unprivileged_userfaultfd = 0
+```
+
+**Monitoring alert:** Any unprivileged process writing to `/proc/[pid]/mem` or invoking `userfaultfd` outside of a known application allowlist should be treated as a potential LPE attempt.
+
+---
+
+## Hand-Off / Related Skills
+
+After producing the kernel LPE triage output, the operator should chain into the following skills. Each entry names a downstream or sibling skill and the specific reason to invoke it from this finding.
+
+- **`exploit-scoring`** — recalculate RWEP when any of the inputs that drive the score change post-triage: a new CISA KEV listing for Dirty Frag, a public PoC for CVE-2026-43500's RxRPC leg, or an AI-discovery flag flip. RWEP, not CVSS, is the prioritisation signal — re-run scoring rather than re-reading the static value in the matrix above.
+- **`defensive-countermeasure-mapping`** — map each kernel LPE finding to D3FEND counters (D3-EAL for executable allowlisting at the kernel-module layer, D3-ASLR for address-space layout randomisation hardening, D3-PSEP for process self-modification prevention, D3-PHRA for process hardening / runtime attestation) and produce the defence-in-depth, least-privilege, zero-trust layered remediation plan rather than a single-control patch ticket.
+- **`attack-surface-pentest`** — verify that the kernel LPE class is in the organisation's pen-test scope (TIBER-EU / DORA TLPT for EU financial-sector orgs, CBEST for UK financial, or the equivalent red-team programme). Most 2025-vintage pen-test scopes are perimeter / web-app focused and do not exercise local LPE primitives against the patched-kernel claim.
+- **`compliance-theater`** — test whether the org's SI-2 / A.8.8 / PCI 6.3.3 patch-management evidence is CVSS-anchored theater for a KEV-listed, AI-discovered, 732-byte deterministic LPE. The 30-day window is the exploitation window; if the org cannot show live-patch-within-4-hours capability or documented compensating controls, the patch-management control is theater for this CVE class.
+- **`policy-exception-gen`** — generate a defensible exception for ephemeral container workloads where the 30-day patch window is architecturally impossible (per AGENTS.md rule #9): immutable image fleets, short-lived serverless functions, and Knative-style scale-to-zero workloads cannot accept a runtime patch and must instead document the compensating controls (host-kernel patched, seccomp profile, namespace isolation, unprivileged-userns disabled) as the exception evidence.

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

@@ -0,0 +1,326 @@
+---
+name: mcp-agent-trust
+version: "1.0.0"
+description: Enumerate MCP trust boundary failures — tool allowlisting, signed manifests, bearer auth, zero-interaction RCE
+triggers:
+  - mcp security
+  - model context protocol
+  - agent trust
+  - tool trust
+  - mcp rce
+  - cve-2026-30615
+  - cursor security
+  - windsurf security
+  - claude code security
+  - ai agent security
+data_deps:
+  - cve-catalog.json
+  - atlas-ttps.json
+  - framework-control-gaps.json
+atlas_refs:
+  - AML.T0010
+  - AML.T0016
+  - AML.T0096
+attack_refs:
+  - T1195.001
+  - T1059
+  - T1190
+framework_gaps:
+  - ALL-MCP-TOOL-TRUST
+  - ISO-27001-2022-A.8.30
+  - NIST-800-53-CM-7
+  - NIST-800-53-SA-12
+  - OWASP-LLM-Top-10-2025-LLM06
+  - SOC2-CC9-vendor-management
+  - SWIFT-CSCF-v2026-1.1
+rfc_refs:
+  - RFC-6749
+  - RFC-7519
+  - RFC-8446
+  - RFC-8725
+  - RFC-9114
+  - RFC-9421
+  - RFC-9700
+cwe_refs:
+  - CWE-22
+  - CWE-345
+  - CWE-352
+  - CWE-434
+  - CWE-494
+  - CWE-77
+  - CWE-918
+  - CWE-94
+d3fend_refs:
+  - D3-CBAN
+  - D3-CSPP
+  - D3-EAL
+  - D3-EHB
+  - D3-MFA
+last_threat_review: "2026-05-01"
+---
+
+# MCP Agent Trust Assessment
+
+## Threat Context (mid-2026)
+
+The Model Context Protocol (MCP) is an open protocol for connecting AI assistants to external tools and data sources. It is now the standard integration layer for AI coding assistants: Cursor, VS Code + GitHub Copilot, Windsurf, Claude Code, and Gemini CLI all support MCP servers.
+
+MCP creates an architectural trust problem that no existing security framework addresses.
+
+### The Trust Boundary Failure
+
+An MCP server is a process that exposes tools (functions the AI can call) and resources (data the AI can read). When an AI assistant decides to call an MCP tool, it does so based on:
+1. The tool's description (provided by the MCP server)
+2. The prompt context (which may contain adversarial instructions)
+3. The model's own judgment
+
+There is no mandatory:
+- Code signing requirement for MCP server packages
+- Tool allowlist (the client allows all tools by default)
+- Authentication requirement between the AI client and the MCP server
+- Output sanitization before returning tool results to the model
+- Permission model for what the MCP server process can access on the host
+
+This means: a malicious or compromised MCP server can execute arbitrary code by simply returning adversarial instructions in tool responses, which the AI model then follows.
+
+### CVE-2026-30615 — Windsurf MCP Zero-Interaction RCE
+
+**CVSS:** 9.8 | **RWEP:** 94/100
+
+A vulnerability in the Windsurf MCP client that allows a malicious MCP server to achieve remote code execution without any user interaction. The user does not click anything, approve anything, or trigger any visible action. The AI assistant autonomously calls the malicious tool and the code executes.
+
+**Affected:** Windsurf (all versions before patch), and by architectural similarity: Cursor, VS Code MCP extension, Claude Code, Gemini CLI (each has its own vulnerability profile; CVE-2026-30615 is specific to Windsurf's implementation but the attack surface is identical across clients).
+
+**Scale:** 150M+ combined downloads across affected AI coding assistants.
+
+**Attack path:**
+1. Attacker publishes malicious MCP server to npm or creates a typosquatting package
+2. Developer installs the package (or a legitimate package is compromised via supply chain)
+3. AI assistant starts, connects to MCP server, receives tool list
+4. At any future point: AI assistant calls a tool on the malicious server (possibly triggered by a prompt injection in a code comment, PR description, or documentation)
+5. MCP server returns a response containing adversarial instructions
+6. AI assistant follows the instructions — executes code, exfiltrates files, persists backdoor
+
+No user interaction required after installation.
+
+### Supply Chain Attack Surface
+
+Every MCP server listed in popular registries (MCP Hub, npm `@modelcontextprotocol/*`) is a potential supply chain target. Unlike npm packages where exploitation requires running arbitrary code in the package lifecycle hooks, MCP servers are explicitly *designed* to run code on behalf of the AI model. The attack surface is the entire intended functionality.
+
+**Observed patterns:**
+- Typosquatting of popular MCP servers (e.g., `@mcp/filesystem` vs `@mcpfilesystem`)
+- Legitimate servers with delayed malicious payloads (time-bomb or condition-based activation)
+- Dependency confusion attacks targeting MCP servers in private registries
+
+---
+
+## Framework Lag Declaration
+
+| Framework | Control | Why It Fails for MCP |
+|---|---|---|
+| NIST 800-53 | SA-12 (Supply Chain Protection) | Designed for software procurement and vendor management in enterprise contexts. No guidance for developer-installed AI tool plugins that execute code on behalf of AI models. SA-12's "supply chain risk management plan" does not contemplate MCP server provenance or trust. |
+| NIST 800-53 | CM-7 (Least Functionality) | "Configure systems to provide only essential capabilities." Does not address the inverted trust model where the AI assistant decides which tools to call based on model judgment, not an allowlist. |
+| NIST 800-53 | CM-11 (User-Installed Software) | User-installed software policy. MCP servers are installed by developers as part of their workflow. CM-11 doesn't distinguish between a code editor plugin and an MCP server that has RCE capability. |
+| ISO 27001:2022 | A.8.30 (Outsourced development) | Third-party development supplier controls. MCP servers are not "outsourced development" — they are runtime tool providers that execute in the context of the AI session. Requires new control category. |
+| ISO 27001:2022 | A.5.19 (Information security in supplier relationships) | Supplier risk management. Does not contemplate AI tool plugin supply chains or MCP server trust. |
+| SOC 2 | CC9 (Risk Mitigation — vendor management) | Vendor review processes. SOC 2 vendor management reviews are designed for SaaS providers with data access, not MCP servers that run local code. Audit evidence does not cover MCP server signing or allowlisting. |
+| CIS Controls v8 | Control 2 (Inventory and Control of Software Assets) | Software inventory and allowlisting. Does not explicitly cover MCP servers. AI coding assistant MCP configs are not in scope for most enterprise software inventory processes. |
+| PCI DSS 4.0 | 12.3.4 | Review and manage third-party service providers. Scoped to service providers with access to cardholder data. An MCP server running on a developer workstation accessing a PCI-scoped codebase is not clearly in scope and would not appear in vendor management reviews. |
+| SWIFT CSCF v2026 | 1.1 (SWIFT Environment Protection — allowlisted software inside the secure zone) | Mandates allowlisted software and protected operator-PC posture for the SWIFT secure zone. The control's allowlist concept is the closest existing analogue to MCP tool allowlisting, but CSCF 1.1 was written for traditional middleware and does not contemplate MCP servers, agent-mediated tool calls, or model-judgment-as-authorization on operator workstations adjacent to the SWIFT zone. |
+
+**Fundamental gap:** No current framework has a control category for "AI tool trust boundaries" — the concept that an AI model can be the authorization mechanism for code execution, and that this creates a new class of supply chain and access control risk.
+
+**Underlying RFC stack and its gaps.** MCP HTTP transport rides on RFC 9114 (HTTP/3) and/or RFC 9112 (HTTP/1.1). Server-to-agent authenticity claims rely on bearer tokens defined by RFC 7519 (JWT) — and MUST follow RFC 8725 (BCP 225, JWT Best Current Practices) to avoid `alg=none`, `kid` traversal, and audience-confusion attack classes. OAuth 2.0 (RFC 6749) is the typical authorization layer; operators should track RFC 9700 (OAuth 2.0 Security Best Current Practice, January 2025) rather than the original RFC 6749 threat model. For per-request integrity, RFC 9421 (HTTP Message Signatures, published 2024-02) is the current standard, but the MCP specification does not yet mandate it — a documented gap that lets a network-positioned attacker tamper with or replay tool responses even when the transport is TLS-terminated at a reverse proxy. Reference `data/rfc-references.json` rather than restating content here.
+
+---
+
+## TTP Mapping
+
+| ATLAS/ATT&CK ID | Technique | MCP Relevance | Gap |
+|---|---|---|---|
+| AML.T0010 | ML Supply Chain Compromise | Direct: malicious MCP server in public registry compromises AI assistant's tool execution | ATLAS covers this conceptually; no framework has a technical control |
+| AML.T0054 | Craft Adversarial Data — NLP | Indirect: adversarial prompt in tool response triggers AI to call next malicious action | No framework control |
+| AML.T0096 | LLM Integration Abuse | AI assistant is the integration point being abused — MCP tool calls are the mechanism | Not in ATT&CK; only in ATLAS v5.1.0 |
+| T1195.001 | Supply Chain Compromise: Compromise Software Dependencies | MCP server package as supply chain attack target | ATT&CK covers but enterprise controls don't reach developer MCP configs |
+| T1059 | Command and Script Interpreter | MCP server causes shell command execution via model-mediated tool call | Standard SI-3/EDR doesn't attribute this to the MCP server as origin |
+| T1190 | Exploit Public-Facing Application | CVE-2026-30615: MCP client vulnerability exploited by server | Standard vuln management covers client; MCP server trust is unaddressed |
+
+---
+
+## Exploit Availability Matrix
+
+Sourced from `data/cve-catalog.json` and `data/exploit-availability.json` as of 2026-05-11.
+
+| Threat | CVSS | RWEP | PoC Public? | CISA KEV? | AI-Accelerated Weaponization? | Patch Available? | Reboot / Version Bump Required? |
+|---|---|---|---|---|---|---|---|
+| CVE-2026-30615 (Windsurf MCP zero-interaction RCE) | 9.8 | 35 | Partial — conceptual exploit demonstrated; weaponization stage `partial` | No (architectural class; not in KEV catalog as of 2026-05) | No direct AI-assisted weaponization recorded; the attack vector itself rides on the AI agent's tool-call autonomy | Yes — vendor IDE update | IDE update / version bump required (no reboot); `live_patch_available: true` via vendor channel |
+| MCP supply chain compromise — typosquatting / dependency confusion (ATLAS AML.T0010) | N/A (technique, not vendor CVE) | N/A | Yes — public typosquatting incidents in `@modelcontextprotocol/*` namespace observed | No (technique class) | Yes — AI assistants accelerate writing of convincing malicious tool descriptions | Mitigation only: pin versions, verify npm provenance attestation, enforce allowlist | Re-install / pin to known-good version |
+| Adversarial tool response → indirect prompt injection (ATLAS AML.T0054 in MCP context) | N/A (technique, not vendor CVE) | N/A | Yes — public research demonstrations; weaponizable wherever output is unsanitized | No | Yes — adversarial instruction crafting is a documented AI-accelerated capability | Mitigation only: output sanitization, system-prompt authority hierarchy, tool allowlisting | Client configuration change; no version bump strictly required |
+| AML.T0096 — MCP tool call as covert C2 conduit | N/A (technique) | N/A | Yes — SesameOp-class techniques apply when an MCP tool call is the relay | No | Yes — see `data/atlas-ttps.json` AML.T0096 real-world instances | Mitigation only: process-level AI/MCP egress monitoring | Configuration / monitoring change |
+
+**Interpretation:** CVE-2026-30615 has a vendor patch and live-update path — verify Windsurf clients are on the patched version. The remaining rows are technique classes with no vendor CVE; mitigation is configurational (signed manifests, tool allowlists, bearer auth, output sanitization, version pinning) and cannot be "patched away" by a single vendor release.
+
+---
+
+## Analysis Procedure
+
+### Step 1: Inventory installed MCP servers
+
+For each developer workstation or shared AI system:
+
+```bash
+# AI coding assistant MCP configs (check all that are installed):
+cat ~/.claude/settings.json | jq '.mcpServers'
+cat ~/.cursor/mcp.json
+cat ~/.windsurf/mcp.json
+cat ~/.gemini/settings.json
+cat ~/.vscode/settings.json | grep -A 20 '"mcp"'
+```
+
+For each server found, record:
+- Package name and version
+- Installation source (npm, local path, custom registry)
+- What tools it exposes
+- What filesystem/network/process permissions it requires
+- Whether an explicit tool allowlist exists
+
+### Step 2: Verify package provenance
+
+For each npm-installed MCP server:
+```bash
+npm pack --dry-run <package-name>
+npm audit <package-name>
+# Check: is the package signed? (npm provenance)
+npm view <package-name> dist.integrity
+# Check: does it match the expected hash?
+```
+
+Red flags:
+- Recent publication (< 30 days) with high download counts
+- Package name close to a well-known server (typosquatting)
+- Dependencies with postinstall scripts
+- No npm provenance attestation
+
+### Step 3: Assess trust configuration
+
+For each MCP client configuration, check:
+
+**Tool allowlisting:**
+- Is there an explicit `allowed_tools` list? (restricts which tools the AI can call)
+- If no allowlist: the AI can call any tool the server exposes, including tools added after installation
+- Risk: server can add new malicious tools in an update, no re-consent required
+
+**Authentication:**
+- Does the MCP server require authentication (bearer token, mTLS)?
+- If no auth: any local process can connect to the MCP server and impersonate the AI client
+- Applies particularly to MCP servers that listen on a local port
+
+**Output trust:**
+- Are MCP server responses treated as trusted (passed directly to model context)?
+- If yes: adversarial instructions in tool responses execute in model context
+
+**Process isolation:**
+- Does the MCP server process run with the same privileges as the AI client?
+- Does it have filesystem access beyond its stated scope?
+- Does it have network access?
+
+### Step 4: Score MCP trust posture
+
+| Factor | Risk Score |
+|---|---|
+| No tool allowlist | +High |
+| No package signing verification | +High |
+| No authentication required by server | +Medium |
+| Server has filesystem read/write access | +High |
+| Server has shell/process execution access | +Critical |
+| Server has network access | +Medium |
+| Outputs not sanitized | +High |
+| Server was installed from public registry without audit | +Medium |
+| Server version was auto-updated | +Medium |
+| No MCP server activity logging | +High |
+
+### Step 5: Generate remediation
+
+**Immediate (regardless of risk posture):**
+1. Audit all installed MCP servers — full inventory
+2. Remove any servers that cannot be verified by provenance
+3. Pin all MCP server versions (no auto-update)
+4. Enable logging for all MCP tool calls (what tool was called, what arguments, what response)
+
+**Configuration hardening:**
+```json
+{
+  "mcpServers": {
+    "filesystem": {
+      "command": "npx",
+      "args": ["-y", "@modelcontextprotocol/server-filesystem@1.2.3"],
+      "allowed_tools": ["read_file", "list_directory"],
+      "env": {}
+    }
+  }
+}
+```
+
+**Trust tier model:**
+- Tier 0 (no install): MCP servers with shell/process execution, network exfil capability, unsigned
+- Tier 1 (audited, pinned, allowlisted): Standard workspace MCP servers (filesystem, git, DB read-only)
+- Tier 2 (monitored): Any server with write access — every tool call logged and alertable
+
+**For organizational deployments:**
+- Maintain an approved MCP server registry (name, version, hash, approved scopes)
+- Distribute approved MCP configs via MDM/endpoint management
+- Block unapproved MCP server installations on managed workstations
+- Monitor for new MCP server additions in endpoint config files
+
+---
+
+## Output Format
+
+```
+## MCP Trust Assessment
+
+**Assessment Date:** YYYY-MM-DD
+**Scope:** [workstations / AI systems assessed]
+
+### Installed MCP Server Inventory
+| Server | Version | Source | Tools Exposed | Filesystem | Network | Shell | Auth Required | Allowlist |
+|--------|---------|--------|---------------|------------|---------|-------|---------------|-----------|
+
+### CVE-2026-30615 Exposure
+[Windsurf version check — patched/unpatched]
+
+### Trust Posture Score
+[Per server: Critical/High/Medium/Low with factor breakdown]
+
+### Immediate Actions Required
+[Servers to remove, versions to pin, configs to lock]
+
+### Hardened Configuration
+[Ready-to-use JSON config for each AI client in scope]
+
+### Framework Gap Declaration
+[Per-framework: what control nominally applies, why it doesn't cover MCP trust, what a real control requires]
+
+### Organizational Policy Requirements
+[If org-level deployment: approved registry, MDM config, monitoring requirements]
+```
+
+---
+
+## Hand-Off / Related Skills
+
+After producing the MCP trust assessment output, the operator should chain into the following skills. Each entry is specific to a finding class this skill produces.
+
+- **`supply-chain-integrity`** — MCP servers are software supply chain artifacts. For every server in the inventory, produce SLSA-level attestation, Sigstore signature verification, and in-toto provenance. The MCP ecosystem ships overwhelmingly via npm without provenance; this is the artefact-level control that the vendor-management gap above implicitly delegates to.
+- **`defensive-countermeasure-mapping`** — map MCP trust failures to D3FEND counters: D3-EHB (hash-based executable allowlisting for the MCP server binary), D3-CBAN (certificate-based authentication between client and server), D3-MFA (multi-factor authentication on the MCP control plane where remote), D3-CSPP (client-server payload profiling on tool call / tool response shapes). The trust-tier model in Step 5 above is operationalised through these counters.
+- **`attack-surface-pentest`** — explicitly include each installed MCP server in the in-scope target list for pen-testing and adversary emulation. 2025-vintage pen-test scopes overwhelmingly omit MCP servers; this is the single biggest assumed-out-of-scope gap discovered during this skill's analysis.
+- **`dlp-gap-analysis`** — MCP tool arguments are a DLP egress channel. Verify that SDK-level prompt logging captures tool-arg egress (filenames, file contents, credential strings passed as arguments) and that DLP classifiers run on the tool-call payload, not just on file/email egress. Without this, an MCP server with filesystem read access is a fully invisible exfiltration path.
+- **`framework-gap-analysis`** — when the MCP trust gap fails a specific framework control (NIST-800-53-CM-7 / ISO-27001-2022-A.8.30 / SOC2-CC9 vendor management), invoke this skill to produce the formal gap declaration tied to the organisation's compliance scope and jurisdiction, including the EU NIS2 / DORA / AU Essential 8 mappings per AGENTS.md rule #5.
+
+For ephemeral / serverless AI-pipeline contexts (per AGENTS.md rule #9): live SLSA-attestation verification at runtime is architecturally impossible for inline-pulled MCP servers in serverless functions. The scoped alternative is build-time attestation pinning baked into the function image, with the runtime fetch path disabled at the network layer.
+
+---
+
+## Compliance Theater Check
+
+> "Your vendor management control (CC9 / SA-12 / A.5.19) documents a review process for third-party software with access to sensitive systems. Enumerate the MCP servers installed on developer workstations that have access to production codebases or credentials. How many of those MCP servers went through your vendor review process? If the answer is zero, the vendor management control is theater for the attack surface where AI-assisted supply chain attacks are actually occurring."