September 22, 2026

After the rapid spread and adoption of AI agents we've experienced in the past 18 months, enterprise security teams see a day coming when they have to pull them back. Yet most of them have not built a way to do it without stopping the whole fleet, and the lever they do have does not reach the agents they are most worried about.

In our Agents of Change survey of 251 cybersecurity leaders, 79 percent expect their organization to claw back or significantly restrict AI agent usage within 18 months. Gartner predicts that 40 percent of enterprises will demote or decommission autonomous agents by 2027 because of governance gaps found only after production incidents. While both point in the same direction, our survey shows just how unprepared enterprises are to act. Decommissioning ranks last among the controls leaders plan to add before they scale, and fewer than half are very confident they can reliably disable an agent.

We ran this study because our customers in semiconductor design asked us to. Chip design is about as demanding an environment for agent governance as exists: the design IP is the value of the company, engineers adopt coding agents faster than security can track them, and each project has to be walled off from the next. TrendCandy, an independent research agency, fielded the survey double-blind. Ninety percent of respondents are director level or above, and 78 percent work at organizations of more than 1,000 employees. Industry was multi-select, with semiconductors at 70 percent, software at 51 percent, and financial services at 43 percent.

The leaders of the agentic charge are the ones who most expect a pullback

Expectation of a claw-back rises with fleet size. It stands at 72 percent among organizations that run 50 or fewer agents, 79 percent among those with 51 to 100, and 90 percent among those with more than 100. The organizations with the most agents in production are the most certain they will have to pull some of them back, which suggests the expectation comes from operating experience.

FLEET SIZES ARE MOVING UP

The reasons are governance failures. Shadow agents (56 percent) and data leakage (52 percent) lead the list, and token costs (26 percent) sit near the bottom. The correction leaders anticipate is about control, and cost barely registers.

The kill switch most enterprises have

For most enterprises, the only way to pull agents back is a fleet-wide off switch: revoke the corporate API key, disable the SSO integration, or block the LLM provider at the proxy. The first two act only on the sanctioned fleet, the agents that were provisioned properly and use the corporate path. The proxy block reaches more and still misses a local model, a personal API key, or a provider that is not on the list. A shadow agent running under an engineer's personal key does not notice any of it. Shadow agents are the top reason leaders expect to restrict, and they are the agents a credential-based switch cannot reach.

restriction_expectation3

Gartner's May 2026 note gets at the same problem from the governance side. It argues that enterprises treat agent governance as binary, either locked down or fully trusted, and that failing to separate an agent's ability to act from the scope of access it holds is the root cause of agent failure. IBM's 2026 breach report supplies the cost context. Security incidents involving shadow AI more than doubled year over year, to 43 percent, and more than two-thirds of breached organizations had no governance process in place to limit it.

An AI agent kill switch, as this post uses the term, is a control that can stop one agent, one agent type, or one project, whether or not the agent was set up through sanctioned channels, and that can be reversed once the specific problem is contained. A credential switch meets none of those conditions.

Expected, yet unprepared

The gap between expectation and preparation is wide. Decommissioning ranks last on both lists leaders were asked about, as a control to add before scaling and as an indicator of governance maturity, and only 42 percent are very confident their organization can reliably disable or claw back agents if it needs to. Two things explain the gap.

The first is ownership. Eighty-five percent of leaders report more agents than approved owners, and 81 percent say ownership disputes are actively delaying governance decisions. In most organizations the person who builds an agent is not the person who secures it. A restriction decision needs someone with the authority to make it and the context to make it narrowly. When the owner is unknown, or two teams claim the agent, the decision may wait for an incident to happen first.

The second is discovery. Shadow agents are the top restriction driver, yet agent discovery sits near the bottom of the controls leaders plan to add before scaling, at 27 percent. You cannot restrict an agent you have not found, and shadow agents are by definition the agents you have not found. A credential switch does not find them either.

The Five Eyes agencies' joint guidance on agentic AI, published in May, reaches the same requirements from the government side. It tells operators to roll back autonomy and access in response to failures, to establish trigger-action protocols that automatically restrict agent permissions when unexpected behavior emerges, and to deny access to any agent or key that is not present in the trusted registry. By that last standard, an unauthorized agent is rogue whether or not it has done anything anomalous yet.

