Cyber defenses have grown more vital — and more complex — as artificial intelligence (AI) evolves. Critical infrastructure in particular is a key area where cybersecurity professionals need to dedicate their attention, as the disruption of this infrastructure can lead to lasting repercussions. 

Here, Security magazine talks with Vrajesh Bhavsar, CEO of Operant, about the importance of infrastructure-level protection as AI advances. 

Security: Tell us about your background and career. 

Bhavsar: I was born and raised in Gujarat in India, where my father was an engineer, doing critical work to keep electricity power stations up and running, so I have always had a very tangible idea of how much the world depends on the dedication of skilled engineers for everyday life to function.

I came to the United States from India for my Masters in Computer Science at USC back in 2003, and then began my career at Apple as a kernel engineer, building core tech for iOS and macOS including dynamic tracing (aka DTrace), Data Protection, and Secure Enclave. I later built AI/ML systems to detect malicious apps in the Android ecosystem at Qualcomm research, which is where I met Priyanka Tembey, Operant’s CTO and one of my co-founders. Back then, we worked together applying ML algorithms to solve really hard security problems at scale in that new app ecosystem that was evolving exponentially. New threats were emerging almost daily and there was very little security that could be applied at scale to protect end users. There were many parallels between that “wild west” time and today’s threat landscape in the Age of AI. 

After that experience, I joined ARM, where I founded their AI & ML business unit, bringing security to billions of devices at the Edge and worked on some of the foundational tech for the GenAI ecosystem, but I had the startup “bug” and eventually joined Scaled Inference, a Reinforcement Learning startup founded by former Google Brain engineers. There, we worked on operationalizing advanced reinforcement learning for high value business use cases, and after Scaled Inference was acquired by AirBnB, I turned my focus towards founding Operant AI to solve the most critical unsolved challenges in the world of Cloud and AI. Priyanka joined as our CTO, bringing exceptional expertise from the world of distributed systems and hybrid clouds, and our third co-founder, Ashley Roof, joined on the GTM side. Since then, we have been building some of the most advanced and useful tech on the market for solving many of the most critical problems in AI and Cloud security today. We announced our Series A in September of 2024, and the rest is “history.” 

Security: Why is infrastructure-level protection important?

Bhavsar: The word infrastructure in this context can have so many meanings! Infrastructure-level protection is important both in the world of software, where what we mean is protecting the infra layer of the software stack (the “OSI” Infra layer) that is running on your public or private cloud (like Kubernetes containers running in AWS or in your own datacenter via OpenShift), but then, obviously in the world of AI, protecting the world’s critical infrastructure takes on a new meaning as cloud architecture and AI are being used for so many high-impact use cases and are being attached to so many critical systems. From managing airplane auto-pilots to controlling logistics for shipping containers, the world is more dependent than ever before on software infrastructure being protected.

Focusing on the software context for a second, we are just past a massive paradigm shift in which “old-school” security practices don’t translate to the distributed, ephemeral, and complex world of the cloud, with AI and its many enhanced attack paths adding an even greater urgency to a problem that was already dangerous and unsolved. In the “old world” of hardware firewalls in a private data center with hard-coded network-layer microsegmentation rule-sets that let specific traffic through while blocking other traffic, resources for constantly maintaining those rulesets were already untenable for all but the Fortune 500. In fact, that lack of scale is partly what led to the cloud revolution in the first place. But, in the modern world of AI, the majority of which is currently built and deployed on Kubernetes infrastructure, those network-layer rules don’t actually work. What that means, practically speaking, is that companies have so far been able to secure their cloud environments at the outer perimeter with WAFs (web application firewalls), but they haven’t been able to secure the internals of their Cloud and Kubernetes environments, where APIs and third party containers (including AI APIs and third party AI models, both open source models like Llama2 and Deep Seek, and commercial models like those by Cohere, Anthropic and Mistral), are letting data pass in and out unchecked, while infra-level and API access controls and data privacy rules are not being enforced inside the cloud application perimeter. Why? Because it is a really hard technical problem to solve.

AI is now basically exaggerating the criticality and catastrophic blast radius of major threat vectors that had already not been solved before the Gen AI revolution, because in order to actually protect infrastructure, you need to have active blocking of attack paths at runtime that address the movement of attackers from the infra layer into the rest of the application stack. Most cloud application “protection” today is done statically at just the cloud layer or in static code analysis mode before code is pushed live. That means it can only identify publicly known vulnerabilities at the time of the build, so any zero day vulnerabilities or prompt injection attacks that emerge after that point (which is most of them) are not even identified, let alone blocked. Just taking prompt injection attacks for a second — they can take basically infinite forms that you don’t really know… until you know, and they will never be fully prevented because they are an innate flaw of the probabilistic logic that powers all GenAI. That’s why setting up least privilege at the Kubernetes and infrastructure layer is so, so, so important — you can’t predict most prompt injections, but you can stop them from accessing your sensitive data or taking control of your applications. So, let’s talk about what can happen if they take over your critical infrastructure applications for a second…

Let’s use an example that I know well having grown up by the towering smoke stacks of India’s rapidly-evolving power revolution of the 1990s. Fast-forwarding to 2025, let’s say that a power grid is using a third party AI model to analyze huge quantities of data around power usage, optimizing input, output, and throughput in order to make sure that the power is optimally efficient and stays on without damaging equipment during a summer heatwave. The system has the ability to shut down the power flow, as well as to increase it, making the potential consequences of an attack or system breach life-threatening. In the past, the type of power usage analysis the system is doing would have been done by a team of human engineers (with varying results), but the promise of AI, and the reason the AI revolution is upon us, is because AI can produce such incredible results at a scale and complexity that humans simply can’t achieve. That said, the vulnerabilities of this system with an AI component are also potentially catastrophic. 

