NIST SP 800-171 Rev 2

AI inference APIs that process CUI must enforce access controls for every API call. Requirement 3.1.1 covers "processes acting on behalf of users" — directly addressing AI agents, but requiring robust request tracing to map agent actions back to originating users. The flow control requirement (3.1.3) is critical: CUI used as training data must not leak through model outputs.

The 22 access control requirements are easier to satisfy with cloud AI platforms. API gateways, IAM integration, managed VPN endpoints, and mobile device management are built into Azure Government and AWS GovCloud. Local GPU servers requiring custom access control infrastructure create a significant implementation and documentation burden for CMMC assessment.

Personnel working with CUI-trained AI models need awareness training on AI-specific risks. Prompt injection attacks that could exfiltrate CUI through model outputs, training data leakage, and model theft are threats that traditional security awareness training doesn't cover. Insider threat training (3.2.3) must address AI-specific risks like data scientists exfiltrating model weights or training datasets.

Organizations must document this AI-specific training to pass CMMC assessment. The 3 requirements seem simple, but satisfying them for an AI workforce requires developing custom training materials, tracking completion, and refreshing content as AI threats evolve. Cloud AI providers offer managed training programs that organizations can reference.

3.3.2 unique user traceability is the hardest requirement for AI systems. When an AI agent makes API calls on behalf of a user, the audit log must trace the action back to the originating user through potentially multiple layers of abstraction. AI systems generate enormous volumes of audit events: every inference request, model update, and training run. This volume can overwhelm traditional SIEM tools.

Cloud AI services provide pre-built audit logging with configurable retention. Azure Monitor, AWS CloudTrail in GovCloud, and Google Cloud Audit Logs capture AI API calls automatically, satisfying 3.3.x requirements through service inheritance. Local deployments require custom audit pipelines with defined event types, retention policies, and correlation capabilities — a major implementation effort.

AI model configurations (weights, hyperparameters, training pipeline configs) must be tracked as baseline configurations under 3.4.1. Every model update is a configuration change requiring security impact analysis (3.4.4). The principle of least functionality (3.4.6) is challenging for AI systems that may need broad data access for training. Software whitelisting (3.4.8) must extend to ML frameworks, libraries, and model artifacts — an area where many organizations lack established controls.

Cloud AI platforms maintain managed model registries and CI/CD pipelines that satisfy CM requirements through automation. Azure ML, AWS SageMaker, and Google Vertex AI provide built-in versioning, change tracking, and approval workflows. Local deployments require custom tooling to achieve equivalent configuration management capabilities.

Requirement 3.5.3 (multifactor authentication) is particularly burdensome for AI systems. ML training pipelines and inference services that run autonomously cannot use human MFA. Service-to-service authentication with API keys and workload identity (not human passwords) is the practical solution, but CMMC assessors may question whether API keys satisfy the MFA intent. 3.5.1 identification of "processes acting on behalf of users" directly addresses AI agents but requires robust request tracing.

Cloud AI platforms integrate with enterprise IdP (Entra ID, IAM) for MFA and API key management. GovCloud environments provide FedRAMP-authorized identity services. Making these requirements easier to satisfy than local deployments where organizations must implement and document their own MFA infrastructure for AI model management interfaces.

Incident handling for CUI-processing AI systems must cover AI-specific incidents. Model extraction attacks that could leak CUI memorized during training, prompt injection that bypasses content filters, and training data poisoning are all incidents that 3.6.1 requires the capability to detect, contain, and eradicate. 3.6.3 testing must include AI red-team exercises.

Organizations without dedicated AI security expertise will struggle to demonstrate adequate incident response capabilities during CMMC assessment. The 3 requirements are simple in statement but complex in implementation for AI systems. Cloud AI providers offer built-in abuse detection and content filtering that can be incorporated into IR procedures.

AI model retraining and fine-tuning are maintenance activities under 3.7.1. GPUs used for CUI model training that are sent for repair must be sanitized (3.7.3) — a non-trivial task given that VRAM may contain residual training data. Nonlocal maintenance (3.7.5) applies to remote model management interfaces, requiring MFA.

The continuous nature of AI model maintenance conflicts with the discrete, scheduled maintenance model assumed by these requirements. Cloud AI providers handle maintenance through managed CI/CD pipelines with built-in security gates, satisfying these requirements through service inheritance. Local deployments must build custom maintenance authorization workflows.

