Mohan Veloo, Chief Technology Officer (CTO) for Asia Pacific, China and Japan, F5, said AI security has to move closer to the runtime, where the context of every prompt, API call and agent action can actually be policed, in an interview with TechObserver.in’s Mohd Ujaley. He also flagged a sharp shift in how enterprises are measuring AI infrastructure, with tokens per second, time-to-first-token, cost per token and tokens per watt rapidly displacing the GPU-led conversation that dominated boardrooms as recently as nine months ago.
“Static security will not work for this,” Veloo said, arguing that AI itself has to become part of the application architecture rather than a layer bolted on after the fact. He pointed to shadow AI accounts inside companies, “zombie APIs” still exposing production data and the difficulty of enforcing consistent policies across hybrid environments as the most pressing issues facing CIOs in regulated industries such as banking and healthcare.
Edited Excerpts:
Most enterprises today run a heterogeneous mix of public cloud, on-prem and increasingly edge with AI on top. Where does this fragmentation hurt the most: inconsistent security blind spots, lack of visibility across infrastructure, or something CIOs are underestimating?
Companies are running their applications across many environments. Earlier, the assumption was that everything would move to the public cloud and it would be a cloudy world, but that is not how it has turned out. There are several reasons, including digital sovereignty, which has become important given the geopolitical shifts around the world. A lot of companies we engage with are actually choosing to stay on-prem rather than move to the public cloud, and they are looking at different types of locations. Hybrid cloud is here to stay.
That comes with its own challenges. The real issue is not simply that there are more places to run applications. Each of these environments comes with its own tools, its own policies, its own controls and its own blind spots. But enterprises need a consistent way to operate and secure applications wherever they run.
With AI, this becomes even more important. AI brings its own set of challenges. It creates new application flows, new API directions and a lot of new data movement. So the question becomes: where do you place the right control points around all these applications, APIs and AI workloads as they scale and go into production? We work with a lot of companies in regulated industries like banking and healthcare, and they have specific requirements on where data sits, how data flows and what cross-data flows are permitted. All of that becomes critical.
When people say “AI security” they usually mean protecting the model. But the real attack surface is wider, covering prompt injection, data leakage, shadow AI and agentic AI acting on behalf of users. Which of these are causing real damage today, and which are still mostly talk?
Advertisement
When people think of AI security, they think of the model first, because the model has had the most news around it. But the model is actually only one part of the picture. Once AI is connected into enterprise systems and starts interacting with applications, data sources, APIs, workflows, identity systems and business applications, that is where the real risk shows up.
You now have people entering prompts that carry sensitive data. APIs and agents are being called by AI-driven systems, and those systems are feeding outputs into business decisions or into more agents, which then take actions on behalf of users. The traditional security stack that companies have spent millions of dollars on was not designed for this kind of environment. The risks are different. There are prompt injections, where if you are smart enough you can craft a prompt to extract what the system is not supposed to disclose, for instance, what is the CEO’s salary.
One of the bigger issues for companies right now is data leakage. Almost everyone in every company has their own personal AI account and is using it on the side. The company may not have told them: “Don’t put your meeting minutes in there to summarise.” Most people would. But some of that material may be very critical, financial information, internal data. Shadow AI, as it is being called, has become a very big issue. People are using their own external AI tools, and at twenty dollars a month it is not expensive, and the data can do a lot for you.
The real problem is that companies are moving fast on AI adoption without putting governance in place first. They are pushing AI into production before they have full visibility into how these systems are connected and how they are being used. At F5 we believe security has to move closer to the AI runtime. You need to figure out the context, what is being sent to the model, what is coming back, which APIs are being called, what data and applications are being accessed and whether that behaviour is allowed. Static security will not work for this. Security needs to move to runtime, it needs to understand context before it is applied, and AI itself needs to become part of the application architecture and the controls around it.
APIs now carry the bulk of internet traffic, yet most companies cannot even produce a complete inventory of the APIs running inside their own environment. Why is this such a hard problem to fix, and what is it costing them?
At F5 we have solutions that go and search for what we call zombie APIs. APIs are very easy to create now. With Claude, or even by myself, anyone can create an API. What typically happens is that developers create APIs to test something out and then forget about them. They forget to close them. Those zombie APIs are left lying around, and sometimes they are still giving access to production data. There have been several public cases. The Optus breach in Australia is one I can mention, where a forgotten zombie API effectively brought down the network.
What is interesting is that when we speak to CIOs, application CTOs and the teams managing applications, they say: “We are fine, everything goes through the API gateway, I know all my APIs.” But in reality the APIs do not all go through the gateway. They are lying around, and when we run a scan they fall off their chair. We show them: you said you had 500 APIs, but actually there are 1,500. That is more common than people think.
With AI, this becomes an exponential problem, because agents themselves create APIs to connect to systems. So you need a kind of API cleansing exercise. There are solutions in the market that can scan your applications and environments and confirm whether what is in your inventory is what is actually exposed. F5 has API discovery capabilities that can scan, secure or shut these APIs down.
Most enterprises are spending heavily on GPUs and models, but the real operational work of AI, things like rate limiting, traffic management, endpoint protection and cost-per-query, sits in the data path. How should CIOs think about this plumbing layer, and what are early AI deployments getting wrong?
This is a conversation we keep having with customers. Initially, when the AI wave first hit, and “initially” could mean as recently as nine months ago, everyone was focused on GPUs. Customers wanted the latest GPU, the G1, the 200s, the 300s. The conversation was always: “I want this GPU.”
What we are seeing now is people looking at a different kind of economics. The metric is shifting to tokens per second. Instead of selling the GPU, you are increasingly selling tokens, because tokens are how AI is ultimately measured and costed. Then there is time-to-first-token, which is critical because it determines user experience, how quickly the system starts responding. There is cost per token, end-to-end latency and tokens per watt, which brings energy efficiency into the picture. Performance and energy both matter. These are the metrics that are starting to percolate through, and we see customers moving from a product-based GPU model towards a more tokenised economic model.
The industry is consolidating heavily, with API security, bot management, WAF and DDoS all being bundled into single platforms. Is this real value for the customer, or are vendors mostly jumbling products together?
It is a genuine value for the customer. As I mentioned at the start of our conversation, you have multiple environments to handle and a different set of tools for each. And do not underestimate this: a typical enterprise will have somewhere between 50 and 60 security tools. That means you need 50 people trained on those tools. They need to know how to write the policies and how to configure each one. It is impossible. And once you train someone, they leave. In some markets, people will move on for a 5% or 10% raise. It becomes very hard to manage.
As you consolidate into platforms, deployment becomes easier and management becomes faster. When management is easier, the number of security holes shrinks because policies can be applied consistently. At F5, because we have an Application Delivery and Security Platform that works across public cloud, private cloud, on-prem and edge networks, we can push a single policy across all those environments. If you do not have that platform, you have to go and configure each environment separately, and you will eventually make a mistake. So yes, what we are seeing in the industry is a consolidation into platforms, and I think it is the right direction. It makes deployment easier for customers and brings the overall return on investment (ROI) down.







