Scope
This guide helps you apply NIST Cybersecurity Framework 2.0 controls to AI systems in your organization. It focuses on the emerging Cyber AI Profile structure, key terminology distinctions, and implementation considerations based on community feedback from over 1,400 comments during NIST's public consultation process.
Use this when you're:
- Scoping CSF 2.0 implementation for AI workloads
- Translating AI governance requirements into security controls
- Briefing leadership on AI-specific cybersecurity gaps
- Conducting risk assessments for AI system deployments
This guide does NOT cover AI model development methodology, data science practices, or ML operations tooling selection.
Key Concepts and Definitions
Agentic AI: AI systems that take autonomous actions based on goals rather than explicit instructions. These require heightened oversight because they operate with less direct human intervention than traditional AI tools.
Human-in-the-Loop (HITL): Control processes requiring human review or approval before AI system outputs are acted upon. HITL remains the standard for AI accountability in most enterprise contexts.
AI Bills of Materials (AIBOM): Documentation of AI system components, training data sources, dependencies, and supply chain elements. Consider this an SBOM equivalent for AI systems.
Shadow AI: Unauthorized or undocumented AI tools adopted by business units without security review. This creates visibility gaps similar to shadow IT but with potentially higher consequences due to data exposure and decision-making authority.
Cyber AI Profile: NIST's industry-agnostic framework that maps CSF 2.0 controls to AI-specific risks. It's designed to help you identify where standard cybersecurity controls need adaptation for AI workloads.
Requirements Breakdown
The Cyber AI Profile organizes controls around three focus areas. While NIST hasn't published the final structure, workshop feedback indicates these themes:
Focus Area 1: AI System Integrity and Supply Chain
Apply CSF 2.0 supply chain risk management controls (SR category) with AI-specific adaptations:
- Maintain AIBOMs for all production AI systems
- Implement cryptographic signing for model artifacts
- Verify training data provenance
- Document third-party AI service dependencies
Focus Area 2: AI-Driven Decision Accountability
Map CSF 2.0 governance controls (GV category) to AI decision processes:
- Define roles for AI system ownership (some organizations are creating Chief AI Officer positions; align your control structure with whoever holds accountability)
- Establish HITL checkpoints for high-consequence decisions
- Document decision logic and override procedures
- Create audit trails for AI system outputs that inform security decisions
Focus Area 3: AI-Specific Threat Management
Extend CSF 2.0 identify and protect functions (ID, PR categories):
- Assess adversarial machine learning risks (model poisoning, evasion attacks)
- Control access to training environments
- Monitor for data exfiltration through model queries
- Test AI system behavior under adversarial inputs
Implementation Guidance
Start with Visibility
Before mapping controls, inventory what you have:
- Catalog AI tools in use (including shadow AI)
- Classify by consequence level (what decisions does this AI inform or make?)
- Map data flows to and from AI systems
- Identify which systems are agentic vs. tool-like
Adapt Your Testing Approach
Traditional vulnerability scanning doesn't catch AI-specific risks. You'll need:
- Adversarial testing: Can malicious inputs manipulate model behavior?
- Drift monitoring: Is model performance degrading over time?
- Bias assessment: Are outputs consistently skewed in ways that create risk?
- Explainability checks: Can you trace how the system reached a decision?
NIST's Dioptra project offers testbed capabilities for adversarial machine learning assessment if you need a starting point.
Integrate with Existing CSF Implementation
Don't create a parallel AI security program. Map AI-specific controls into your existing CSF 2.0 implementation:
- If you're tracking PR.DS (Data Security) controls, add AIBOM requirements there
- If you have GV.OC (Organizational Context) documentation, add AI governance roles
- If you run tabletop exercises under RS.MA (Response Management), include AI system compromise scenarios
Document HITL Boundaries
For each AI system, define:
- Which outputs require human review before action
- Who's authorized to override AI recommendations
- How quickly human review must occur (some systems can't wait)
- What happens if the human reviewer is unavailable
These aren't technical controls, but they determine where your technical controls need to enforce gates.
Common Pitfalls
Over-specifying controls too early: Technology changes quickly. Avoid controls that lock you into specific tools or techniques. Focus on outcomes (can you detect model tampering?) rather than methods.
Treating all AI systems identically: A chatbot that answers HR questions needs different controls than an AI system making credit decisions. Consequence-based classification matters more than technical architecture.
Assuming transparency solves accountability: You can document how an AI system works and still struggle with accountability when something goes wrong. Define who's responsible for outcomes before you deploy.
Ignoring OT contexts: If you're implementing AI in operational technology environments, control requirements differ significantly. The Cyber AI Profile is intended to address these use cases, but you'll need to adapt timing, availability, and safety requirements.
Skipping the taxonomy work: Inconsistent terminology between security, data science, and business teams creates gaps. Establish common definitions before you implement controls. The Cyber AI Profile aims to provide industry-agnostic taxonomy, but you'll still need to translate it for your organization.
Quick Reference Table
| CSF 2.0 Function | AI-Specific Adaptation | Key Control Examples |
|---|---|---|
| Govern (GV) | Add AI accountability roles and decision authority | Define Chief AI Officer scope; establish multidisciplinary AI governance body; document HITL requirements |
| Identify (ID) | Inventory AI systems and classify by autonomy level | Catalog agentic AI separately; map AI data flows; assess adversarial ML threat scenarios |
| Protect (PR) | Secure training environments and model artifacts | Implement AIBOM; cryptographically sign models; control training data access |
| Detect (DE) | Monitor for AI-specific anomalies | Track model drift; detect shadow AI adoption; alert on unusual query patterns |
| Respond (RS) | Plan for AI system compromise scenarios | Define model rollback procedures; establish override protocols; test incident response with AI failure modes |
| Recover (RC) | Restore AI system integrity after incidents | Verify model provenance before restoration; retrain from clean data; validate post-incident behavior |
Version note: This guide reflects the Preliminary Draft stage of NIST's Cyber AI Profile. NIST plans to publish an Initial Public Draft following analysis of workshop feedback. Check the Cyber AI Profile project page for updates and subscribe to the community of interest for notification of working sessions.