CUI training datasets are media that must be physically controlled (3.8.1), access-limited (3.8.2), encrypted during transport (3.8.6), and sanitized before disposal (3.8.3). Model weights trained on CUI may themselves encode sensitive information and should be treated as CUI media. Removable media controls (3.8.7–3.8.8) are critical for preventing exfiltration of CUI training data via USB drives or portable storage.

Cloud AI platforms provide encrypted storage, managed data lifecycle policies, and cryptographic erase capabilities. Azure Government and AWS GovCloud offer FIPS-validated encryption at rest and automated data deletion. These satisfy 3.8.x requirements through service inheritance, while local deployments must manually track and sanitize training data media — a labor-intensive, error-prone process.

Data scientists and ML engineers with access to CUI training data must be screened (3.9.1) and have appropriate clearances (3.9.2). The need-to-know principle (3.9.2) is challenging in AI contexts where a single training dataset may aggregate CUI from multiple projects. Personnel who can access model weights that encode CUI patterns may need the same clearances as personnel who access the raw CUI.

Organizations must carefully scope AI team access to minimize clearance requirements. This is easier with cloud AI platforms that provide granular, role-based access to training data and model artifacts. Local deployments with broad filesystem access make it harder to enforce need-to-know boundaries.

GPU clusters and AI training infrastructure require physical protection under 3.10.1–3.10.2. Organizations hosting local AI must implement facility access controls, monitoring, and visitor escort procedures for their AI infrastructure. This is a significant capital and operational expense.

Cloud AI providers handle physical protection at their data centers, and customers inherit these controls through FedRAMP/SOC 2 documentation. This is a decisive advantage for cloud-hosted AI: the physical security of the data center is already audited and documented, eliminating a major compliance scope area. Local deployments must document their own facility security, access logs, and visitor procedures — all of which will be scrutinized during CMMC assessment.

3.11.1 risk assessments for CUI-processing AI must evaluate AI-specific risks. Model inversion attacks that could reconstruct CUI from model outputs, membership inference that reveals whether specific records were in the training data, and training data poisoning are all risks that traditional risk frameworks don't address. 3.11.2 vulnerability scanning must include AI model vulnerability testing — an emerging discipline with few established tools.

Cloud AI providers invest in AI red-teaming and vulnerability research that most organizations cannot replicate locally. Microsoft, Amazon, and Google have dedicated AI security teams continuously testing their models. Organizations using managed cloud AI platforms benefit from this research without bearing the cost themselves.

3.12.4 system security plans for AI systems must document the model architecture, training data sources, inference pipeline, and how each of the 110 requirements is satisfied for the AI components. 3.12.1 assessments must test AI-specific controls (content filtering, access controls on inference APIs, training data protection). 3.12.3 continuous monitoring for AI includes model drift detection and adversarial input monitoring.

This is the family where CMMC assessors will focus on AI-specific compliance evidence. The system security plan is the primary document assessors review. If it doesn't adequately describe how AI-specific risks are controlled, the assessment will fail. Cloud AI platforms provide pre-written control inheritance documentation that simplifies SSP creation. See CMMC v2.

This family is the most critical for AI systems processing CUI. 3.13.8 requires encryption of CUI in transit — including API calls to AI inference endpoints. 3.13.16 requires encryption of CUI at rest — including training data and model weights that encode CUI. 3.13.11 requires FIPS-validated cryptography, a constraint that eliminates many open-source ML encryption libraries.

3.13.4 (prevent unauthorized information transfer via shared resources) is directly relevant to AI. Model outputs could leak CUI from the training data. This requirement demands output monitoring or content filtering — capabilities that cloud AI platforms (Azure OpenAI content filtering, AWS Bedrock guardrails) provide natively. Local deployments must build custom output monitoring.

Cloud AI platforms in GovCloud provide FIPS-validated encryption, TLS endpoints, and key management services that satisfy these requirements by inheritance. Local deployments must implement FIPS-validated crypto modules, configure TLS for all inference endpoints, and stand up key management infrastructure — a major implementation burden.

3.14.1 flaw remediation for AI models means identifying and correcting model vulnerabilities through retraining or patching. You can't patch a model the way you patch software — you must retrain or fine-tune. 3.14.6 monitoring must detect AI-specific attack patterns: model extraction (high-volume similar queries), prompt injection attempts, and adversarial inputs. 3.14.7 unauthorized use detection must catch AI model misuse (e.g., using a CUI-trained model for non-authorized purposes).

Cloud AI providers offer built-in abuse detection and content filtering that addresses several of these requirements. Rate limiting, query pattern analysis, and content moderation are built into managed AI platforms. Local deployments require custom monitoring solutions — another implementation burden that favors managed cloud services over local AI.