Lava Security’s Yakir Kadkoda on the AI Data Center Boom: Growth, Security, and the Risks in Between

The rapid expansion of artificial intelligence is driving demand for computing power, placing data centers at the center of a growing debate in the United States. While new facilities promise greater computing capacity, concerns over electricity costs, water consumption, and environmental impact have prompted calls for tighter oversight, including proposals to pause new construction. Beyond these concerns lies another challenge: securing the infrastructure that powers AI. As companies increasingly rent GPU capacity from specialized cloud providers known as neoclouds, questions arise about hardware security, shared infrastructure, and the isolation of customer workloads. Lava Security is a cybersecurity company focused on protecting neoclouds and AI data centers. Its platform provides visibility across computing, networking, storage, and hardware management systems, helping operators identify vulnerabilities, verify firmware integrity, and detect security gaps between tenants. We spoke with Yakir Kadkoda, Co-Founder and CTO of Lava Security, who previously served as Director of Security Research at Aqua Security and currently co-leads the OWASP Top 10 for Neocloud and AI Data Center Security Risks project. He discusses the debate over data center expansion, vulnerabilities in GPU cloud infrastructure, and the responsibilities of operators, customers, and policymakers. Q: Why does the U.S. need more AI data centers? What’s one example outside Big Tech where access to more computing power would make a tangible difference? A: AI is not a feature anymore, it is infrastructure, like power or roads. Every hospital, bank, university and manufacturer is going to run models, and most of them cannot buy GPUs by the thousand. They rent them. More data centers means more supply, lower prices and shorter waits for everyone who is not a hyperscaler. Three examples outside Big Tech. A hospital group running its own models on patient data: it cannot send that data to a public API, so it needs local or rented GPUs, and today it waits months or pays a premium. A university lab that queues for weeks on a shared cluster, where more capacity means faster science. A startup on a neocloud with no capex, living on rented GPUs, which feels every price hike first. Q: If Congress paused new data center construction and expansion, who would feel it first? Could the biggest tech companies rely on the capacity they already control while startups and researchers face higher prices or longer waits? A: Startups, researchers, and smaller companies would pay the price first. Big Tech already owns enormous compute capacity. Everyone else depends on renting it. Restricting new data centers would drive prices up, reduce availability, and concentrate even more power in the hands of the largest players. And AI development wouldn’t stop. It would simply move to countries that continue investing in infrastructure. Q: Lava analyzed publicly exposed data from more than 12,000 GPUs and found thousands reporting zero utilization. What can that snapshot tell us about how efficiently existing capacity is used, and what can’t it tell us? A: Between March and May 2026, our research identified more than 2,100 servers publicly exposing monitoring data from over 12,000 NVIDIA GPUs, representing roughly $100 million in hardware. Nearly 60% reported zero utilization when we observed them. That doesn’t mean 60% of GPUs are permanently idle. Some could have been between jobs, reserved, or undergoing maintenance. It’s a snapshot of a specific exposed population, not the entire industry. The bigger finding isn’t unused GPUs. It’s that thousands of expensive AI systems were leaking operational information to anyone on the internet. We need better visibility, security, and utilization of existing infrastructure alongside building more capacity. These are complementary goals, not competing ones. Q: What do supporters of a data center moratorium get right? Which of their concerns would a construction pause actually address? A: They’re right that infrastructure growth needs to be responsible. Electricity, water, environmental impact, and security are legitimate concerns. But stopping construction is the wrong solution. We don’t stop building hospitals because they consume electricity. We improve how they’re built and operated. The same principle applies to AI infrastructure. Set clear requirements, enforce them, and make operators accountable. The answer to infrastructure challenges is better infrastructure, not less infrastructure. And there’s a national competitiveness dimension. If America slows down while other countries accelerate, the demand for AI doesn’t disappear. The infrastructure, investment, and innovation simply move elsewhere. Q: If you were advising a town considering a large data center, what would you ask the developer to put in writing about electricity costs, water use, and permanent jobs? What would make you advise the town to reject the project? A: I’d focus on three things: measurable economic benefits, responsible resource consumption, and operational security. The developer should clearly explain how much electricity and water the facility will consume, who pays for infrastructure upgrades, and how many permanent jobs it will create. Those commitments should be measurable and enforceable. I’d also require a credible security plan. Modern AI data centers are complex infrastructure environments with thousands of interconnected systems, including servers, management controllers, networking equipment, and industrial control systems. Communities should welcome investment, but demand transparency and accountability. The goal should be to build data centers that benefit both the local community and the broader economy. Q: What changes when a company rents GPUs from a specialized cloud provider instead of running its own infrastructure? Which security decisions does it hand over to the provider, and how much visibility does it get in return? A: You give up control of the infrastructure, but you don’t give up the security risk. When you rent GPUs, you’re trusting someone else with the physical servers, firmware, networking, storage, and management systems running your workloads. You’re also sharing infrastructure with other customers, sometimes on the same physical machines or interconnected networks. The biggest challenge is visibility. Most customers can monitor their workloads but have almost no visibility into the infrastructure underneath them. They cannot independently verify whether other tenants are properly isolated, whether the underlying hardware is secure, or whether previous customers left anything behind. The fundamental problem is that customers are expected to trust infrastructure they cannot see or verify. Q: In The Next Web, you described Lava’s research into compromising the systems that manage GPU clouds. Can you walk us through one case you can discuss publicly? What access did you start with, what did you actually reach, and what could that have exposed? A: We rented GPU infrastructure just like any regular customer would. From that environment, we discovered that security boundaries which appeared to exist at the container or virtual machine level didn’t extend to the underlying infrastructure. In one case, we could reach internal management systems and infrastructure that should never have been accessible to a customer. That created a potential path from a single rented machine into the provider’s broader infrastructure, putting other customers and their workloads at risk. The most concerning part? We didn’t need sophisticated exploits. In some cases, the problem was simply how the infrastructure had been configured. Across our research, we identified serious control-plane security vulnerabilities at different providers. We responsibly disclosed the findings, and the affected providers addressed them. Q: When a GPU server is handed from one customer to the next, what should the operator verify before putting it back into service? Where do you see operators under the most pressure to cut corners? A: The provider needs to ensure the previous customer is completely gone, not just from the operating system, but from the underlying infrastructure. That means securely sanitizing storage, removing credentials and encryption keys, clearing persistent data, and verifying the integrity of firmware and management controllers. A simple reboot or operating system reinstall isn’t sufficient. The challenge is economic. GPU providers make money when their hardware is running workloads, not when it’s undergoing security verification. That creates pressure to minimize the time between customers. But speed cannot come at the expense of isolation. One customer’s data, models, or credentials should never become accessible to the next. And customers should be able to verify that these protections actually exist. Q: What’s one serious vulnerability in an AI data center that conventional cloud security tools would likely miss? Why is it harder to spot, and what could an attacker do with it? A: One of the biggest blind spots is the Baseboard Management Controller, or BMC. It’s essentially a separate computer inside every physical server, with powerful capabilities to control and manage the hardware remotely, even when the main server is turned off. Traditional cloud security and endpoint security tools generally don’t monitor this layer. In our research, we identified more than 36,000 management interfaces exposed to the internet, many with serious authentication vulnerability. An attacker who compromises a BMC can control the entire physical server, independently of the operating system and the security software running on it. And if management networks aren’t properly isolated, one compromised controller can become a path into an entire fleet. This is why securing AI infrastructure requires visibility beyond operating systems, containers, and cloud APIs. You cannot protect infrastructure you don’t even know exists. Q: Based on the OWASP project you co-lead, what three pieces of evidence should a company ask for before putting a valuable AI model on rented GPUs? What answer from a provider would make you walk away? A: First, proof of tenant isolation. I want evidence that other customers cannot access my workloads, storage, networking, or underlying management infrastructure. Second, proof of hardware and firmware integrity. I want to know that the physical infrastructure I’m running on hasn’t been compromised, including the GPUs, management controllers, and networking equipment. Third, proof of secure tenant handover. I want evidence that previous customers’ data and credentials were properly removed and that mine will be too. These are exactly the kinds of risks we’re addressing through the OWASP Top 10 for Neocloud and AI Data Center Security Risks. And here’s what wouldn’t satisfy me: a SOC 2 certificate alone. Compliance is important, but being compliant doesn’t automatically mean your infrastructure is secure. You want technical evidence, not just paperwork. Q: If lawmakers asked you for two conditions every major AI data center should meet before going live, what would you require to protect the surrounding community and the companies running workloads inside? Who should verify those commitments? A: First, accountability to the community. Operators should make clear, enforceable commitments around electricity, water, infrastructure costs, and local economic benefits. Second, independently verified infrastructure security. Before hosting sensitive workloads, operators should demonstrate that their infrastructure is secure across the entire stack, from physical hardware and firmware to networking, virtualization, and tenant isolation. Today, many security assessments focus on applications and operating systems while overlooking the infrastructure underneath them. That’s a dangerous gap, particularly as AI data centers become critical infrastructure. Our OWASP Top 10 for Neocloud and AI Data Center Security Risks provides a starting point for establishing common security expectations. Verification should be performed independently, with meaningful evidence available to customers. We don’t need to slow down AI infrastructure development. We need to make security and accountability part of how that infrastructure is built from day one. This article was published under HackerNoon's Business Blogging program.