Secure, Defend, and Thwart: CSF 2.0 functions mapped to SWT3 procedures for AI system cybersecurity governance.
Who this is for: Security architects implementing AI-aware cybersecurity controls, CISOs evaluating AI risk within existing CSF 2.0 programs, FedRAMP and FISMA compliance teams extending controls to AI workloads, and third-party assessors evaluating AI system security posture.
Status: Preliminary Draft. NIST published IR 8596 on December 16, 2025. Public comment period closed January 30, 2026. Final publication expected 2026. Built with input from 6,500+ contributors across government, academia, and industry. Organizations should begin alignment now --- the final version will set the standard for AI cybersecurity governance.
NIST IR 8596 overlays AI-specific considerations on the Cybersecurity Framework (CSF) 2.0. Rather than creating a separate AI security framework, it extends existing CSF 2.0 outcomes with AI Focus Areas that address the unique risks AI systems introduce to organizational cybersecurity posture.
The profile addresses three fundamental challenges:
Organizations already using CSF 2.0 can adopt the Cyber AI Profile incrementally. It does not replace existing cybersecurity programs. Instead, it identifies where AI considerations must be layered onto current controls and processes.
SWT3 witness procedures provide the cryptographic evidence layer that proves these AI-specific controls are operating continuously, not just documented in policy.
Securing AI systems against adversarial manipulation, data poisoning, model theft, and supply chain compromise.
Maps primarily to Protect and Identify CSF 2.0 functions.
SWT3 procedures: AI-SEC.1, AI-SEC.2, AI-GRD.1, AI-DATA.1, AI-SBOM.1, AI-HW.1
Using AI to enhance cybersecurity operations, including threat detection, anomaly identification, and automated incident response.
Maps primarily to Detect and Respond CSF 2.0 functions.
SWT3 procedures: AI-MDL.3, AI-INF.1, AI-INCIDENT.1, AI-MDL.1
Countering adversarial use of AI for cyberattacks, including deepfakes, automated vulnerability exploitation, and AI-generated phishing.
Maps primarily to Detect and Respond CSF 2.0 functions.
SWT3 procedures: AI-CYBER.1, AI-REV.1
Each CSF 2.0 function maps to specific AI Focus Areas and SWT3 witness procedures that generate cryptographic evidence of control operation.
| CSF 2.0 Function | AI Focus Area | SWT3 Procedure | What It Witnesses |
|---|---|---|---|
| Govern (GV) | Secure | AI-AUDIT.1 | AI governance audit trail with tamper-evident anchors |
| Govern (GV) | Secure | AI-GOV.6 | Governance policy attestation and version tracking |
| Identify (ID) | Secure | AI-HW.1 | Hardware attestation: accelerator inventory and health |
| Identify (ID) | Secure | AI-SBOM.1 | AI system bill of materials with component hashing |
| Protect (PR) | Secure | AI-SEC.1, AI-SEC.2 | Security control enforcement and access boundary verification |
| Protect (PR) | Secure | AI-GRD.1, AI-GRD.2, AI-GRD.3 | Guardrail enforcement, content safety, PII redaction |
| Protect (PR) | Secure | AI-DATA.1 | Training data provenance and integrity verification |
| Detect (DE) | Defend | AI-MDL.3 | Model drift detection with threshold-based alerting |
| Detect (DE) | Defend | AI-INF.1 | Inference provenance capture for anomaly correlation |
| Detect (DE) | Thwart | AI-CYBER.1 | Adversarial input detection and classification |
| Respond (RS) | Defend | AI-INCIDENT.1 | Incident response evidence chain with anchor verification |
| Respond (RS) | Thwart | AI-REV.1 | Anchor revocation for compromised model responses |
| Recover (RC) | Defend | AI-MDL.1 | Model integrity verification for rollback validation |
Profile requires: AI systems must implement security controls proportionate to risk, including access controls, encryption, and monitoring.
SWT3 witness: Every security boundary crossing is witnessed with cryptographic anchors. Factor A = control count, Factor B = controls active, Factor C = enforcement mode. Each anchor proves the security posture at the exact moment of evaluation, not at the time of last audit.
Assessor Tip
Query the auditor portal for AI-SEC procedure anchors. Continuous pass rate above 95% demonstrates operational security, not just documented policy.
Profile requires: Organizations should identify and inventory AI-specific computing resources including accelerators, GPUs, and specialized hardware.
SWT3 witness: The K8s DaemonSet continuously attests accelerator inventory, silicon vendor, topology, and health status. Every node reports hourly. Cross-silicon support covers NVIDIA, AMD, Intel, Apple, and Qualcomm hardware.
Assessor Tip
Check the Infrastructure tab on the AI Witness dashboard. Node staleness indicators (fresh/stale/critical) show whether hardware attestation is continuous or point-in-time.
Profile requires: AI system behavior should be monitored for unexpected changes, performance degradation, or adversarial influence.
SWT3 witness: Factor A = drift threshold, Factor B = measured drift. FAIL verdict triggers automatically when drift exceeds threshold. Webhook events fire for SIEM integration, enabling real-time correlation with broader cybersecurity monitoring.
Assessor Tip
Look for AI-MDL.3 FAIL anchors in the ledger. Zero FAIL anchors means either no drift occurred or drift detection is not configured. Ask which.
Profile requires: Organizations must maintain incident response procedures that address AI-specific scenarios including model compromise, data poisoning, and adversarial attacks.
SWT3 witness: Incident response actions are witnessed as they happen. Each anchor captures the action taken, the responder identity (agent_id), and the affected model. The evidence chain connects detection through containment to recovery.
Assessor Tip
During incident response exercises, verify that AI-INCIDENT.1 anchors appear in the ledger within the expected response window. The timestamp proves response time.
| Examiner Question | Where to Look |
|---|---|
| Are AI systems inventoried? | AI-HW.1 anchors in Infrastructure tab: node count, silicon vendor, topology |
| Is AI model integrity verified? | AI-MDL.1 anchors: model hash verification at deployment |
| Are guardrails enforced? | AI-GRD.1/GRD.2/GRD.3: pass rate in procedure stats |
| Is drift monitored? | AI-MDL.3: threshold and measured values in Factor A/B |
| Are incidents documented? | AI-INCIDENT.1 anchors with response timeline |
| Is training data provenance tracked? | AI-DATA.1: provenance documentation status |
| Are AI governance policies attested? | AI-AUDIT.1 + AI-GOV.6: governance trail |
| Is adversarial AI addressed? | AI-CYBER.1: adversarial detection classification |
For full SDK documentation, see the SDK Docs. To create a free account and start generating witness anchors, sign up here.