Threat Model, Assets & Security Levels for AI Infrastructure

The controls in an AI data center are downstream of a question almost nobody states explicitly: which adversary are you actually trying to stop? Not "hackers" in the abstract — a specific, named tier, from a bored insider with a USB stick to a top-priority operation run by the most cyber-capable state on earth. That answer drives Part 11 the way the workload archetype drove Part 1. Pick it and the firewall rules, the standoff distance, the attestation flow, the egress cap, and the two-person rule all follow as consequences. Skip it and you buy a pile of expensive controls that defend the wrong asset against the wrong attacker, and you discover the gap the day a competitor's frontier weights show up on someone else's cluster.

This chapter builds the threat model in three moves. First, why AI data centers are a special case — the asset-value density, the IP concentration, and the strategic targeting that together make an unscoped cloud-security posture inadequate for some services. Second, the asset taxonomy and adversary tiers, anchored on the RAND Securing AI Model Weights framework — five Weights Security Levels, five operational-capacity adversary tiers, and the 38 attack vectors that map between them. Third, the defense-in-depth reference architecture and the method of setting a target level and deriving controls from it. Each selected control must identify the attack path it constrains, its enforcement evidence, and its cost in capex, performance or operability, and the target level and service boundary frame that trade before you commit steel, silicon, or staff.

A hyperscale e-commerce hall and a frontier-training campus can look identical from the road and run the same SOC 2 controls — and be in completely different threat models. Three properties make the AI facility a special case, and each one breaks an assumption that generic data-center security quietly relies on.

Asset-value density. A single GB200 NVL72 rack is about $3.1M for the server alone in SemiAnalysis’s August 2025 hyperscaler model; its accelerator supply and replacement lead time add a separate exposure, and its GB300 successor — the principal NVIDIA rack platform of 2026 — comes out of the same constrained allocation. The constraint, not the dollar figure, is what changes the economics. Generic cloud hardware is fungible and insured; a stolen or destroyed NVL72 is not replaced by a purchase order, it is replaced by waiting at the back of an allocation queue measured in quarters. That inverts the loss function: the asset is worth more because it cannot be re-bought quickly, which makes physical theft and physical destruction rational adversary goals in a way they never were for commodity servers. The March 2026 drone strikes (below) proved the destruction case is no longer hypothetical.

IP concentration. The frontier model weights resident on the cluster are arguably the single highest-value digital asset in existence — a multi-hundred-million-dollar training run compressed into a few terabytes that, once exfiltrated, hand a competitor or an adversary state a capability they did not pay to build. RAND treats frontier weights as a national-security asset warranting defenses up to nation-state grade. The crucial property is that the loss is silent and complete: unlike a stolen database, a copied weight file leaves the original in place, so there is no outage, no missing inventory, no obvious tell — the first signal may be a rival model that is suspiciously similar. This is why egress control, not perimeter control, becomes the linchpin (→ Chapter 11.8).

Strategic targeting. AI compute is now treated as strategic infrastructure by states, which means the adversary set includes actors with intelligence services, kinetic reach, and supply-chain access — not just criminals. On 1 March 2026, IRGC Shahed drones struck two AWS facilities in the UAE with direct hits and blast-damaged a third in Bahrain, causing structural damage, power loss, and fire/water damage from suppression, and taking down multiple availability zones simultaneously so that standard redundancy models failed (CNBC; The Conversation, March 2026). It was the first time a state deliberately targeted commercial data centers in wartime. The planning consequence is blunt: "kinetic attack on a data center" moved from a tail risk you accept to a design case you must address — and most legacy physical controls (fences, cameras, ground access control) were never designed for an aerial threat (→ Chapter 11.2).

You cannot derive controls from a target level until you know which assets the level is protecting, and the most common scoping error is treating every asset as equally precious. An AI data center has a clear hierarchy of crown jewels: the heaviest controls belong on the top tier, with lighter controls deliberately accepted below it, because a budget spread evenly defends nothing well. Five asset classes, ranked by what an adversary actually wants and what its loss actually costs.

Read the table top-down as a budgeting instrument. Unreleased frontier weights sit at the top of this confidentiality example because a copied artifact can leave the owner unaware and cannot be recalled — so they justify controls (confidential computing, attestation, hard egress caps) where the adversary and exposure justify their cost. Facility availability sits at the bottom of the confidentiality hierarchy not because outages are cheap but because they are loud — you may detect their loss promptly, but failover needs tested capacity and an eligible recovery path — whereas a copied weight file is the loss you never see. The management plane is the sleeper: it is rarely the adversary's objective, but it can be a path, which is why it earns crown-jewel-grade controls despite holding no IP of its own. For an open-weight service, tenant prompts, credentials and availability can rank above the already-public weights. Misranking these is how budgets get spent on hardening the loud, recoverable asset while the silent, unrecoverable one walks out an unmonitored egress.

The RAND Securing AI Model Weights report (RRA2849-1) is the field's shared vocabulary, and its central insight is that you cannot reason about "is this secure" without naming the adversary. RAND defines five operational-capacity (OC) tiers of attacker, from OC1 (amateurs) to OC5 (the top cyber-capable states running their highest-priority operations), and enumerates 38 distinct attack vectors across them — from social engineering and supply-chain implants to side-channels and human intelligence. The decisive finding for design: RAND assesses eight vectors as likely infeasible for OC1–OC3 and likely feasible for OC4–OC5, creating a practical step-up in the required control set along a continuum of attacker capabilities.

