The AI you run in production executes somewhere, on a GPU cluster, in a data center, on infrastructure you will never physically inspect. That infrastructure is being built at the speed of the AI gold rush and secured at the speed of habit. And the most dangerous risks in it do not live in the software you can see. They live below the operating system, in firmware, interconnects, and shared silicon, where almost none of the security industry’s tooling is even looking.
The Trust Model Just Inverted
A July 2026 SecurityWeek analysis of research from Lava Labs reaches a blunt conclusion: AI data centers are being built faster than they are being secured. The reason is not negligence. It is that the people building these facilities at speed are using a blueprint that no longer describes what they are building.
A traditional data center is a processing warehouse serving a known clientele. It can be a collection of independent servers, each reasonably isolated, each serving a party you have a contract with. An AI data center is a different machine entirely: a high-power compute factory that must function as a single engine capable of massive parallel processing, serving a larger and often unknown clientele. You cannot build the second thing the way you built the first.
“Systems originally designed for trusted operators are now supporting high-value, multi-tenant workloads from unrelated customers.”
Lava Labs: The Top 10 Data Center and AI Infrastructure Security Risks
That single sentence is the whole problem. The trust model of a traditional data center assumed operators you trust and tenants you know. AI infrastructure introduces unrelated commercial tenants, extremely high-value workloads, and GPU nodes that get reassigned between customers. The assumptions the old design rested on are simply gone and the controls built on those assumptions go with them.
The Dangerous Risks Live Below the OS
Lava Labs names its framework Forge, the stated purpose is to “harden the metal beneath the model” and ranks ten risk classes by severity. The ordering is the insight. The five most severe all operate below the operating system, are difficult to detect, and carry a cluster-wide blast radius.
The remaining five Forge risks, insecure facility management systems, insecure data and artifact handling, certification and transparency gaps, insecure operational services, and vendor embargo and patch-velocity failures are generally easier to detect and recover from. But the top five share a property that should worry any organization renting AI compute: they are the hardest to see and the widest in impact, and they sit at exactly the layer a tenant has the least visibility into.
Almost every security tool an enterprise owns EDR, workload protection, cloud posture management operates at or above the operating system. A firmware implant, a compromised interconnect, or a GPU that wasn’t properly wiped between tenants sits underneath all of it. The blast radius is the entire cluster, and the detection surface is close to zero. This is the same “architecture beneath the visible layer” problem that makes static-secret and supply-chain compromises so damaging, moved down to the silicon.
The Interconnect Is the New Soft Underbelly
Of all the below-the-OS risks, the interconnect deserves special attention, because it is the one most people have never thought of as an attack surface.
AI clusters depend on high-performance fabrics – InfiniBand, RoCE, RDMA, NVLink to move data between GPUs fast enough to train and serve large models. These fabrics were engineered for speed inside a trusted environment, not for adversarial multi-tenancy. In practice that means they are often unencrypted, poorly monitored, and highly privileged. Remote direct memory access, the “D” and “M” in RDMA, is exactly what it sounds like: one node reaching directly into another’s memory. Weak isolation on that fabric can expose paths to discovery, abuse, and lateral movement across the cluster.
The interconnect is the highway between GPUs. When it is unencrypted, unmonitored, and privileged, it is also the highway an attacker uses to move between tenants who were never supposed to touch each other.
Propelex Security Intelligence
This is the multi-tenancy problem made concrete. In a traditional data center, lateral movement means traversing a network you can instrument and inspect. In an AI data center, it can mean traversing a memory fabric most security teams have never monitored, connecting workloads from companies that have no relationship except that they rented capacity from the same provider.
You Are Sharing Silicon With Strangers
The economic engine of the AI data center is utilization. GPUs are scarce and expensive, so they are packed densely and reassigned constantly between customers to keep them busy. That efficiency is also the risk. A GPU node that served one company’s confidential workload this morning may serve an unrelated company’s this afternoon.
If the isolation and reset between those assignments is imperfect – residual memory, cached artifacts, leftover state, one tenant can inherit fragments of another’s data or workload. Combine that with the artifact-handling risks Forge identifies, and the multi-tenant AI data center becomes a place where high-value data from unrelated parties coexists on shared hardware with isolation that was, in many builds, an afterthought.
The scarcity dynamic makes it worse. When GPUs are hard to get, new AI data centers opt for whatever processors they can source, sometimes ones with weaker isolation properties which raises the likelihood of both supply-chain compromise and tenant-to-tenant leakage. The pressure to fill the facility works directly against the discipline required to secure it.
What to Do If You Build, Buy, or Rent AI Compute
Most organizations reading this will not build an AI data center. They will rent capacity in one which means the practical question is not “how do I secure my facility” but “how do I evaluate the facility my AI already runs in.” Guidance for both.
If you rent or buy AI compute
- Demand tenant-isolation evidence, not assurances. Ask how GPU nodes are wiped and validated between tenant assignments, and require documentation. “It’s isolated” is not an answer; the reset and verification procedure is.
- Ask whether the interconnect is encrypted and monitored. If the provider cannot tell you how the InfiniBand or RoCE fabric is isolated between tenants, treat that as an unmonitored lateral-movement path and price the risk accordingly.
- Require firmware and supply-chain attestation. Get written answers on hardware provenance, firmware integrity validation, and how quickly firmware-level vulnerabilities are patched. Forge’s patch-velocity risk is real and provider-specific.
- Close the certification and transparency gap contractually. Where provider transparency is thin, put the obligations in the contract, audit rights, incident-notification terms, and evidence of independent assessment.
If you build or operate AI infrastructure
- Secure below the OS first. Firmware integrity, the out-of-band management plane (BMC, Redfish, IPMI), and interconnect isolation are the highest-severity, hardest-to-detect risks. Prioritize them ahead of the OS-layer controls you already know how to run.
- Treat GPU reuse as a data-handling problem. Build and verify a rigorous wipe-and-attest process between tenant assignments, and log it as evidence you can show customers.
- Don’t let GPU scarcity dictate your isolation posture. If the only processors you can source have weaker isolation, that is a risk decision for security to own — not a procurement default to absorb silently.
The Bigger Picture
The verdict from the Lava Labs analysis is unambiguous: yes, you will need a new kind of data center to feed your AI but no, you cannot use your existing data center model as the design blueprint. The industry is discovering that the hard way, one gold-rush build at a time.
For the organizations that consume AI rather than host it, the takeaway is sharper still. Your AI strategy now has a dependency you cannot see and did not design: the physical infrastructure it runs on. The security of that infrastructure is someone else’s build decision, made under intense speed and scarcity pressure, at a layer your own tooling cannot inspect. That is precisely the kind of third-party, below-the-visible-layer risk that does not show up until it becomes an incident.
The riskiest part of your AI stack is the part you will never see. You cannot audit the firmware or the fabric yourself but you can make provider transparency a procurement requirement, and refuse to run high-value workloads on infrastructure that won’t answer the hard questions.
Propelex Security Intelligence
AI data centers are being built faster than they can be secured. That gap is not going to close on its own, and it will not close before your workloads are already running inside it. The organizations that ask the below-the-OS questions now before they sign, before they scale, before the incident are the ones that will not be surprised by an attack surface they never knew they depended on.
Propelex helps organizations assess the security of the AI infrastructure they build on and rent evaluating provider tenant-isolation, interconnect and firmware posture, supply-chain attestation, and the contractual transparency that closes the gaps you can’t audit yourself. We start with a Cybersecurity & Privacy Risk Assessment scoped to your AI and cloud infrastructure dependencies. Fortune 50-experienced consultants across regulated industries.
