@blamejs/exceptd-skills 0.9.1

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

@@ -0,0 +1,440 @@
+---
+name: ai-c2-detection
+version: "1.0.0"
+description: Detect adversary use of AI APIs as covert C2 — SesameOp pattern, PROMPTFLUX/PROMPTSTEAL behavioral signatures, response playbook
+triggers:
+  - ai c2
+  - ai command and control
+  - sesameop
+  - promptflux
+  - promptsteal
+  - ai api abuse
+  - llm c2
+  - covert channel ai
+  - aml.t0096
+data_deps:
+  - atlas-ttps.json
+  - cve-catalog.json
+  - framework-control-gaps.json
+atlas_refs:
+  - AML.T0096
+  - AML.T0017
+attack_refs:
+  - T1071
+  - T1102
+  - T1568
+framework_gaps:
+  - NIST-800-53-SI-3
+  - NIST-800-53-SC-7
+  - ISO-27001-2022-A.8.16
+  - SOC2-CC7-anomaly-detection
+rfc_refs:
+  - RFC-8446
+  - RFC-9180
+  - RFC-9458
+  - RFC-9421
+  - RFC-9114
+  - RFC-9000
+d3fend_refs:
+  - D3-CA
+  - D3-CSPP
+  - D3-DA
+  - D3-IOPR
+  - D3-NI
+  - D3-NTA
+  - D3-NTPM
+last_threat_review: "2026-05-01"
+---
+
+# AI C2 Detection
+
+## Threat Context (mid-2026)
+
+### SesameOp — AI APIs as Covert C2 (ATLAS AML.T0096)
+
+The SesameOp campaign documented a technique that has since been replicated and expanded: adversaries repurposing legitimate AI agent APIs as covert command-and-control channels.
+
+**Technical pattern:**
+```
+Compromised host                    Attacker
+      |                                |
+      |  POST /v1/messages             |
+      |  {"messages": [                |
+      |    {"role": "user",            |
+      |     "content": "b64:<cmd>"}    |  ← Command encoded in prompt
+      |  ]}                            |
+      |                                |
+      |  {"choices": [{                |
+      |    "message": {                |
+      |     "content": "b64:<data>"}   |  ← Exfiltrated data in completion
+      |  }]}                           |
+      |                                |
+```
+
+The malware on the compromised host:
+1. Encodes commands/exfiltrated data as base64 or other encoding within semantically valid text
+2. Sends "legitimate-looking" API calls to OpenAI, Anthropic, Google, or Azure AI endpoints
+3. Receives attacker instructions encoded in the AI's response
+4. The AI API is simply relaying encoded content — it is not the attacker's infrastructure, it's the transport
+
+**Why traditional C2 detection fails:**
+- No DGA (domain generation algorithm): the endpoint is a legitimate, well-known AI service
+- No unusual TLS certificates: certs belong to OpenAI/Anthropic/Google
+- No beaconing pattern: AI API calls are bursty and aperiodic, indistinguishable from legitimate developer usage
+- No payload size anomaly in the traffic layer: prompt + completion sizes vary widely for legitimate workloads
+- No protocol anomaly: standard HTTPS REST API calls
+- No reputation signal: blocking the endpoint blocks legitimate AI usage
+
+The only detection surfaces are:
+1. Behavioral: does this host/process/user normally make AI API calls? Is the pattern consistent with legitimate usage?
+2. Content: is the prompt/completion content encoded or high-entropy? (requires TLS inspection)
+3. Correlation: do AI API calls correlate with file access, lateral movement, or other attack-indicative activity?
+4. Process: what process is making the AI API call? Is it expected to use AI APIs?
+
+---
+
+### PROMPTFLUX Malware Family
+
+PROMPTFLUX is a malware family that queries public LLMs during execution to generate novel evasion code in real-time.
+
+**Execution pattern:**
+1. Initial compromise via standard delivery (phishing, exploit)
+2. Malware runs, hits an AV/EDR detection signal
+3. Queries a public LLM: "Generate functionally equivalent code to [detected snippet] using different variable names and control flow that doesn't match common malware patterns"
+4. LLM returns new variant
+5. Malware re-deploys with new variant, bypassing static signatures
+6. Repeat indefinitely
+
+**Detection signature (behavioral, not content):**
+- A process making repeated AI API calls during or immediately after security product alerts
+- AI API calls from processes that are not known AI-using applications (e.g., a Chrome extension making calls to OpenAI, or a background service with no UI making API calls)
+- LLM query content containing: code snippets, function names, API patterns that would be unusual for conversational use
+
+**Why SI-3 (Malicious Code Protection) fails:**
+SI-3 requires malicious code protection mechanisms that "detect and eradicate malicious code." PROMPTFLUX generates unique code per detection event. There is no signature to detect, because every variant is novel. SI-3 provides zero protection against AI-generated dynamic evasion.
+
+---
+
+### PROMPTSTEAL Malware Family
+
+PROMPTSTEAL uses LLMs as live intelligence analysts for exfiltration targeting.
+
+**Execution pattern:**
+1. Compromise host, gain access to credential stores, user files, and email
+2. Query LLM: "Given this list of files and email subjects, which files are most likely to contain credentials or sensitive business information?"
+3. LLM prioritizes the exfiltration target list
+4. Exfiltrate prioritized targets
+5. Query LLM: "Given these captured credentials for [company], what systems are most likely accessible with these credentials?"
+6. LLM provides lateral movement guidance
+
+**PROMPTSTEAL turns a commodity compromise into a targeted, prioritized attack** without requiring any attacker-side human intelligence work. The LLM is doing the targeting, prioritization, and strategy work.
+
+**Detection:**
+- AI API calls from processes with access to sensitive file paths or credential stores
+- AI prompts containing filenames, email subjects, or data that could be used for targeting
+- Unusual AI API usage from processes associated with file scanning or credential access patterns
+
+---
+
+## Framework Lag Declaration
+
+| Framework | Control | Why It Fails |
+|---|---|---|
+| NIST 800-53 SI-3 | Malicious Code Protection | Signature/behavioral detection for known malware. AI-generated dynamic evasion (PROMPTFLUX) produces unique code per execution. Zero signature coverage. |
+| NIST 800-53 SC-7 | Boundary Protection | Egress controls block unauthorized destinations. AI API endpoints (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com) are not unauthorized — they are commonly whitelisted for legitimate use. SC-7 cannot distinguish C2 traffic from legitimate AI API usage at the network layer. |
+| NIST 800-53 SI-4 | System Monitoring | Monitor for attacks and indicators of attack. Current SI-4 implementations don't baseline AI API usage per process or alert on high-entropy prompt content. |
+| ISO 27001:2022 A.8.16 | Monitoring Activities | Monitoring of systems, networks, and applications. No guidance for AI API behavioral baseline, no mention of AI traffic as a monitoring concern. |
+| SOC 2 CC7 | System Operations (Anomaly Detection) | Detect and respond to security events. CC7 implementations baseline network traffic and system events. AI API calls are typically in the same anomaly detection blind spot as other SaaS traffic. |
+| ATT&CK T1071 | Application Layer Protocol | ATT&CK documents C2 over application protocols. AI API as C2 fits the technique but detection guidance doesn't address legitimate-endpoint C2 specifically. |
+
+---
+
+## Detection Architecture
+
+### Layer 1: Process-Level Behavioral Baseline
+
+Build a model of which processes are expected to make AI API calls on each host type.
+
+**Expected AI API callers by host type:**
+
+| Host Type | Expected AI API Callers |
+|---|---|
+| Developer workstation | IDE processes (cursor, code), terminal sessions, browser |
+| CI/CD runner | Build tools if AI-assisted (specific known tools only) |
+| Production server | Application processes if AI features are deployed (specific, named) |
+| User workstation (non-dev) | Browser, Office productivity suite (if AI features enabled) |
+| Database server | None expected |
+| Network device | None expected |
+
+**Alert conditions:**
+- AI API calls from processes not on the expected list for that host type
+- AI API calls from system services or background processes
+- AI API calls at unusual hours relative to the user's normal working pattern
+- Spike in AI API call frequency from a single process (PROMPTFLUX's rapid querying pattern)
+
+### Layer 2: Behavioral Correlation
+
+Correlate AI API calls with other security-relevant events on the same host:
+
+```
+AI API call + file_access(sensitive_path) within 5 minutes → ALERT
+AI API call + credential_access event within 5 minutes → ALERT  
+AI API call + network_scan event within 10 minutes → ALERT
+AI API call + security_alert event within 1 minute → HIGH ALERT (PROMPTFLUX pattern)
+AI API call + large_file_transfer within 10 minutes → ALERT (PROMPTSTEAL exfil)
+```
+
+### Layer 3: Traffic Content Analysis (requires TLS inspection)
+
+If TLS inspection is deployed at the boundary:
+
+**High-entropy content detection:**
+- Calculate entropy of the `content` field in AI API requests/responses
+- Flag: entropy > 6.5 bits/byte in prompt content (suggests encoding)
+- Flag: base64 patterns in prompt/completion content that aren't image data
+- Flag: prompt content containing recognizable file paths, usernames, or credential patterns
+
+**Prompt pattern matching:**
+- Flag: prompts containing code snippets + requests for "equivalent" or "alternative" implementations
+- Flag: prompts listing filenames, email subjects, or asking for prioritization of sensitive data
+- Flag: prompts requesting "code that avoids detection" or equivalent phrasing
+
+### Layer 4: Response Monitoring
+
+Monitor AI API responses for anomalous patterns:
+- Responses containing executable code when the calling application has no known code-generation use case
+- Responses containing lateral movement guidance (lists of systems, exploitation advice)
+- Large response volumes from processes that normally produce small queries
+
+---
+
+## Incident Response Playbook — AI C2
+
+### Detection trigger
+
+Any of these triggers:
+- Process-level anomaly: unexpected process making AI API calls
+- Behavioral correlation: AI API call + security-relevant event correlation
+- Content alert: high-entropy or encoded content in AI API traffic
+- Threat intel match: C2 infrastructure or campaign IOC matches observed AI API destination
+
+### Triage (0–30 minutes)
+
+1. Identify the process making AI API calls
+2. Check process legitimacy: is this a known application? Signed binary? Expected on this host?
+3. Review call timing: when did these calls start? What changed on the host before?
+4. Pull the last 100 API calls (prompt + response content if TLS inspection is available)
+5. Check for file access and credential access events correlated in time
+
+### Investigation (30 minutes – 4 hours)
+
+1. If TLS inspection available: export prompt/response content for analysis
+   - Decode any base64 or encoded content
+   - Check prompts for: code rewrite requests (PROMPTFLUX), targeting/prioritization requests (PROMPTSTEAL), encoded commands (SesameOp)
+2. Timeline reconstruction: what did this process do before and after AI API calls?
+3. Lateral movement check: have other hosts shown AI API behavioral anomalies?
+4. Exfiltration check: did any data leave the network via AI API responses?
+
+### Containment
+
+1. Block AI API destinations at the boundary for the affected host/process (scoped to minimize business disruption)
+2. Preserve: full packet capture of AI API traffic from affected host, process memory dump if feasible, file system timeline
+3. Rotate: credentials that may have been accessed by PROMPTSTEAL pattern
+4. Isolate: host if lateral movement is confirmed or suspected
+
+### Evidence Handling
+
+AI API traffic logs (prompt + response) are primary evidence. Preserve:
+- Network flow records (timestamps, volumes, endpoints)
+- TLS inspection logs (full content if captured)
+- Process execution logs
+- File access logs correlated with AI API call timeline
+- Credential access events
+
+### Attribution
+
+Map observed TTPs to:
+- SesameOp campaign indicators if C2 pattern matches
+- PROMPTFLUX indicators if code rewrite requests observed
+- PROMPTSTEAL indicators if targeting/prioritization pattern observed
+- Novel campaign if pattern doesn't match known families — document as new indicator
+
+---
+
+## Detection Rule Examples
+
+### Sigma-style rule — PROMPTFLUX
+
+```yaml
+title: PROMPTFLUX Pattern - AI API Call Following Security Alert
+status: experimental
+logsource:
+  product: endpoint
+  service: process
+detection:
+  condition: ai_api_call and security_alert within 60s
+  ai_api_call:
+    TargetHostname|contains:
+      - 'api.openai.com'
+      - 'api.anthropic.com'
+      - 'generativelanguage.googleapis.com'
+      - 'api.cohere.ai'
+  security_alert:
+    EventID: [1116, 1117]  # Windows Defender alert example
+timeframe: 60s
+falsepositives:
+  - Developer using AI assistant to investigate security alert (verify by user identity)
+level: high
+```
+
+### Sigma-style rule — Unexpected AI API Origin
+
+```yaml
+title: AI API Call from Unexpected Process
+status: experimental
+logsource:
+  product: network
+  service: dns
+detection:
+  condition: ai_domain and not expected_process
+  ai_domain:
+    dns_query|contains:
+      - 'api.openai.com'
+      - 'api.anthropic.com'
+  expected_process:
+    ProcessName|contains:
+      - 'Code.exe'
+      - 'Cursor.exe'
+      - 'chrome.exe'
+      - 'msedge.exe'
+falsepositives:
+  - New AI-using applications deployed — update allowlist
+level: medium
+```
+
+---
+
+## TTP Mapping (MITRE ATLAS v5.1.0 + MITRE ATT&CK)
+
+| ID | Source | Technique | C2 Relevance | Gap Flag — Which Detection Control Fails |
+|---|---|---|---|---|
+| AML.T0096 | ATLAS v5.1.0 | LLM API as covert C2 / LLM Integration Abuse | Direct: SesameOp encodes commands and exfiltrated data in prompt and completion fields against api.openai.com, api.anthropic.com, generativelanguage.googleapis.com. AI provider domain is the relay, not the attacker C2 endpoint. | NIST-800-53-SC-7 (Boundary Protection) — AI provider domains are allowlisted in most enterprise egress for legitimate developer and product use, so boundary inspection cannot distinguish benign developer prompts from C2-encoded prompts. See SC-7 entry in `data/framework-control-gaps.json` — real requirement is SDK-level prompt logging with identity binding, anomaly detection on prompt-shape and token-volume, and an allowlist that enumerates the sanctioned business reason per identity. Boundary-only SC-7 evidence is incomplete for any org with AI API access in production. |
+| AML.T0017 | ATLAS v5.1.0 | Develop Capabilities — including adversary use of inference APIs to develop/refine attack capability (and model exfiltration via inference API where applicable) | PROMPTFLUX queries public LLMs to generate per-execution evasion code; PROMPTSTEAL uses LLMs to prioritise exfiltration targets. The inference API is doing capability-development work for the adversary in real time. | NIST-800-53-SI-3 fails — there is no static signature for code generated per-event by a public LLM. NIST-800-53-SI-4 fails as commonly deployed — no AI-API behavioural baseline per process/identity. |
+| T1071 | ATT&CK | Application Layer Protocol (C2) | AI C2 traffic is standard HTTPS REST to api.openai.com or equivalent. Application-protocol C2 detection that looks for DGA, unusual TLS, or beaconing does not fire. | SC-7 boundary control sees only the destination domain (allowlisted) — no protocol anomaly to alert on. Detection requires identity-bound prompt content inspection, which SC-7 as written does not require. |
+| T1102 | ATT&CK | Web Service (C2 via legitimate web service) | AI API endpoints are exactly the "legitimate web service used as C2" pattern that T1102 describes — but at scale and pre-allowlisted in nearly every enterprise. | SOC 2 CC7 anomaly-detection control: AI API traffic shares the SaaS blind spot — typically not baselined per process or identity. ISO 27001 A.8.16 monitoring activities: no guidance for AI-API-shaped traffic. |
+| T1568 | ATT&CK | Dynamic Resolution | AI provider responses can carry encoded instructions that dynamically determine the next-hop behaviour for the malware (effectively model-mediated dynamic resolution of the next attacker instruction). | No standard DNS-tunnelling or DGA detection applies — the "resolution" happens inside an HTTPS payload to a trusted endpoint. SC-7 cannot see it without SDK-level prompt + response logging. |
+
+---
+
+## Exploit Availability Matrix
+
+The threats in this skill are adversary TTPs and malware families rather than vendor vulnerabilities, so they carry no CVE IDs in `data/cve-catalog.json`. Public incident reports and ATLAS `real_world_instances` are the primary evidence base.
+
+| Threat | CVE? | Public Incident Reporting / PoC | CISA KEV? | AI-Accelerated? | EDR / SIEM Detection Support (mid-2026) | AI Provider Abuse Signal Available? |
+|---|---|---|---|---|---|---|
+| SesameOp (AML.T0096) | No — adversary TTP, not vendor vuln | Yes — public campaign write-ups; ATLAS AML.T0096 lists SesameOp under `real_world_instances` | No (technique class; KEV catalogs vendor vulns only) | Yes — the entire technique is AI-API-mediated | Minimal — most EDR and SIEM products do not baseline AI API calls per process/identity or inspect prompt/response content. A handful of vendors ship experimental rules; coverage is fragmentary. | Partial — OpenAI, Anthropic, and Google publish aggregate abuse and policy-violation reports; per-tenant, per-request abuse telemetry that an enterprise SOC can subscribe to is not generally available as of 2026-05. |
+| PROMPTFLUX | No — adversary malware family | Yes — public reporting documenting LLM-mediated evasion code generation per execution | No | Yes — every variant is AI-generated; the technique is AI by definition | Minimal at signature layer (zero signatures by design). Behavioural detection (AI API call within 60s of an AV/EDR alert from an unexpected process) is feasible but not shipped out-of-the-box in major EDRs. | None enterprise-subscribable; AI provider abuse teams act on their own telemetry. |
+| PROMPTSTEAL | No — adversary malware family | Yes — public reporting on LLM-assisted exfiltration prioritisation and lateral-movement guidance | No | Yes — LLM is acting as the adversary's live intelligence analyst | Minimal — requires correlation of AI API calls with credential-access and file-access events. Possible to build in a SIEM; not a default rule pack. | None enterprise-subscribable. |
+| AI C2 — generic (T1071 / T1102 / T1568 over AI APIs) | No | Yes — research and red-team demonstrations across all major AI providers | No | Yes | Minimal — boundary controls treat AI provider domains as allowlisted SaaS; content-layer inspection requires TLS interception plus SDK-level prompt logging, which most orgs do not run. | Partial / inconsistent across providers. |
+
+**Interpretation:** there is no patch to apply because there is no vendor CVE. Mitigation is detection-architectural: SDK-level prompt logging with identity binding, AI-API behavioural baselining per process, correlation with credential/file/scan events, and an explicit allowlist that enumerates the sanctioned business reason per identity (per the SC-7 real_requirement in `data/framework-control-gaps.json`).
+
+### RFC Transport Reality
+
+AI provider egress is TLS 1.3 (RFC 8446) terminated at the provider, so boundary inspection at the enterprise edge does not yield prompt content; Encrypted Client Hello uses RFC 9180 (HPKE), and for ECH-enabled connections even the destination hostname is hidden from boundary inspection. Oblivious HTTP (RFC 9458, January 2024) is a published-standard covert-channel candidate — every AI request gets relayed, so the visible destination is the relay rather than the AI provider, and SC-7 boundary tooling vendors are 12–18 months behind on detection guidance for this class. AI providers increasingly serve over HTTP/3 (RFC 9114) on QUIC (RFC 9000); enterprise NGFW HTTP/3 inspection coverage as of mid-2026 is uneven, with many boundary stacks default-denying QUIC or falling back to passive observation. HTTP Message Signatures (RFC 9421) are how AI providers publish abuse signals via webhook, and subscribing requires verifying these signatures. See `data/rfc-references.json` for the canonical entries rather than restating content here.
+
+---
+
+## Analysis Procedure
+
+### Step 1: Enumerate AI API egress destinations from the last 30 days
+
+Pull from the boundary or SaaS-egress logs all connections to:
+- `api.openai.com`, `api.anthropic.com`, `generativelanguage.googleapis.com`, `api.cohere.ai`, regional Azure OpenAI endpoints (`*.openai.azure.com`), AWS Bedrock endpoints (`bedrock-runtime.*.amazonaws.com`), and any internal AI gateway.
+
+For each destination, record: source identity (user, service account, machine account), source process where available, request volume, request times, and whether the calling host is a developer workstation, a CI runner, a production server, or another class.
+
+### Step 2: Cross-reference each calling identity against a sanctioned business reason
+
+For each identity making AI API calls, answer: is there a documented business reason for this identity to call AI APIs? Examples of sanctioned reasons: named developer using an AI IDE, named product using a named AI feature, named CI tool with an AI-assist component. Identities making AI API calls without a sanctioned business reason are the first investigation tier — they map directly to the SC-7 gap (allowlist without per-identity business reason is theater).
+
+### Step 3: Flag prompts with anomalous shape
+
+Requires SDK-level prompt logging or TLS inspection. For each request, compute:
+- Token volume vs. that identity's rolling baseline. Outliers above the 99th percentile are flagged.
+- Time-of-day vs. that identity's documented working pattern. Off-hours calls from human-developer identities are flagged.
+- Linguistic shape: prompts that are not natural language (high entropy, base64, hex, or structured token streams that do not match a known schema) are flagged. PROMPTFLUX and SesameOp both produce non-conversational prompt shapes.
+- Repeated identical or near-identical prompt structures from the same identity over short windows — consistent with automated C2 polling.
+
+### Step 4: Check for SesameOp signature shape
+
+Specifically inspect for the SesameOp pattern: OpenAI Assistants API used with a deterministic system-prompt pattern and prompt/completion bodies carrying encoded payloads. Indicators include: a fixed system prompt that does not vary across sessions, completions containing base64 or other encodings exceeding 64 bytes, and a request cadence that is bursty but persistent across hours/days without an obvious developer-session correlation. Cross-reference identity from Step 2 — SesameOp on a service account with no sanctioned AI use is a high-confidence finding.
+
+### Step 5: Verify SDK-level prompt logging is enabled
+
+If SDK-level prompt logging is off, the org cannot detect AI C2 at all — Steps 3 and 4 produce empty results regardless of whether C2 is occurring. Confirm, per AI SDK in use:
+- Is full prompt content logged with identity binding?
+- Is full completion content logged with identity binding?
+- Are logs retained long enough for incident investigation (minimum 90 days)?
+- Are logs forwarded to the SIEM or detection platform?
+
+If any answer is "no," the org's AI-C2 detection coverage is structurally zero for that SDK, and that finding is itself the most important output of this analysis.
+
+### Step 6: Correlate AI API calls with security-relevant host events
+
+For each flagged identity from Steps 2–4, pull the corresponding host-event timeline from EDR/sysmon: file access (especially credential stores and sensitive paths), process creation, network scans, lateral movement indicators, AV/EDR alerts. Apply the correlation windows from the Detection Architecture section (file access within 5 minutes, security alert within 1 minute — PROMPTFLUX pattern, large transfer within 10 minutes — PROMPTSTEAL pattern).
+
+### Step 7: Produce findings
+
+For every identity flagged in Step 2, every prompt flagged in Step 3, every SesameOp shape match in Step 4, and every correlation in Step 6, write a finding mapped to AML.T0096 / AML.T0017 / T1071 / T1102 / T1568 with the specific evidence and the SC-7 / SI-3 / SI-4 / CC7 / A.8.16 gap that allowed it to land.
+
+---
+
+## Compliance Theater Check
+
+> "Your SC-7 boundary-protection evidence shows AI provider domains — `api.openai.com`, `api.anthropic.com`, `generativelanguage.googleapis.com`, Azure OpenAI endpoints, Bedrock endpoints — on the egress allowlist, with NetFlow or Zeek records demonstrating that egress is monitored. Now answer two questions. First: for each AI provider domain on the allowlist, does the allowlist entry enumerate the specific sanctioned business reason and the identities or services entitled to use it, or is the entry a blanket allow for the domain? Second: do you have SDK-level prompt and completion logging, bound to identity, retained for at least 90 days, and forwarded to the SIEM, for every place AI APIs are called in production? If the allowlist is a blanket domain allow and SDK-level prompt logging is absent, the SC-7 control is theater for AI C2 — boundary inspection of an allowlisted domain cannot distinguish a developer prompt from a SesameOp-encoded C2 prompt, and you have no content-layer evidence to fall back on. SC-7 evidence is structurally incomplete for any org using AI APIs in production unless both an identity-bound business-reason allowlist and SDK-level prompt logging are in place. The control gap is recorded in `data/framework-control-gaps.json` under NIST-800-53-SC-7 — the real requirement names exactly these components."
+
+---
+
+## Output Format
+
+```
+## AI C2 Detection Assessment
+
+**Date:** YYYY-MM-DD
+**Scope:** [hosts / network segments assessed]
+
+### Current Detection Coverage
+| Detection Layer | Deployed | Coverage |
+|---|---|---|
+| Process-level AI API baseline | Yes/No | [% of host types covered] |
+| Behavioral correlation (AI + file/cred/scan) | Yes/No | [configured correlations] |
+| TLS inspection for AI traffic | Yes/No | [% of AI API traffic] |
+| Response monitoring | Yes/No | [coverage] |
+
+### Coverage Gaps
+[What's missing from the detection architecture]
+
+### Active Indicators
+[If this is a live investigation: current IOCs, correlated events]
+
+### Detection Rule Recommendations
+[Specific rules to add, tuned for the org's AI tooling inventory]
+
+### Framework Gap Declaration
+[Per framework: what monitoring control exists, why it doesn't address AI C2]
+```
+
+---
+
+## Hand-Off / Related Skills
+
+After producing the AI C2 detection assessment, the operator should chain into the following skills. Each entry is specific to a finding class this skill produces.
+
+- **`dlp-gap-analysis`** — AI-API-as-C2 is a DLP egress channel. The same SDK-level prompt logging recommended above (identity-bound, retained 90+ days, forwarded to SIEM) is the exact instrumentation that detects DLP egress through prompts. Treat the AI API endpoint as a sanctioned-SaaS DLP surface and apply prompt-content classifiers, not just file/email classifiers. A SesameOp-encoded payload is a DLP event the moment the prompt leaves the host.
+- **`defensive-countermeasure-mapping`** — map AI C2 findings to D3FEND: D3-NTA / D3-NTPM (network traffic analysis plus policy mapping for AI provider egress, including the QUIC / HTTP/3 path called out in the RFC Transport Reality section), D3-IOPR (prompt-shape profiling per identity baseline), D3-CSPP (client-server payload profiling on prompt and completion bodies when TLS-inspected). The Layer 1–4 detection architecture maps directly to these counters.
+- **`mcp-agent-trust`** — AI-API-mediated C2 frequently routes through MCP tools whose privilege scope exceeds the documented business reason. When PROMPTSTEAL-pattern correlations surface (AI API call + credential-store access + large-egress), pivot into MCP trust assessment as a compensating control: tightening MCP tool allowlists and removing shell/process-execution-capable servers reduces the blast radius of the AI agent that the C2 is steering.
+- **`attack-surface-pentest`** — AI-API egress channels must be enumerated in attack-surface management and exercised in adversary-emulation engagements. Most pen-test scopes test for outbound DNS / generic HTTPS C2 and do not specifically exercise legitimate-AI-SaaS-as-C2. Without this, the SesameOp / PROMPTFLUX / PROMPTSTEAL signature shapes are detected only post-incident.
+- **`compliance-theater`** — test whether the org's SC-7 boundary-protection claim is satisfied by domain allowlisting alone. It is theater: see the SC-7 entry the project added in v0.3.0 of `data/framework-control-gaps.json`, which names the real requirement (identity-bound business-reason allowlist plus SDK-level prompt logging). Boundary inspection of an allowlisted AI provider domain cannot distinguish a developer prompt from a C2-encoded prompt.
+
+For ephemeral / serverless workloads (per AGENTS.md rule #9): per-host EDR-side correlation (Layer 2) is architecturally impossible when the host's lifetime is shorter than the correlation window. The scoped alternative is identity-bound prompt logging at the SDK layer combined with workload-identity correlation in the SIEM (e.g., correlate AI API calls by IAM role / service-account identity rather than by host), which preserves the SesameOp / PROMPTFLUX / PROMPTSTEAL signature shapes across short-lived function invocations.