As AI agents gain greater access to enterprise systems, data and infrastructure, organisations face growing challenges in managing identity, permissions, accountability and unauthorised activity. In an interaction with Enterprise Times, Rahul Sood, GM, Application Security, Harness, explores why traditional security approaches are insufficient for autonomous AI agents and outlines the governance measures enterprises need to scale them safely.
Enterprise Times: Are AI agents becoming privileged digital workers, and are enterprises giving them the right level of oversight and controls?
Rahul Sood: AI agents are increasingly operating like privileged users inside enterprise environments. They can read code, call APIs, access data, interact with infrastructure and take actions across multiple systems. And they aren’t limited to the ones a development team builds in-house – any employee who purchases a SaaS tool or connects a new service can introduce an agent with its own access into the environment. What makes them different from traditional software is that they can decide which tools to use and what steps to take based on the context they receive at runtime.
The security model needs to reflect that. An agent’s identity should be separate from the developer or service that created it, its permissions should be tied to the specific work it is expected to perform, and its actions should leave a record that can be reviewed after the fact. A coding agent that needs to inspect a repository, for example, should not automatically have the ability to deploy a change to production.
The level of control should also follow the consequence of the action. Reading documentation and changing production infrastructure should not carry the same approval requirements. The harder an action is to reverse, the stronger the controls around it should be.
Enterprises also need a reliable record of what an agent did and why: its identity, the tools it used, the context it received, and the changes it made. Without that, investigating an incident after the fact becomes guesswork.
This is where enterprise oversight still needs to mature. We have spent years building identity and access models around people and relatively predictable software. Agents introduce actors that can make decisions at runtime, so identity, permissions, evidence, and oversight now have to account for that autonomy.
Enterprise Times: What security and governance measures should enterprises have in place before deploying AI agents at scale?
Rahul Sood: The starting point has to be concrete, because the oversight model I described a moment ago can’t exist for an agent an organisation doesn’t know is running. So the first step is understanding which agents, MCP servers and models are active in the environment, and what systems they are connected to. 41% of organisations are confidently declaring “no shadow AI” with nothing in place to verify it, which means the foundation the rest of this is built on is often missing.
From there, security has to work at two points in an agent’s life. Before deployment, the prompts, skills, and models used to build an agent need to be scanned the same way code gets scanned – catching injected instructions, leaked credentials, or unsafe tool references before they ship. This is also where “permissions tied to the specific work it’s expected to perform” gets decided: you can’t scope an agent’s access correctly if you don’t know what it was actually built to do.
Once an agent is running in production, the controls change shape. You need defenses that hold regardless of whether the agent was built in-house or bought – blocking prompt injection and data exfiltration attempts in real time, the way a firewall protects a web application, backed by testing that actively probes for those weaknesses rather than waiting to find them in an incident report.
The mistake enterprises make is treating a written AI policy as equivalent to having controls at both of those points. A policy doesn’t scan a prompt and it doesn’t block an exfiltration attempt as it happens.
Enterprise Times: Who should be accountable when an autonomous AI agent makes an unauthorised or harmful decision?
Rahul Sood: Autonomy does not transfer accountability from the organisation to the agent. Catching the action is a separate problem from owning it, but once it’s caught, an agent may decide how to complete a task, the enterprise still decides where it can operate, what it can access and how much authority it receives.
That makes ownership particularly important. Every production agent should have an identifiable owner responsible for its permissions and operating boundaries, just as enterprises already assign ownership to applications, services and infrastructure. The exact owner may differ depending on the use case, but responsibility cannot become ambiguous simply because an AI system was involved.
There is also a broader design issue here. If an agent can make a consequential change without any independent control, the problem is not only the decision the agent made. The organisation has created a system in which one component can effectively initiate, execute and validate its own actions.
For higher-risk workflows, those responsibilities need to be separated. An agent might propose or execute a change, while policy controls, another specialised system or a human validates it before it progresses. The more consequential the action, the more important that separation becomes.
Accountability therefore comes from being able to establish ownership, authority and a reliable record of how a decision was made.
Enterprise Times: What can enterprises do today to safely scale AI agents while managing the risks of shadow AI and unauthorised agent activity?
Rahul Sood: Shadow AI becomes difficult to control when adopting an agent is much easier than discovering and governing it. A developer can connect a new model, install an MCP server or give an agent access to another tool very quickly. And the path doesn’t require a developer at all: any employee who buys or signs up for a SaaS tool can introduce an agent with its own access to company systems. In a large organisation, those small decisions can create an agent footprint that changes much faster than a traditional software inventory.
Enterprises need continuous visibility into that environment. They should be able to identify which agents are operating, the models and tools they connect to, the permissions they hold and whether those connections have been approved.
Part of the challenge is that most discovery approaches only see what they are set up to find. Tooling integrated into the development pipeline may identify agents built by your own developers, but miss those purchased by the company or embedded in third-party tools that employees connect to internal systems. Real inventory has to cover both: the agents you built and the agents you brought in. That gap is measurable: 41% of organisations confidently report having no shadow AI, with no tooling in place to verify it.
But visibility alone will not solve shadow AI. Organisations also need to give developers a practical, sanctioned way to experiment. If the approved route is significantly slower than installing a tool independently, people will find ways around it. The better approach is to make experimentation easy within controlled environments and introduce stronger restrictions as an agent gets closer to sensitive data or production systems.
There also needs to be a clear distinction between discovering an agent and trusting it. Simply appearing inside the environment should never be enough to inherit access. Trust should be explicit, scoped and revocable as the agent’s role changes.
Enterprise Times: In your recent Agent DLC report, it states that while 76% of enterprises believe they can disable a misbehaving AI agent within 15 minutes, only 33% actually have an instant kill switch. What does this gap tell us about enterprise readiness for AI agents?
Rahul Sood: The interesting part of that finding is the difference between having an incident-response process and being able to stop an autonomous system immediately.
Most enterprises already know how to respond when software fails. They can roll back a deployment, revoke credentials, disable a service or involve an incident-response team. Those responses only start once someone has detected that something is wrong – the controls covered earlier are what make that possible. Those mechanisms still matter, but an agent introduces a different problem because it may continue calling tools and taking actions while the team is working out what went wrong.
That is why the gap between 76% believing they can disable or roll back an agent within 15 minutes and 33% having an instant kill switch matters. It suggests that many organisations are applying existing operational processes to a system that can act much faster than those processes were designed for.
A kill switch is also only useful if it has been tested. Organisations need to know whether stopping an agent actually terminates its sessions, credentials, delegated permissions and downstream activity.
As agents receive greater autonomy, containment becomes part of the architecture rather than simply an incident-response procedure. Enterprises should test their ability to stop an agent with the same seriousness that they test recovery from other critical failures.
Enterprise Times: Looking ahead, as AI agents become more autonomous, what should enterprises do today to ensure they can scale them safely and responsibly?
Rahul Sood: The mistake would be to assume that greater capability should automatically come with greater authority. An agent becoming better at reasoning or completing complex tasks does not mean it needs unrestricted access to the systems around it.
Enterprises should design for different levels of autonomy. An agent gathering information or analysing code can operate with relatively limited controls because the consequences are small and usually reversible. An agent modifying infrastructure, accessing sensitive information or making a production change needs a very different level of oversight.
That distinction will become more important as agents start working with other agents and dynamically choosing tools. Security teams will not always be able to predict every sequence of actions in advance. They will need controls that remain effective while the agent is running: scoped permissions, policy enforcement, monitoring, evaluation and the ability to withdraw authority quickly.
We also need to think beyond securing the model itself. An agent operates through APIs, tools, identities and data. Its security ultimately depends on that entire chain.
The goal should not be to restrict autonomy for its own sake. It should be to make sure the authority given to an agent never grows faster than the organisation’s ability to observe, control and contain it.