What a selective restriction requires

Our report lays out three prerequisites for restriction that is selective rather than blunt: a complete inventory with named owners, an authorization baseline that records what each agent was permitted to do, and a decision path that can act without an ownership dispute. Zentera's view is that a fourth belongs on the list. The enforcement point has to sit outside the agent, and it cannot depend on the agent following the rules, such as using a sanctioned credential or path. A kill switch that only works on agents that were set up correctly is a kill switch for the wrong population.

The reason is in the survey. Eighty-four percent of leaders believe agents cross project boundaries more easily than employees. A control that lives in the agent's own configuration, harness, or system prompt shares the agent's failure modes, and killing a process restricts nothing if the agent, or a copy of it, can come back with the same reach. Restriction has to be enforced where reachability is decided, and it has to persist there.

It also has to be granular and reversible. A useful restriction stops one instance, one type or version, or one project, and leaves the rest of the fleet running; once the specific problem is contained, the fleet goes back to work. The Five Eyes guidance calls the constraint behind this a declarative safety contract, a boundary the agent cannot override. In practice that is declarative intent: an administrator declares the operating envelope from the agent's purpose, and enforcement does not require the agent's cooperation.

What this looks like in practice

A coding agent on an engineer's workstation, running under a personal API key, starts reading synthesis scripts from a design repository it was never assigned to and sending them to a cloud model. Revoking the corporate API key does nothing, because the agent does not use it. Blocking the provider at the proxy stops this agent and every sanctioned agent on the same provider, and does nothing about the next engineer who picks a different provider or a local model. A quarantine at the network boundary of that workstation stops this one agent from reaching the repository or the model, leaves the rest of the fleet running, survives a restart of the agent, and lifts when an administrator releases it.

This is the control Ensage AI provides. zLink detects AI agents at the process level on enrolled endpoints, including agents on personal keys and local inference runtimes. Reachability is decided in the enclave, a trust boundary that holds the agents, assets, and tools for one defined scope of work; an administrator defines what belongs in it, so an enclave can be a chip design program, a clinical trial, or a single repository. Resources outside an enclave are not reachable from inside it, and an agent with no enclave assignment reaches nothing until an administrator assigns it. Quarantine of a misbehaving instance is automatic and survives a restart. Restricting an agent type, version, or model across every enrolled endpoint is one policy change, applied to current and future instances regardless of the credential they use, and decommissioning a project is enclave removal.

Ensage governs agents on endpoints and servers that run zLink and sessions that pass through the AI Session Controller. An agent hosted entirely inside a SaaS vendor's cloud is outside that scope. Ensage AI entered early access in March 2026 and reached general availability in June; the enclave architecture underneath it has run in production at semiconductor and other IP-sensitive customers for years. The difference from a proxy or a credential control is architectural. A network proxy cannot see a process that never sends traffic through it, and a credential control cannot revoke a key it never issued. Process-level discovery on the endpoint sees both.

What to do next

The report's fifth recommendation is the one this post is about, and it applies with any tooling: prepare the restriction playbook now. Define in advance how a single agent, project, or path is suspended without a fleet-wide shutdown, who decides, and how the action is reversed. Four questions will tell you where you stand.

  • Can you name the owner of every agent in your environment?
  • Can you produce the authorization record for any one of them on request?
  • Can you detect and stop a shadow agent that never used your corporate key?
  • Can you stop one agent, one type, or one project without stopping the rest, and reverse it tomorrow?

agents_of_change_crIf the answer to the third question is no, you do not have a kill switch. The other four recommendations, the full findings, and the methodology are in the Agents of Change report.

Sources
Picture of Mike Ichiriu

Written by Mike Ichiriu

Mike Ichiriu is VP of Marketing and Product at Zentera Systems, where he leads product strategy for the company, including its Zero Trust and agentic AI security initiatives.
A Certified Cloud Security Professional (CCSP) and frequent speaker on enterprise security, Mike has 25+ years of experience across cybersecurity, networking silicon, and enterprise software, and holds 15 U.S. patents.