NIST SP 800-53 Rev 5

AI systems break the user-vs-process boundary. AC-2 manages accounts for "users, processes acting on behalf of users, and devices." Autonomous AI agents that make API calls on behalf of users blur this line — the agent is a process, but it acts with the user's authority. Who gets the account? Who is accountable?

Information flow control (AC-4) is the CUI leakage vector. AI models trained on CUI can regurgitate it through inference. Traditional flow control operates at the network boundary; AI model output flows through an API response. Cloud AI providers offer content filtering and DLP integration that satisfies AC-4 more easily than local deployments where organizations must build custom output monitoring.

Least privilege (AC-6) is antithetical to broad-data-access AI. AI training pipelines need access to large datasets, often spanning multiple security domains. Granting a training pipeline "least privilege" while still giving it enough data to train effectively is an unsolved tension. Centralized cloud AI platforms handle this through scoped data access policies and managed training environments.

AI introduces entirely new training requirements that didn't exist when AT was written. Prompt injection awareness, model output validation, data leakage through inference, and adversarial ML techniques are not covered by traditional security awareness training. Organizations deploying AI must develop role-based training (AT-3) for data scientists, ML engineers, and AI system administrators — roles that have no established training curriculum.

AT-4 documentation becomes a compliance trap. Organizations must prove their AI workforce has been trained on these new threat vectors. Without documented AI-specific training, assessors will flag the AT family as deficient. Cloud AI providers offer managed training programs and certification paths that organizations can reference, while local deployments require self-developed training materials.

AI systems generate orders of magnitude more audit events than traditional systems. Every inference request, model update, training run, and data access is an auditable event. Traditional SIEM systems may not parse AI-specific event types (model drift alerts, prompt injection attempts, token-level access logs). AU-6 anomaly analysis requires understanding what "normal" AI behavior looks like — a fundamentally different problem from detecting traditional system anomalies.

Cloud AI providers offer built-in audit logging that satisfies AU controls through inheritance. Azure Monitor, AWS CloudTrail, and Google Cloud Audit Logs capture AI API calls automatically. Locally hosted models require organizations to build custom audit pipelines, define event types, and implement retention policies from scratch — a significant implementation burden that favors managed platforms.

CA is where AI systems face their highest compliance barrier. Continuous monitoring (CA-7) for AI requires monitoring model performance, data drift, and adversarial robustness — not just patch levels and configuration drift. Security assessments (CA-2) must now include AI-specific testing: adversarial inputs, bias testing, model extraction attacks, and prompt injection resistance.

FedRAMP leverages CA controls to gate cloud AI. A cloud provider with a FedRAMP ATO has already passed CA-2 assessment and implemented CA-7 continuous monitoring. Customers deploying AI on that platform inherit these controls. Self-authorizing a local AI deployment requires a full CA-2 assessment from scratch — a 6-18 month process costing $250K-$2M. This is why virtually all federal AI deployments run on FedRAMP-authorized cloud platforms. See FedRAMP.

The ATO process itself favors centralized systems. An ATO covers a defined system boundary. AI systems that dynamically scale, federate learning across organizations, or use external model APIs have fuzzy boundaries that are difficult to scope for an ATO. Managed cloud AI services have clear, pre-documented boundaries.

AI models are not static configurations — they change continuously through training and fine-tuning. CM-2 baseline configuration assumes a fixed, documented state. AI model weights change during operation; fine-tuning updates change model behavior without changing the software stack. Model versioning, training data provenance, and fine-tuning audit trails must all be tracked as configuration items.

CM-8 inventory becomes complex with dynamic AI infrastructure. AI systems that auto-scale inference endpoints have constantly changing component inventories. Cloud AI services handle this through automated model registries and deployment tracking. Local deployments require custom inventory tooling that can track model versions, GPU allocations, and training pipeline states.

Backing up an AI model means preserving both weights and the training data pipeline. If a model is corrupted or compromised, restoring from backup is insufficient — the organization must also verify the model hasn't been poisoned. CP-9 backups should include model checksums, training data hashes, and version provenance to enable integrity verification on restore.

Cloud AI providers offer multi-region model replication and automated failover. Azure OpenAI, AWS Bedrock, and Google Vertex AI provide built-in disaster recovery across availability zones. This satisfies CP controls through service inheritance that local GPU deployments cannot easily match without investing in redundant infrastructure.

