NIST SP 800-239 reframes AI infrastructure security around the data center rather than a single model or application. The initial public draft, AI Data Center Security Analysis: A High-Performance Computing (HPC) Driven Approach, compares AI environments with traditional HPC across architecture, hardware, software stacks, workflows, and storage.
That perspective is useful because an AI data center concentrates expensive accelerators, high-speed fabrics, large datasets, model artifacts, orchestration systems, and multi-tenant workloads. A threat model built only around API access misses the infrastructure that trains, serves, and moves those models.
Start with assets and trust boundaries
The NIST draft covers purpose-built infrastructure for training, inference, and AI applications. Translate that scope into an environment-specific asset map: accelerator nodes, CPU hosts, storage tiers, schedulers, container platforms, model registries, data pipelines, management controllers, firmware services, and network fabrics.
Draw trust boundaries where identity, ownership, or control changes. Important boundaries often include user-to-scheduler, workload-to-workload, tenant-to-tenant, compute-to-storage, data-plane-to-management-plane, and on-premises-to-cloud connections. Include vendor remote support and out-of-band management; these paths can bypass application-layer controls.
Model the full AI lifecycle
Training data, checkpoints, weights, prompts, retrieval indexes, evaluation results, and deployment packages have different confidentiality and integrity requirements. Track how each asset is created, transformed, approved, distributed, and retired. A model registry should not be treated as ordinary object storage if production systems automatically trust what it serves.
For each lifecycle step, ask who can submit work, select data, change code, alter dependencies, publish a model, and promote it to inference. Then identify how those actions are authenticated and logged. Separation of duties is especially important when a single pipeline can both train and deploy.
Threats unique to concentrated compute
AI clusters inherit familiar risks—credential theft, vulnerable services, insecure supply chains, and lateral movement—but scale changes the consequences. Compromised scheduling credentials can expose many nodes. Weak isolation can leak data between workloads. Tampered firmware or drivers can undermine controls below the operating system. Theft of model weights may represent loss of both intellectual property and embedded sensitive information.
Availability also has a direct financial dimension. Resource-exhaustion attacks, cryptomining, malicious jobs, or faulty workloads can consume scarce accelerators and disrupt priority services. Quotas, admission controls, workload identity, and anomaly detection should therefore be part of the security design, not only capacity management.
Control priorities for architecture review
- Identity: use short-lived workload credentials, strong administrator authentication, and separate human from service identities.
- Isolation: segment management, storage, training, and inference traffic; validate tenant boundaries at compute and orchestration layers.
- Integrity: sign images and model artifacts, verify provenance, and control who can promote assets into production.
- Data protection: classify datasets and checkpoints, encrypt transfers and storage, and limit bulk export paths.
- Observability: correlate scheduler, container, identity, storage, network, and model-registry events.
- Recovery: maintain tested restoration procedures for orchestration state, registries, keys, and critical datasets.
Turn the threat model into decisions
A useful threat model does not end with a diagram. For every credible scenario, record the affected asset, attacker prerequisites, existing controls, detection signal, response owner, and residual risk. Use the results to drive design choices such as whether training and inference should share a control plane, whether research workloads can reach production registries, and how vendor access is brokered.
Test the model through exercises. Simulate a stolen scheduler token, a malicious container image, unauthorized model promotion, or a compromised management controller. The exercise should reveal whether teams can contain the event without shutting down the entire cluster and whether forensic evidence survives rapid workload churn.
Include the physical and supply-chain layers
Accelerators, network adapters, baseboard management controllers, firmware, drivers, and vendor tooling form a dependency chain below the AI software stack. Record who supplies each component, how updates are authenticated, what telemetry is available, and how a vulnerable node can be quarantined. Procurement requirements should include security-update commitments and disclosure processes, not only performance targets.
Physical operations also affect cyber controls. Technicians may access racks, removable media, console ports, or replacement hardware outside the normal identity plane. Align facilities access, asset custody, hardware disposal, and remote-hands procedures with the data classification of the cluster. A failed accelerator returned to a vendor may still contain local data or configuration.
For cloud or colocation deployments, state which controls belong to the provider and which remain with the customer. Ask for evidence around tenant isolation, privileged access, firmware maintenance, incident notification, and destruction of replaced media. Shared responsibility should be expressed as named tasks, not a generic contract paragraph.
Use SP 800-239 as a baseline, not a checklist
The draft’s HPC-driven framing provides a common vocabulary for security, platform, data, and facilities teams. Organizations should adapt it to their tenancy model, deployment pattern, regulatory obligations, and tolerance for shared infrastructure.
The immediate deliverable can be modest: one asset inventory, one trust-boundary diagram, and a ranked list of scenarios with owners. Revisit it when new accelerators, storage systems, orchestration layers, model services, or external data sources enter the environment. AI infrastructure changes quickly; the threat model must be maintained as an operational artifact rather than archived as architecture documentation.
