Our Top 10 Neocloud and AI Data Center Security Risks Joins OWASP

Our Top 10 Neocloud and AI Data Center Security Risks is now an OWASP Project. As project co-leads, we’ll continue developing it with the OWASP community.

Earlier this year, we published the first version of the framework, building on Lava’s research into neocloud and AI data center security. It draws on disclosed vulnerabilities, incident reports, vendor documentation, and real-world experience. Feedback from over 20 security and infrastructure practitioners across neocloud providers, hardware OEMs, security companies, universities, and research institutions helped shape the risks, attack scenarios, and mitigation guidance.
Why AI Infrastructure Needs Its Own Security Framework

AI infrastructure is evolving rapidly, but many of the technologies it relies on were designed for trusted high-performance computing environments. In neoclouds, those technologies now serve unrelated customers sharing networks, storage, and management infrastructure.

For example, in a bare metal neocloud, tenants have root access to the servers they rent. An unrestricted local interface to the management controller can let them change the server’s boot configuration. These settings can survive an operating system reinstall and affect the next customer if the provider does not reset them between rentals.

Yet the knowledge needed to secure these environments remains fragmented across hardware vendors, infrastructure providers, operators, and researchers. Risks well understood by one group may be overlooked by another, making it difficult to establish consistent security practices across the industry.

The OWASP Top 10 Neocloud and AI Data Center Security Risks was created to help close this gap.

It brings together the most important infrastructure security risks into a shared, practical framework that helps the industry understand common threats, learn from real-world findings, and improve how AI infrastructure is secured.

The Top 10 Security Risks

1. Hardware & Firmware Integrity Compromise: Attackers can compromise firmware or hardware components that control physical servers. These attacks can operate below the operating system, making them difficult to detect and potentially allowing attackers to maintain access even after a server is reinstalled or reassigned.

2. Network & Interconnect Vulnerabilities: AI infrastructure relies on high-speed networks such as InfiniBand, RoCE, and RDMA to connect servers and GPUs. Misconfigurations or vulnerabilities in these networks can expose sensitive data, enable unauthorized access, or allow attackers to move between systems.

3. Unsafe Multi-Tenant Isolation and Resource Reuse: Neoclouds often share physical infrastructure between multiple customers. Weak isolation or improper cleanup between users can allow one tenant to access another tenant’s data, workloads, or infrastructure.

4. Insecure Out-of-Band Management Plane: Servers rely on dedicated management interfaces, such as BMCs, for remote administration. If compromised, these interfaces can give attackers extensive control over physical machines, including the ability to modify firmware, access consoles, or disrupt entire server fleets.

5. AI Infrastructure Supply Chain Compromise: AI infrastructure depends on hardware, firmware, drivers, and software from multiple vendors. Compromised components or updates can introduce malicious code or hidden access before systems are deployed or while they are running.

6. Insecure Facility & Data Center Management Systems: Data centers depend on power, cooling, physical access controls, and facility management systems. Security gaps in these systems can expose sensitive information, disrupt operations, or affect the availability of critical infrastructure.

7. Insecure Data and Artifact Handling: AI workloads rely on shared storage, datasets, model weights, and checkpoints. Weak access controls or improper data cleanup can expose sensitive information, allow unauthorized modifications, or leave data accessible to future users.

8. Certification Gaps & Provider Transparency Failures: Security certifications don’t always cover the entire infrastructure. A provider may have certified its software platform while leaving the underlying hardware and operational systems outside the audit scope. Customers may also lack visibility into who operates the infrastructure or which security controls actually apply.

9. Insecure Operational Infrastructure Services: AI data centers rely on centralized services to provision, configure, and manage servers and workloads. Compromising these systems can allow attackers to change configurations, disable security controls, deploy malicious workloads, or gain control over large parts of the environment.

10. Vendor Embargo Gaps & Patch Velocity Failures: AI infrastructure depends on complex technologies that require ongoing security updates. Delayed vulnerability disclosures, slow patch availability, or operational challenges in deploying updates can leave critical systems exposed to known vulnerabilities for extended periods.

Each risk includes potential attack scenarios, real-world implications, and practical mitigation guidance.

For infrastructure providers and operators, the framework offers a way to assess their environments, identify security gaps, and prioritize improvements. For neocloud users, it provides a common language for understanding the risks associated with the infrastructure running their AI workloads and asking providers the right security questions.

The full framework is available on our website.

What becoming an OWASP project means

We brought the framework to OWASP to develop it with a wider community. Providers, infrastructure engineers, hardware vendors, and security researchers see different deployments and different failures. Their experience can help improve the guidance and identify risks we have missed.

The framework is vendor-neutral, and development takes place openly on GitHub. Anyone can review the content, challenge an assumption, contribute research, or propose changes. Contributors are credited in each release.

Read the OWASP project page, or open an issue or pull request on GitHub to contribute.