AI agents need service-to-service authentication, not human credentials. IA-2 was written for human users. AI systems need API keys, OAuth tokens, or workload identity federation. IA-5 authenticator management for AI must handle automated credential rotation for model training and inference pipelines — a different problem from managing human passwords.

Cloud AI platforms integrate with enterprise identity providers (Entra ID, IAM Identity Center) to provide managed authentication. This satisfies IA-2 and IA-5 through inheritance. Local AI deployments require custom identity infrastructure — building an OIDC provider, managing token lifecycles, and implementing MFA for model management interfaces. The managed platform advantage is substantial.

AI introduces entirely new incident categories with no established playbooks. Model extraction attacks, data poisoning, prompt injection, adversarial evasion, and model inversion are AI-specific incidents that traditional IR procedures don't address. IR-4 incident handling requires detection capabilities (model behavior monitoring, input validation) and containment strategies (model rollback, inference endpoint quarantine) that most IR teams don't have.

Cloud AI providers increasingly offer built-in abuse detection and content filtering that feeds into incident response workflows. Azure OpenAI's content filtering, AWS Bedrock's guardrails, and Google's Perspective API provide automated detection of prompt injection and abusive inputs. This makes managed platforms easier to defend than local deployments where organizations must build AI-specific IR capabilities from scratch.

AI model maintenance (retraining, fine-tuning) is continuous, not scheduled. MA-2 assumes discrete, authorizable maintenance windows. AI systems update models through CI/CD pipelines that run continuously. Per-update authorization is impractical, but the MA control requires it. Organizations must either implement automated maintenance authorization gates or document a compensating control.

Cloud AI services handle model maintenance through automated CI/CD pipelines with built-in security gates. The provider's maintenance processes are already authorized under their FedRAMP package. Local deployments must build custom maintenance authorization workflows, creating another implementation burden that favors managed platforms.

AI training datasets are massive media assets — terabytes on physical or virtual storage. MP-6 sanitization applies when storage containing training data (which may include CUI or PII) is repurposed. Cryptographic erase requires key management for the encryption layer. GPU VRAM can retain residual training data, creating an overlooked sanitization gap.

Cloud AI providers manage media protection at scale with automated data lifecycle policies. Azure, AWS, and Google Cloud provide automated data deletion, cryptographic erase, and lifecycle management. Local deployments must manually track and sanitize training data media — a labor-intensive process that is easy to get wrong and hard to audit.

AI training infrastructure (GPU clusters, TPUs) requires significant physical security and environmental controls. Power density, cooling, and physical access to expensive hardware all fall under PE. Organizations hosting local AI must implement these controls at their own facilities — a major capital expense.

Cloud AI providers inherit PE controls through their FedRAMP/SSAE 16 audits. Customers can inherit these controls rather than implementing them. The physical security of the data center is already audited and documented in the provider's SSP. This is a significant cost advantage for cloud-hosted AI over on-premises GPU infrastructure, where the organization bears the full physical security burden.

PL-2 system security plans for AI must document model architecture, training data sources, inference pipeline, and human-in-the-loop processes. PL-8 security architecture must address the AI-specific attack surface (model endpoints, training pipelines, data preprocessing). The documentation burden is significant — organizations must describe how their AI system works in terms that security assessors can evaluate.

Cloud AI services provide pre-documented architecture diagrams and security inheritance statements. This simplifies PL-2 and PL-8 compliance dramatically. A customer deploying Azure OpenAI can reference Microsoft's SSP for the platform-level controls and document only their application-specific controls. A local deployment must write the entire SSP from scratch.

Organizations deploying AI at scale need an AI governance program integrated with their existing security program. PM-9 risk management strategy must address AI-specific risks: model bias, adversarial attacks, data poisoning, and hallucination. Many organizations lack the senior-level AI security expertise needed for PM-2 leadership roles.

The centralized program management approach favors organizations with mature governance structures. Typically these are organizations using managed cloud platforms with built-in governance tooling (Azure Policy, AWS Control Tower, Google Cloud Security Command Center). Smaller organizations or those with distributed AI development teams struggle to implement PM controls effectively.

AI creates new insider threat vectors that PS controls weren't designed for. Data scientists with access to training data, ML engineers who can modify model weights, and prompt engineers who can craft adversarial inputs all have capabilities that traditional personnel security doesn't address. PS-3 screening must consider AI-specific risks (e.g., model theft by departing employees).