Let’s say that the system in this example is quite typical for how AI systems are built today, using Kubernetes on a private cloud instance (which feels more secure than hosting it in a public cloud, but still has its open attack paths). It is transferring huge amounts of live usage data both into its SIEM and into a containerized foundational model rooted in open source code, which is then connected to numerous APIs that enable it to analyze the data in multiple ways and take action based on logic input by the power grid’s engineering team as well as a centralized engineering team at the power company’s headquarters. This means that at every API connection and every data transfer, there is an opportunity for an attacker to enter the system. The number of people involved in creating the application’s rulesets also mean that human and non-human identities (NHIs) alike have a lot of privileged access, and there is no system in place to remove access after their contribution is completed. In fact, there isn’t even a system to see all the human and non-human identities that currently have access to the APIs, services, and data stores that are involved in the day-to-day functioning of the model or the application it powers. 

So, the application is functioning, the AI model is analyzing, all seems okay, until one day, one of the many open doors to this system creates a really, really big problem. It could be as simple as an attacker using an open API to enter the system (they could also piggy-back off of an AI API), they could use social engineering to trick an engineer into handing over credentials (a mode that is being enhanced by deep fakes), or they could be using AI to test infinite combinations of access keys until they stumble onto one of the many open doors left behind and unmonitored after the application’s initial creation. Getting more creative, a zero day prompt injection that was already embedded in the model’s open source code could emerge and move laterally, just like all of the other attack modes can, inside the Kubernetes environment to literally all of the unprotected applications, containers, and data stores, including the ones that have control of the power grid’s energy regulation systems. 

This is why having live, runtime protection that proactively enforces access controls,  blocks nefarious behaviors, and limits the ability of prompt injections to access anything critical, is absolutely essential for containing blast radius and preventing a very physical manifestation of the downsides of AI. Imagine how much damage could be done if an attacker broke into this system and the power company had to wait for a human red team to find the exploit and shut down the attack, while millions of people are without power, or while power equipment is damaged beyond repair by a surge caused by the hacker. This pattern of control loss could be repeated by any critical infrastructure entity that has controls connected in the backend to data and AI models, from dams controlling flood waters to GenAI-powered airport traffic controllers and container ship co-pilots. The implications here when we introduce agentic AI become even more disturbing, with the access controls and human fail-safes for AI agents being of the utmost importance. 

Security: How are new AI regulations impacting the threat landscape, especially in terms of critical infrastructure?

Bhavsar: I think it is yet to be seen exactly how regulations will affect the real world application of AI, in California and across the world. Taking a step back, we’ve seen that cybersecurity regulations such as PCI compliance and NY DFS in the FinTech industry alongside HIPAA in the healthcare industry do drive business and engineering decisions around securing private data. We’ve also seen that on the data side, despite being a European regulation, GDPR did have a substantial impact on global companies, and therefore, AI regulations passed in major locations where a lot of companies want to do business (including California or the EU AI Act) will likely have some impact on security and data governance priorities. 

That said, for regulations to be effective, they must be targeted at outcomes, and be measurable and enforceable in a real-world context, and therefore must be written with a deep knowledge of the actual threat landscape in mind. Regulations that do not take into consideration how AI actually works and what GenAI is being used for in a real-world context will likely fall short in providing actual protection for businesses and for any critical infrastructure that they are intended to protect. 

There is also a difference between “box-checking” for compliance purposes and actually reducing risk and preventing data breaches. The consequences of major breaches caused by AI-based attacks on cloud infrastructure, or introduced to a system through a GenAI application that is embedded in a larger cloud environment, go beyond what regulation can achieve. That is partly why we joined the board of CoSAI, (the Coalition for Secure AI), through which forward-thinking tech companies can come together and work on securing AI from inside the industry. Self-regulation may be the fastest path to Responsible AI adoption, and can also survive the ever-changing tides at the macro-political level.

Security: How can organizations approach these regulatory challenges to ensure efficiency and security?

Bhavsar: We strongly advocate that organizations — whether commercial businesses or stewards of critical infrastructure — focus on the actual protection of their systems against the egregious and unprecedented threat landscape that we are facing in 2025. When organizations gain better transparency into their entire cloud application stacks across every layer, including their AI APIs, model containers, and how their data is flowing in live applications, they are already able to achieve compliance goals for other regulated industries, like PCI compliance, faster. Introducing new capabilities, such as in-line auto-redaction of sensitive and PII data allows companies to innovate with AI while only transferring the minimum amount of data necessary for their AI applications to work, which already helps them meet their data privacy and data governance goals, whether or not those goals are regulated at a state or national level. But, more importantly, developing these capabilities, and enforcing least privilege access controls all the way down to the cloud-infrastructure/Kubernetes layer, are absolutely pivotal to protecting critical systems, including critical infrastructure, from the major attack vectors caused by the AI revolution. We know that this can be done easily today at scale, because that is what we’re doing every day.

Additionally, blocking attacks in the live application environment using secure-by-default architectures can be extremely effective at preventing costly and dangerous attacks. The world will never fully stop prompt injections, just like it will never be able to fully stop social engineering attacks (and deepfakes make that problem even worse). Yet, we can absolutely prevent those types of attacks from taking down our critical infrastructure, and we can stop them from gaining access to our sensitive and private data. We need to get out of the reactive mindset of waiting for attacks before remediating, or waiting for regulations before implementing preventative measures. Securing your AI proactively actually fuels AI innovation while protecting your systems and your end users, and that should be a greater business motivator than regulations alone could ever be.