The idea of a “kill switch” for AI agents is a popular talking point in cybersecurity. It sounds reassuring: if an AI agent misbehaves, goes rogue, or gets compromised, you simply shut it down. Problem solved. But this framing is incomplete in a way that should concern security leaders. A kill switch is not a strategy. It is a last resort, and if organizations are relying on it as a primary control, they are already operating from a position of weakness. The growing focus on kill switches is less about control and more about what is missing underneath. What it really exposes is a deeper issue that security teams have been struggling with for years and can no longer ignore: identity.
AI agents are not tools. They are actors.
For most of the past two decades, enterprise security has been built around a relatively stable assumption that software does not act unless a human tells it to. Applications store data, process inputs, and execute commands, but they do not initiate behavior on their own. AI agents fundamentally change that model. They are not passive tools. They log into systems, retrieve data, trigger workflows, and increasingly make decisions on behalf of users. In many organizations, they are being embedded directly into operational processes with access to core systems like email, CRM platforms, finance tools, and internal knowledge bases. This shift turns software into something closer to an actor inside the environment, which in turn changes the nature of risk from something static to something continuous and active.
The illusion of control
In that context, the instinct to build a kill switch is understandable. If an autonomous system is capable of taking unintended or harmful actions, there needs to be a way to stop it quickly. But the existence of a kill switch does not mean the system is under control. In fact, it often signals the opposite. By the time an organization needs to “pull the plug,” the agent has already accessed systems, used its permissions, and potentially caused damage. The kill switch may limit further impact, but it does not address why the agent had that level of access or why its behavior was not constrained earlier. It is a reactive mechanism applied after the fact, not a preventive control.
Identity has always been the problem
To understand why this matters, it is important to look at where security risk has already been trending. Identity has quietly become the dominant attack surface in enterprise environments. As Carey Frey, Chief Security Officer at TELUS, explains, “over 80% of the breaches are happening because of identities that are being compromised.” Attackers have shifted away from complex malware and toward simpler, more effective methods that involve stealing credentials and operating within legitimate systems. This approach, often described as “living off the land,” allows attackers to blend in with normal activity while using existing permissions to move laterally and access sensitive data. It is cheaper, faster, and harder to detect than traditional attack methods.
Agents amplify identity risk
AI agents amplify this existing problem in a significant way. They are, in effect, non-human identities that are granted access and authority to act. They inherit permissions from the systems they interact with, and they are often given delegated authority to perform tasks on behalf of users. However, unlike traditional service accounts or applications, they do not behave in strictly predictable ways. They can reason, adapt, and chain together multiple actions across systems. When organizations deploy these agents without a clear identity framework, they are introducing entities that have both access and autonomy but lack the governance structures required to manage them safely. As Frey notes, if this foundation is not addressed, “you can just imagine the great success that the threat actor community is going to have if it gets control of agents with agency.”
The attribution problem
One of the most immediate consequences of this gap is the loss of clear attribution. When an agent performs an action, it becomes difficult to determine whether that action was initiated by a human or by the system itself. Frey raises this challenge directly: “how are we going to know the difference between what Carey the human was doing or what Carey’s agent was doing?” Without distinct identities and proper tracking, audit logs lose their reliability, investigations become ambiguous, and accountability is undermined. This is not just a technical inconvenience. It has direct implications for incident response, compliance, and trust in the system as a whole.
The visibility gap
Compounding this issue is a lack of visibility into how widely AI agents are already being deployed. In many organizations, adoption is happening in a decentralized way. Developers are experimenting, business units are integrating agents into workflows, and new capabilities are being rolled out without centralized oversight. This creates a form of sprawl that is reminiscent of early SaaS adoption, where hundreds of applications were introduced without security teams having a clear understanding of what existed or how it was being used. The difference now is that these agents are not just storing or processing data. They are acting on it. As Frey points out, if organizations are not even aware of the agents being created, “that’s going to be a problem… because you can’t protect what you can’t see.”
Identity security is the answer
Despite this, much of the current conversation around AI security remains focused on models. There is significant attention on improving alignment, preventing prompt injection, and building stronger guardrails. While these efforts are important, they do not address the core issue. Even a well-aligned model can cause harm if it is given excessive permissions or operates without proper constraints. The real control point is not the model itself but the identity through which it interacts with the rest of the environment. Agents need to have distinct, verifiable identities, clearly defined permissions, and enforceable access controls. They must operate within a framework where they can prove who they are and what they are authorized to do. As Frey explains, “these agents will have to prove that they are the legitimate agent with the legitimate identity and access that has been prescribed to it.”
From kill switch to control plane
This is where the concept of a kill switch begins to make more sense, but in a different light. What organizations are really asking for is not a single button to shut down an agent, but the ability to revoke access, contain activity, and enforce boundaries in real time. These are identity and access management functions. When properly implemented, they provide the same outcome as a kill switch, but in a way that is integrated into the system rather than bolted on as an emergency measure. In that sense, the kill switch is not a standalone solution but a byproduct of having a mature identity control plane.
A turning point in security
The urgency around this issue is growing, in part because organizations are moving quickly to adopt AI capabilities. There is competitive pressure to deploy agents, automate workflows, and realize efficiency gains. But this speed introduces risk. Frey expresses concern that the industry may “go too fast and deploy too many things… in that race to win the market.” This pattern is familiar. New technologies are adopted rapidly, security lags behind, and vulnerabilities emerge over time. The difference with AI agents is that the potential impact is more immediate because these systems are not just exposing data but actively interacting with it.
The industry now faces a choice. Organizations can continue to build on top of fragmented and underdeveloped identity systems, accepting the increased risk that comes with it. Or they can take this moment as an opportunity to strengthen identity as the foundation of security for both human and non-human actors. Frey describes this as an inflection point, noting that “we can choose to fix some of the legacy identity infrastructure that AI will crumble on… or… reap the consequences.” The path forward is not necessarily simple, but it is clear.
The bottom line
A kill switch may provide a sense of reassurance, but it does not solve the underlying problem. It is a reactive measure that assumes failure has already occurred. The real challenge for security leaders is to ensure that their systems are designed in a way that makes such measures unnecessary in the first place. That means establishing clear identity frameworks, enforcing least privilege, maintaining visibility into agent activity, and building the ability to control access dynamically. The question is not whether organizations can shut down an AI agent when something goes wrong. It is whether they have enough control over those agents to prevent things from going wrong at all.