PS-4 termination must revoke access to model registries, training pipelines, and inference endpoints — not just traditional system accounts. The collaborative, shared nature of AI development teams conflicts with the individual accountability model underlying PS controls. Cloud platforms provide centralized access management that makes termination revocation more reliable than the scattered access paths typical of local AI deployments.

AI training data frequently contains PII scraped from public sources or repurposed from operational systems. PT-3 privacy impact assessments must address the risk that AI models memorize and regurgitate training data, creating new PII disclosure vectors. PT-6 consent becomes nearly impossible when training data is aggregated from thousands of sources — who consents to their data being used to train a model?

Cloud AI providers increasingly offer data processing agreements and privacy controls that help satisfy PT requirements. Azure OpenAI's "your data is not used for training" policy, AWS Bedrock's data isolation, and Google's data residency controls provide contractual PII protections. Local AI deployments must build their own privacy controls and cannot offer the same level of contractual assurance.

AI risk assessment (RA-3) must address threats that traditional risk frameworks don't cover. Adversarial ML attacks, model inversion, membership inference, and training data extraction are AI-specific risks with no established scoring methodology. RA-5 vulnerability scanning must extend to model vulnerabilities (prompt injection, jailbreak susceptibility) — an emerging field with no standard scanners.

Cloud AI providers invest heavily in AI red-teaming and vulnerability research. Microsoft, Amazon, and Google have dedicated AI security teams that continuously test their models. Organizations using local deployments cannot match this investment. The managed platform advantage is not just convenience — it's a fundamentally different level of risk coverage.

SA-9 external system services is the control that governs using cloud AI providers. The provider must implement equivalent security controls, verified through FedRAMP or equivalent assessment. SA-11 developer testing is critical for AI: model developers must test for bias, robustness, and adversarial resilience — requirements that have no established testing standards.

The supply chain risk for AI models is largely unaddressed. Pre-trained models from HuggingFace, open-weight models from Meta, and fine-tuned models from third parties all introduce supply chain risk. There is no "FedRAMP for AI models" — the SA family doesn't yet address the unique risks of consuming externally-developed AI models. This is a gap that NIST is actively working on through the AI RMF and related efforts.

AI inference traffic must be protected under SC-8, and model weights at rest under SC-28. SC-7 boundary protection must account for AI APIs that may exfiltrate training data through model responses. Cryptographic key management (SC-12) for AI must protect model encryption keys and training data encryption keys — a complex key hierarchy that most organizations don't have established.

Cloud AI providers offer TLS-encrypted endpoints, encryption at rest, and managed key vaults. Azure Key Vault, AWS KMS, and Google Cloud KMS satisfy SC-12 through inheritance. Local deployments must implement these from scratch — standing up a key management service, configuring encryption for training data stores, and managing TLS certificates for inference endpoints. The managed platform advantage is substantial for the SC family.

SI-7 integrity verification for AI models is an unsolved problem. There is no standard way to verify that a model's behavior hasn't been subtly altered (model poisoning). Traditional file integrity monitoring checks hash values — but a model's hash can be correct while its behavior has drifted due to adversarial fine-tuning. SI-4 monitoring must detect AI-specific attacks like model extraction (many similar queries from the same source).

SI-2 flaw remediation for AI models requires retraining or fine-tuning, not patching. You can't "patch" a model vulnerability the way you patch a software vulnerability — you must retrain with corrected data or apply a fine-tuning delta. Cloud AI providers offer model integrity verification, content filtering, and abuse detection as managed services. Local deployments must build and maintain these capabilities independently — a significant ongoing cost.

The AI supply chain is the least-addressed risk in 800-53. Organizations consuming pre-trained models from HuggingFace, open-weight models from Meta/Llama, or fine-tuned models from third-party providers face supply chain risks with no established controls. A poisoned model from a third-party provider can introduce backdoors that are extremely difficult to detect. SR-2 supply chain risk management plans must address the AI model supply chain specifically.

Cloud AI providers reduce supply chain risk by being the supplier. When you use Azure OpenAI, Microsoft is the sole supplier — and Microsoft's supply chain is already assessed under FedRAMP. Organizations using open-source models from multiple sources have a much larger and harder-to-assess supply chain. This further favors managed cloud AI platforms over distributed, open-source AI deployments.