AI Data Centre Security Guide: Protecting Compute, Weights and Facilities at Frontier Scale

An AI data centre concentrates the most valuable digital asset many organisations will ever own, trained model weights, together with tens of thousands of accelerators, their firmware and management planes, in facilities that were designed for availability rather than for resisting a nation state. Ordinary data centre controls still apply, but frontier-scale training and inference change the threat model: the asset is small enough to steal in one transfer yet worth years of investment, the hardware supply chain is narrow and targeted, and every node holds credentials and cached copies. This guide covers what is different about AI facilities, the emerging security levels and standards (RAND's work, the draft SL5 Standard and the US push for high-security AI data centre standards), and a layered programme from site to accelerator to operations. It is written for security architects, data centre and infrastructure leads, and risk owners at AI labs, cloud and colocation providers, and enterprises building private AI capacity. Status of standards and drafts was checked on 11 November 2026.

Key takeaways

• Protect the weights, not just the building. RAND's Securing AI Model Weights (2024) recommends centralising weight copies in a few access-controlled, monitored systems, cutting the number of people with access, and using confidential computing; the facility design should serve those goals.
• Pick a security level first. In NHI Mgmt Group's view, most enterprises need RAND SL3 controls (which start to cover insiders); SL4 and SL5 aim at state-level attackers and require facility, personnel and supply chain measures most data centres do not have today.
• SL5 is a draft, not a certification. The SL5 Standard for AI Security is a v0.1 preprint (May 2026) that borrows from ICD 705 facilities, TEMPEST and a NIST SP 800-53 overlay; use it as a design reference, not as a compliance target.
• The management plane is the soft centre. BMCs, accelerator firmware, fabric managers and cluster schedulers can reach every node; one exposed BMC flaw such as CVE-2024-54085 (in CISA KEV) is a pre-boot foothold below every other control.
• Bandwidth is a security control. Weights are large, so hardware-enforced caps on egress from weight enclaves, with bigger transfers only by approved physical media, turn a fast theft into a slow, visible one.

What makes an AI data centre different

A conventional enterprise data centre protects many systems of moderate value. An AI facility protects a few assets of very high value and runs them on a hardware stack with more privileged components per rack. The differences that matter for security:

Security levels and the emerging standards

RAND's Securing AI Model Weights (RR-A2849-1, May 2024) identified 38 attack vectors and defined five security levels, SL1 to SL5, each matched to an attacker class from amateurs to top-priority state operations. The levels are covered in depth in the Securing AI Model Weights guide; this section covers the documents that translate them into facility and infrastructure design.

None of these is a binding requirement for private operators as of November 2026. Treat the SL5 Standard and RAND's facility design as engineering references, and expect a US government standard to follow the Action Plan's direction.

Site and physical security

Start from your normal data centre baseline (zoning, access control, visitor management, environmental protection); see the Data Centre Security Guide and the ANSI/TIA-942 and EN 50600 Guide. What AI facilities add depends on the target level:

• A weight enclave inside the facility: isolate the racks that hold full weights in their own zone with separate access authorisation. The SL5 Standard models this on ICD 705: fully enclosed Red Zones with no windows, acoustic attenuation, mantraps at every entry and exit, and intrusion alarm response within 5 minutes for open storage or 15 minutes for closed storage.
• Two-person integrity: require two authorised people for entry to the enclave and for privileged hardware work (NIST SP 800-53 PE-2(3) as cited by the SL5 Standard). For SL3 sites, dual authorisation for weight export and key changes is the practical equivalent.
• Emanations and wireless: at SL5 the draft requires TEMPEST countermeasures (NSTISSAM TEMPEST/1-92), shielded racks meeting NSA 94-106 for weight enclave systems, and no wireless or collaborative devices in Red Zones. Below SL5, ban personal devices in enclave halls and monitor for rogue wireless.
• Hardware additions: lock unused ports, seal chassis with tamper-evident seals that are checked on a schedule, and log every hardware change against a ticket. ATT&CK T1200 Hardware Additions describes the attacker side.
• Shipping and receiving: run receiving inside the controlled perimeter, hold new accelerators in quarantine until inspected, and track high-value parts by serial number from dock to rack.

Compute, firmware and the management plane

Accelerator nodes have more privileged firmware than ordinary servers: system firmware, BMC, accelerator firmware, network adapters and switches. An attacker in any of them sits below the operating system and below most monitoring.

• BMCs: CISA and NSA's 2023 joint guidance on hardening baseboard management controllers names hardened credentials, firmware updates and network segmentation as the areas most often overlooked. The AMI MegaRAC authentication bypass CVE-2024-54085, added to CISA KEV on 25 June 2025, shows why BMC interfaces must never be reachable from production or user networks. See the Server BMC Security guide.
• Signed firmware and measured boot: accept only signed firmware on accelerators and hosts, record boot measurements, and use remote attestation before a node joins the cluster. The SL5 Standard maps this to SP 800-53 SI-7 enhancements and IA-3; it also asks that accelerators reject unsigned code during acceptance testing. ATT&CK T1542.001 System Firmware is the matching technique. See the Firmware and Boot Security Guide and the Hardware Root of Trust Guide.
• Confidential computing on accelerators: NVIDIA documents three deployment modes, confidential bare metal (the infrastructure owner sits outside the trust boundary, but the tenant's host software and administrators stay trusted), confidential VMs and confidential containers, each with attestation before secrets are released. The SL5 Standard notes gaps in current commercial accelerators, including TEEs that depend on the CPU and threat models that exclude physical attacks. See the Confidential AI and GPU Enclaves Guide.
• Cluster control planes: schedulers and orchestration (Slurm, Kubernetes, Ray) can run code on every node. Put them behind strong authentication and their own network segment. See the Ray and AI Compute Cluster Security Guide and, for shared clusters, the GPU and AI Cluster Multi Tenancy Security guide.

Network architecture and egress control

Separate at least four networks: the accelerator fabric, the storage network, the management network (BMCs, switches, OT) and the front-end network that serves users or APIs. Only the front end should touch the internet, and the management network should be reachable only from hardened jump hosts. For the switching fabric itself, see Data Centre Network Fabric Security.

At the top levels the designs become stricter:

• Air-gapped weight enclaves: the SL5 Standard calls for an air-gapped SL5 network with no external connections, weight enclaves confined to one facility, and two inline encryptors from different suppliers, validated to FIPS 140-3 Level 3, on any inter-facility link.
• Unidirectional flows: RAND's 2026 inference data centre design uses unidirectional data diodes and formally verified cross-realm protocols so that requests can enter and answers leave without a general-purpose return path.
• Egress rate caps: the SL5 draft requires hardware-enforced rate limits on outbound flows from weight enclaves, with larger transfers only by encrypted physical media. The logic holds at any level: if the largest legitimate output is far smaller than the model, a low cap makes bulk exfiltration slow and noisy.
• Inference interfaces: RAND recommends hardening model-access interfaces against weight extraction; rate-limit and monitor API use per credential (MITRE ATLAS AML.T0024 Exfiltration via AI Inference API).

Supply chain, personnel and operations

See the Hardware Trojans and Chip Supply Chain Guide, the NIST SP 800-161 Guide and the Insider Threat Programme Guide.

Where identity fits

Most of the access paths into an AI facility are machine identities: training jobs that write checkpoints, serving identities that load weights, scheduler service accounts, BMC management credentials, firmware update services and storage keys. Give each pipeline stage its own workload identity with access to one model path, prefer short-lived federated credentials over static keys, and remove shared cluster-admin credentials, which turn one compromised node into access to every node caching weights. See the AI Infrastructure Workload Identity Guide.

Implementation: a phased programme

1. Set the target level: decide with leadership which RAND security level each model tier needs, and record the decision with the attacker class it implies.
2. Map assets and paths: inventory every location holding weights or checkpoints, every identity that can read them, and every management interface (BMC, switch, scheduler, OT) with its network reachability.
3. Close the management plane: move BMCs and fabric managers to an isolated network, patch KEV-listed firmware first, and enforce signed firmware and attestation for new nodes.
4. Build the weight enclave: consolidate copies, restrict the enclave physically and logically, add dual authorisation for export and key operations, and apply egress caps. Pilot on one cluster and confirm training throughput before widening.
5. Harden supply chain and people: quarantine and inspect incoming hardware, introduce screening and a named custodian group, and extend the insider threat programme to facility staff.
6. Test: commission an external red team that covers insider and physical vectors, as RAND recommends, and rehearse a weight-theft incident.
7. Roll back safely: every new control (rate caps, attestation gates) should have an approved, logged break-glass path so a failed attestation service does not halt a training run without a decision by a named owner.

Decision guidance: an enterprise fine-tuning open models in a colocation cage should aim for SL2 to SL3, focus on management plane isolation, workload identity and egress monitoring, and ask its provider for evidence of BMC and firmware controls. A cloud or GPU provider hosting frontier labs should plan for SL4 measures and offer confidential computing with attestation. A frontier developer planning facilities for 2028 onward should evaluate the SL5 draft now, because, as its authors note, facility construction and hardware procurement have the longest lead times.

Detection and measurement

Monitor bulk reads of weight stores (ATT&CK T1530), unusual cloud identity use (T1078.004), large transfers to external storage (T1567.002), firmware and attestation failures, BMC logins and configuration changes, physical access to enclave zones correlated with logical access, and OT alarms in cooling and power systems. Useful metrics:

• Number of locations holding full weight copies, against the approved set.
• Percentage of nodes that passed firmware attestation before joining the cluster.
• Number of BMC and management interfaces reachable from outside the management network (target zero).
• Mean time to triage a weight-store bulk read or egress cap breach.
• Percentage of incoming accelerators inspected and serial-verified before installation.
• Percentage of enclave entries with two-person integrity recorded.

Framework mapping

Common failure patterns

• Weight copies everywhere: checkpoints on scratch storage, evaluation clusters and researcher machines outlive the run and escape the enclave.
• BMCs on a flat network: management interfaces reachable from compute or office networks, with default or shared credentials, giving pre-boot access to every node.
• Trusting confidential computing beyond its threat model: assuming a GPU TEE protects against the host administrator or physical attacks when the chosen mode does not.
• Uninspected hardware: accelerators installed straight from the dock, with no serial verification or quarantine.
• Unmetered egress: no limit or alert on outbound volume from weight stores, so a full copy leaves in minutes.
• Facility OT treated as somebody else's problem: cooling and power controls on a vendor-managed network outside security monitoring.

Practitioner checklist

• Record the target RAND security level for each model tier and the attacker class it covers.
• Inventory all weight and checkpoint locations and cut them to an approved set.
• Isolate BMC, switch, fabric and OT management networks; remediate KEV-listed BMC firmware first.
• Require signed firmware and attestation before a node joins a cluster.
• Create a weight enclave with dual authorisation for export, key and storage policy changes.
• Apply and monitor egress limits on weight stores and enclaves.
• Quarantine, inspect and serial-verify incoming accelerators.
• Extend screening and the insider threat programme to facility and hardware staff.
• Give every pipeline stage its own short-lived workload identity.
• Track the SL5 draft, RAND's facility design and any US high-security AI data centre standard.

Standards and references

• RAND: Securing AI Model Weights
• RAND: Highly Secure Inference Data Centers
• arXiv: SL5 Standard for AI Security (v0.1 draft)
• The White House: America's AI Action Plan
• NIST: AI Data Center Security Workshop agenda
• CISA and NSA: Joint guidance on hardening baseboard management controllers
• NVIDIA: Confidential Computing documentation

Related NHI Mgmt Group resources: Securing AI Model Weights · Data Centre Security Guide · Confidential AI and GPU Enclaves Guide · Server BMC Security · AI Infrastructure Workload Identity Guide