Mapped onto those adversaries are five Weights Security Levels (SL1–SL5), each defined operationally: an SL is the posture assessed as likely to thwart the corresponding OC-tier adversary's attempt to steal the weights. SL1 thwarts amateurs; SL2 thwarts professional opportunistic attackers running moderate-effort, non-targeted operations; SL3 thwarts cybercrime syndicates and capable insiders; SL4 thwarts the standard operations of leading cyber-capable institutions; and SL5 could plausibly claim to thwart the top-priority operations of the most capable states (RAND, 2024). The reason this framework won is that it turns an unfalsifiable claim ("we're secure") into a falsifiable one ("we meet the SL-N benchmark"), and it gives a campus a single target number to design toward.

In an AI data center, defense in depth is a stack of independent boundaries, each owned by a different chapter of Part 11, arranged so that defeating one layer does not defeat the asset. The architecture is best read from the outside in, because that is the order an adversary must traverse and the order in which a missing layer turns a partial compromise into a total one.

• Physical perimeter and zones — siting standoff, the concentric zones (perimeter → facility → data hall → cage/rack, deepened into a five-zone reference model) with escalating MFA, surveillance, and now counter-UAS for the aerial threat the March 2026 strikes made real (→ Chapter 11.2).
• Supply-chain and provenance — vetting silicon and firmware before it enters the fence, tamper-evident logistics, HBOM/SBOM, and OCP S.A.F.E. firmware audits, because an implant or counterfeit defeats every layer above it from inside (→ Chapter 11.3).
• Hardware root of trust and firmware — a silicon RoT (Caliptra, DICE identity on DC-SCM), secure/measured boot, and a hardened, segmented BMC, so that the foundation every higher control trusts is itself attestable and not the soft underbelly (→ Chapter 11.4).
• Confidential computing and tenant isolation — GPU TEE with a protected HBM region (encrypted on Blackwell) and attestation, plus the MIG/vGPU isolation boundary whose documented limits set how much you can trust a shared GPU (→ Chapter 11.5, Chapter 11.6).
• Network segmentation and zero trust — DPU-enforced microsegmentation, management-plane isolation, and egress control as the anti-exfiltration choke point (→ Chapter 11.7).
• Model and weight protection — the crown-jewel layer: at-rest encryption, in-transit protection, attestation-gated in-use keys, and the egress caps that catch the silent loss (→ Chapter 11.8).
• The human layer and OT plane — insider-threat controls, two-person rules, and the hardening of the facility's OT/ICS (BMS/EPMS/CDU/BESS) against cyber-physical sabotage, the layers that no amount of cryptography can substitute for (→ Chapter 11.9, Chapter 11.10).

The point of arranging them this way is the independence property: a compromised BMC should not yield the weights if confidential computing and egress caps still stand; a defeated fence should not yield the silicon if the data hall and cage zones still gate access. Defense in depth fails not when one layer is breached — that is expected — but when layers share a single point of failure (a flat management network, a universal admin credential, an unmonitored egress) that lets one breach cascade.

The method inverts how security is usually bought. Instead of starting from a catalog of controls and asking which to adopt, start from the target Weights Security Level — the adversary tier you have decided the campus must survive — and derive the controls as the necessary set to reach it. The level is the design basis; the controls are its consequences — the same shape as the workload archetype driving the whole facility in Part 1, one upstream decision that collapses a hundred downstream ones.

The target level is itself a business decision, not a security one. A neocloud renting commodity inference capacity to many tenants may rationally target SL2–SL3: its assets are valuable but not frontier weights, and the cost of SL4 controls (performance overhead, operational drag, supply-chain vetting) would price it out of a margin-thin market. A frontier lab training a flagship model has no such luxury — its adversary is OC4–OC5 by definition, so anything below SL4 is a posture mismatched to its actual threat, and the over-investment is the only rational investment. The error is choosing a level by budget and hoping the adversary cooperates; the adversary is set by what you hold, not by what you can afford.

Two consequences make the level a substrate decision, not a policy one. First, the irreversible layers must be built to the highest level the campus might ever host, because you cannot retrofit standoff distance, network trust zones, or a hardware root of trust into a running cluster without tearing it down — the same density-ramp logic that governs floor loading and water (→ Chapter 11.4; the ramp framing in Chapter 1.1). Second, every level above SL2 taxes goodput and operability: isolation strands capacity, attestation adds latency, egress caps constrain legitimate data movement, two-person rules slow operations. The target level prices that tax up front, which is precisely why it must be decided before the controls are bought — so the trade is made with eyes open rather than discovered control-by-control after the cluster is live.

The same mis-scopes recur, because each comes from skipping the target-level question and reasoning from a control catalog or a compliance checkbox instead. Four are worth naming:

• Compliance as security. Treating SOC 2 attestation / ISO 27001 certification as evidence of an SL4 posture. These frameworks verify that controls exist and are operated; they do not establish that those controls thwart an OC4 adversary. A clean audit and a copied weight file are fully compatible.
• Perimeter thinking for a silent asset. Spending the security budget on fences, badges, and ingress controls while the egress path that the weights would actually leave through goes unmonitored and uncapped. You are guarding the entrance to a building whose crown jewel walks out the exit (→ Chapter 11.8).
• Over-defending the loud asset, under-defending the silent one. Hardening facility availability (which announces its own loss via an outage) to 2N-grade resilience while the weights (whose loss is silent and permanent) sit behind SL2 controls. Match the control to the loss signature, not to the dollar value alone.
• Budget-chosen levels. Picking a security level the organization can comfortably afford and assuming the adversary will scale down to match. The adversary is set by what you hold; choosing SL2 because SL4 is expensive does not make your OC4 adversary go away — it leaves that attack path outside the claimed defense.

Choose the service and adversary before buying controls, and attach each acceptance result to its asset and owner. A lower-threat offering saves operating friction only while its intake excludes the higher-risk workload. Accepting those weights later without changing the boundary transfers an unpriced theft risk to the customer.