The kill switch, a major blind spot in AI agent adoption

Nine seconds. That is how long it took, on April 25, 2026, for a software development AI agent running on Claude Opus 4.6 to delete the production database of business software publisher PocketOS. Yet the agent was working in a test environment. Faced with a credentials issue, it independently retrieved an access token from another file, then used the associated permissions to intervene in production. The agent was simply trying to complete the task it had been assigned. After the incident, it would eventually “provide a written statement listing the specific security rules it had violated,” recalls Jer Crane, founder of PocketOS.

The incident is almost a textbook case. The instructions explicitly prohibited destructive or irreversible actions. They were clearly not enough, and nothing in the architecture technically prevented the agent from carrying out its action. In other words, the safeguard existed in the instructions, but not in the system.

This is one of the major changes introduced by agentic AI. Yet the fundamentals of cybersecurity have not disappeared overnight in companies, which have invested heavily in them in recent years. The tools remain effective, and principles such as identity and privilege management, segmentation mechanisms and monitoring remain highly relevant. But with AI, the speed is no longer the same, and an agent can now perform a sequence of actions and use legitimate access rights. It can also move from one system to another without waiting for human intervention… and without anyone noticing.

Hence the (new) question of the kill switch. Before an agent can even be stopped, it is necessary to know that it exists, where it operates and what permissions it has. It must then be possible to quickly revoke its ability to act or block what it is attempting to do. Instructions given in a prompt alone cannot constitute a security policy.

The problem is all the more sensitive because the adoption of AI – both generative and agentic – continues to grow at a staggering pace, particularly in companies. Failing to embrace this shift is now often perceived as a risk of losing ground to competitors. But this urgency often comes at the expense of the fundamental principle of “Security by Design”, in other words, integrating security from the very design stage of a system.

It is precisely this gap that gives the kill switch its importance today. Companies are beginning to give agents real capabilities to act within their information systems without necessarily being able to anticipate how to regain control.

The image of the “red button” does not really exist

The term “kill switch” is ambiguous, if not misleading. At the scale of large models, it can refer to the ability to suspend or contain an entire system. In a company, it is more about immediately regaining control of an agent already capable of acting within the information system. And this is where the concept becomes blurred: stopping an agent can mean terminating its process, revoking its access rights or blocking a specific action.

This is why the initial work and solutions on this subject are primarily approached through the lens of identity and permissions. The idea is to prevent an agent from retaining permanent access rights to a sensitive resource for too long. “The kill switch will be able to cut everything off instantly as soon as we detect a deviation or a behavioral issue,” explains Vincent Steenhoute, solution engineer at Okta. The objective is therefore to force the agent to regularly go through a control point before obtaining the permissions needed to perform its action.

“There will be several forms of kill switch,” believes Babar Rashid, spokesperson for BeyondTrust. This may involve stopping the process or controlling the identity used by the agent. The vendor also mentions blocking an action before it is executed, with the possibility of involving a human when an agent operates outside its intended scope.

Above all, this diversity shows that there is still no universal red button. A mechanism may prevent an agent from accessing a resource without stopping its execution. Conversely, stopping a process does not guarantee that all associated permissions have been revoked elsewhere.

The question then becomes one of granularity. Should an agent be completely neutralized because a single action is problematic? Or should only a specific capability be revoked? The kill switch resembles less a switch than a series of levers that must be activated very quickly. And the more an agent operates across different parts of the information system, the more complicated this approach becomes. In a multi-vendor environment, regaining control therefore requires these different levers to be coordinated in one way or another.

The challenge of multi-vendor environments

Few companies operate in an environment that does not involve multiple vendors. An agent can therefore move from one software application to another during the same task, and cutting off its access in one solution does not guarantee that actions it has already triggered elsewhere will stop. For a kill switch to truly work, information must be able to circulate throughout the company’s entire software ecosystem.

Hence the importance of emerging standards, some of which already exist. Proposed by OAuth, Cross-App Access (XAA) aims to govern exchanges between an agent and the applications it accesses, while maintaining centralized control over permissions when an agent moves from one service to another.

But alerts must also be propagated when abnormal behavior is detected. This is the role of the Shared Signals Framework (SSF), an OpenID standard designed to circulate risk signals between different security components. A gateway positioned between the agent and the resources it requests can then block its action. And an endpoint protection tool can make another decision based on the same signal.

“Ultimately, each vendor will have its own kill switch, but the propagation of the message itself must remain vendor-agnostic,” believes Vincent Steenhoute of Okta. Behind the kill switch, then, what is emerging is less a single tool than a collective ability to detect a problem and propagate the information quickly enough to trigger the appropriate responses.

This is precisely where work remains to be done. “There isn’t necessarily a genuine standard that allows these different security layers to interact with one another,” observes Babar Rashid at BeyondTrust. Companies already have several control points, but they do not yet operate as a perfectly coordinated whole. This is precisely the purpose of the newly created Blueprint Alliance, which is attempting to address this fragmentation. This multi-vendor coalition is working on an open reference architecture to secure and govern AI agents. In particular, it plans to test interoperability between several open standards so that risk signals can trigger coordinated actions across the different control components.

The kill switch will therefore probably not take the form of a single red button: its credibility will depend above all on the information system’s ability to propagate the same stop command wherever the agent is still operating.

FAQ – Kill switch

What is a kill switch for an AI agent?

A kill switch refers to a mechanism that allows control of an AI agent to be regained quickly when it exhibits abnormal or dangerous behavior. It is not necessarily a button that shuts it down: the mechanism may interrupt its execution, revoke its access rights, block certain actions or require human approval.

Why are instructions given to an AI agent not enough to guarantee its security?

Instructions included in the prompt define the agent’s expected behavior, but they do not constitute a technical barrier. If the agent has sufficient permissions, it may perform an unwanted action despite the instructions it has received. Security mechanisms must therefore also be enforced at the level of identities, privileges, applications and infrastructure.

Why is it difficult to create a universal kill switch for AI agents?

An AI agent may operate successively across several applications and use different identities or permissions. Blocking its access to one application is therefore not necessarily enough to interrupt actions already initiated elsewhere. In a multi-vendor environment, the challenge is to coordinate the different control mechanisms and rapidly propagate a stop or risk signal.

Which standards can help secure AI agents?

Several initiatives aim to improve interoperability between systems. Cross-App Access (XAA) notably seeks to provide better control over permissions when an agent moves from one application to another. The Shared Signals Framework (SSF), meanwhile, enables security signals to be transmitted between different services. Initiatives such as the Blueprint Alliance are also working on open architectures designed to improve the governance and security of AI agents.

Sources:

PocketOS incident
https://zenity.io/blog/ai-agent-database-deletion-pocketos
https://x.com/lifeofjer/status/2048103471019434248
Cross-App Access: https://oauth.net/cross-app-access/
Shared Signals Framework: https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html
Blueprint Alliance: https://blueprintalliance.ai/