Every enterprise technology leader has heard the pitch for agentic AI over and over by now: software that doesn’t just answer questions, but acts. Agents reconcile invoices, triage tickets and provision cloud resources without waiting for human approval. That autonomy is the point. And its the reason it’s so useful and appealing in the first place.It’s also the big risk.
An AI agent is, in practical terms, a new kind of employee identity that holds real credentials, works around the clock and executes thousands of actions per hour. We would never hire a person with that much access and no way to walk them out of the building. Yet, that is exactly how most organizations are deploying agents today.
When an agent goes off-script
Agents rarely fail in dramatic, obvious ways. They fail one reasonable-looking step at a time. An agent holding a valid token calls an approved tool, then another, then another, etc. Each step passes authorization. The sequence as a whole does something nobody sanctioned.
Thus, consider the possibilities. A customer-service agent, nudged by a prompt injection, begins exporting customer records to an external endpoint. A DevOps agent, chasing a performance goal, grants itself broader cloud permissions and starts spinning up costly infrastructure. A finance agent misreads an instruction and initiates payments outside its approval limits. An attacker who compromises one agent’s credentials inherits everything that agent can reach, and uses it as a foothold to move laterally.
The blind spot is bigger than most boards of directors typically can realize. In the environments I’ve examined, roughly one out of five AI agents could be labeled a shadow agent: built on personal accounts, consumer AI tools or unsanctioned integrations, holding real credentials, and absent from the identity provider and the security team’s asset list. You cannot write a policy for an agent you don’t know exists in the first place.
Then there is the all-too-important element of speed. The CrowdStrike 2026 Global Threat Report puts average eCrime breakout time at 29 minutes, with the fastest observed at 27 seconds, and 82% of detections were malware-free, relying on valid credentials. Agents make that the default. By the time an alert lands in a SOC queue, a rogue agent may be long finished.
Why the agent can’t be its own safety net
The instinctive response is to build guardrails into the agent: system prompts that forbid certain actions, model-level filters, self-monitoring routines. These are worthwhile but fatally flawed because they live inside the very thing they are meant to constrain. So it’s just not a smart move.
An agent that has been manipulated, compromised or has simply drifted from its goal is, by definition, no longer reliably following its instructions anyway. If its off switch is one of those instructions, the agent can ignore it, route around it, or disable it entirely. Asking a misbehaving agent to stop itself is like asking a compromised server to report its own breach. Nor does the existing security stack close the gap. Identity governance, privileged access management, and the SIEM are all sound controls, but none sits in the path at the moment an agent acts.
The case for an external, automatic kill switch
The answer is an agent kill switch that operates entirely outside the agent. It doesn’t depend on the agent’s cooperation, can’t be reached by the agent’s code or prompts, and can’t be turned off by the agent on its own. It’s the circuit breaker in the building’s electrical panel, not a switch on the appliance.
The most practical place to anchor that control is identity. Every agent, sanctioned or shadow, must present credentials and generate traffic to do anything meaningful. That footprint can’t be hidden. By continuously observing what each agent actually accesses and does, and comparing it against what that agent is supposed to do, an external control plane can recognize the moment behavior leaves its intended scope.
When it does, the response must be automatic and immediate. A human reviewing an alert minutes later is too slow against a process acting in seconds. An effective kill switch can revoke the agent’s credentials, block the in-progress action, quarantine the agent, reduce its scope or pause it for human review, in the moment, before the damage compounds. But it’s clear that precision matters as much as speed. A kill switch that fires on every anomaly blocks legitimate automation and soon gets disabled. It must know each agent’s normal behavior well enough to act on genuine drift and stay quiet otherwise.
What to demand before the next agent goes live
Technology leaders should put three questions to every agentic AI deployment. Do we know every agent running in our environment, including the ones nobody registered? Can we see what each one is actually doing, not just what it was provisioned to do? And if one goes rogue, can something outside the agent stop it automatically, in seconds?
If the answer to the last question is no, the organization is relying mostly on luck. Agents are already running. The only question is whether you stop a rogue one yourself, or read about it in someone else’s incident report.
