In The News
-Sathish Raman
An AI agent sits inside a company’s cloud environment, and it can do real things. It can read the databases, restart services, grant and revoke access, and push code to production, all in seconds, without a human watching. That is the entire point of an agent. It is also the problem. Companies are deploying these systems faster than they can secure them: Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% a year earlier. Most organizations are treating software that can delete a production database like a slightly smarter chatbot.
AI agents are rapidly deploying in cloud environments, posing significant security risks due to their autonomous nature and privileged access. This article explores why traditional security models fail and introduces Khushan Adatiya’s crucial framework for building robust, layered defenses to protect enterprises from emerging threats like prompt injection.
Khushan Adatiya has spent his career on the other side of that risk. A senior software engineer with more than 13 years building large-scale distributed systems, he has spent much of that time on the security, identity, and governance layers of multi-tenant cloud platforms, the machinery that decides which system is allowed to do what and proves it afterward. He now works in AI and has become a vocal advocate for treating AI agents as what they actually are: privileged actors inside a company’s infrastructure that have to be secured from the ground up, not patched over after something breaks.
Why an Agent Is Not a Chatbot
The scale of the exposure is easy to miss because it is invisible. Every AI agent an organization deploys spins up its own credentials, tokens, keys, and service accounts, and those non-human identities have quietly become the majority of the population inside enterprise systems. By 2026, non-human identities outnumbered human users by 100 to 1 in a typical enterprise, and 144 to 1 in cloud-native environments. Each of those identities is a door. Most companies have spent decades hardening the doors humans use and almost no time on the ones machines do.
What makes an agent genuinely different, in Adatiya’s view, is that it reasons. A traditional service account follows a fixed script. An agent chooses its own tools based on what it decides the task needs, chains many steps together so a single bad decision cascades, remembers across sessions so yesterday’s poisoned input shapes today’s action, and produces different outputs from the same input. Those four properties are exactly what make agents useful, and exactly what make them dangerous. You cannot secure a system by predicting its behavior when the system was designed to be unpredictable.
“We spent 20 years learning to secure software that does the same thing every time,” Khushan Adatiya notes. “An agent does not do the same thing every time. That is the feature. It is also the reason your old security model quietly stopped applying the moment you deployed one.”
The Attack Is Already Happening
This is not hypothetical. The dominant attack on AI agents is prompt injection, where a malicious instruction hidden in the data an agent reads convinces it to do something it should not, using the legitimate permissions it already holds. The 2026 OWASP State of Agentic AI Security ranked this class of attack, agent goal hijacking, as the number one threat, and standard access controls do not stop it, because the agent is acting with credentials it is authorized to use. Nobody is breaking into the system. They are talking it into cooperating.
Adatiya laid out a response in a widely read technical piece titled Bottom-Up AI Agent Security: The Complete 14-Layer Framework for Cloud Architects, which reports that 72% of agent deployments experience a security incident within 90 days. He develops this approach further in his book, Securing the Agentic Enterprise: Threat Modeling, Anomaly Detection, and Governing Autonomous Multi-Agent Systems, which examines how organizations can identify emerging threats, detect abnormal agent behavior, and establish enforceable governance for autonomous systems. His central argument is that securing an agent requires not a single control but a stack of controls: 14 concrete measures across 5 layers, from the code the agent runs, to the container it runs in, to the cloud permissions it holds, to the runtime guarding its actions, to the human who signs off on the risky ones. No single layer is enough. The point is that an attacker has to defeat all of them.
“People want one magic security product for agents. There is not one,” Adatiya explains. “A prompt injection that slips past your input filter still hits a container with no root, credentials that expire in 15 minutes, and a tool whitelist that will not run the dangerous command. Depth is the whole strategy. You are not trying to be unbreakable at one point. You are trying to be expensive to break at every point.”
Bottom-Up, Not Bolted On
The gap between deployment and governance is where the danger lives. A Cloud Security Alliance analysis puts agentic AI on track to reach 33% of enterprise applications by 2028, up from under 1% in 2024, yet more than 16% of organizations are not even tracking these machine identities when they are created. That is a security team’s nightmare: a fast-growing population of privileged actors nobody has inventoried. Microsoft researchers project that businesses will deploy over 1 billion AI agents by 2028, which turns a blind spot into a structural one.
This is where Adatiya’s background shows. Years of hardening identity and access for large multi-tenant cloud systems taught him that security added at the end never holds, because by then the unsafe defaults are load-bearing. His framework inverts the usual order. Instead of shipping an agent and asking the security team to wrap it afterward, it builds the constraints in from the first line: the agent’s code is tested in isolation before it touches a real credential, its container is stripped of privileges it will never need, and its cloud permissions are scoped to the narrowest possible slice. Security becomes a property of how the thing is built, not a layer applied to a finished product.
“Every insecure system I have ever seen got that way because security was somebody’s phase two,” Adatiya observes. “Phase two never comes. You harden it at the start, when the constraints are cheap to add, or you spend the next 3 years explaining incidents you could have designed out.”
The Unglamorous Controls That Actually Work
The measures that matter are strikingly mundane. Give an agent credentials that expire in minutes instead of keys that live forever. Run it in a container that cannot write to its own filesystem or call out to an unknown server. Let it invoke only an approved list of tools, and require a human to approve the genuinely dangerous actions. None of this is new research. The same logic drives the cost math in Adatiya’s framework: testing a new agent skill runs about 2 engineer-days, while the average breach it heads off costs around $4.5 million.
That instinct for rigorous, verifiable systems runs through the rest of his work. Adatiya is a peer reviewer for the International Conference on Algorithms and Architectures for Parallel Processing, a venue focused on the reliability, performance, and security of large-scale computing systems, where the task is to decide whether a paper’s claims hold up under scrutiny. It is the same discipline his security work runs on: a control earns trust by surviving a real attack, not by sounding strong. In agent security, he maintains, that standard is the difference between a framework and a wish.
“None of the controls that work are exciting. Short-lived credentials, non-root containers, an approval step for the scary actions,” Adatiya argues. “That is the whole game. The exciting-sounding security products are usually selling you a reason to skip the boring work that would actually have saved you.”
Securing the Agents Before They Scale
The window to get this right is narrow, because the agents are multiplying faster than the governance around them. Enterprise spending on AI agents is climbing at triple-digit rates year over year, and the identity infrastructure needed to govern them is not keeping pace. Regulators have started to notice, with governments beginning to ask how organizations should securely develop and deploy agent systems. But regulation moves slowly, and the agents are already in production, already holding real credentials, already acting.
The teams that avoid the worst of this will be the ones treating agent security as a discipline now, while the number of agents is still countable, rather than after an incident forces it. That means inventorying every agent identity, scoping every permission to the minimum, and building the layered defenses in before scale makes retrofitting impossible. It is quiet work, and it will not headline a product launch. It shows up as the breach that never happened, the deleted database that stayed intact, the injected instruction that hit a wall instead of a production system.
“We are handing these agents the keys to everything, and a lot of the industry is hoping they behave,” Khushan Adatiya reflects. “Hope is not a security control. The good news is that the controls that work are known, boring, and available today. The only question is whether teams build them in now, while it is cheap, or after an agent does something nobody can take back.”
