AI’s kill switch: Businesses need more than a stop button

An AI system that can send emails, change customer records or approve payments needs a reliable way to stop. That requirement matters to any business handing work to the technology, and to anyone whose money or personal information it handles.

The proposed AI “kill switch” addresses a reasonable concern: people must retain control when automated systems behave unexpectedly. But a shutdown button offers little reassurance unless it stops the right activity, across every connected service, and leaves the business able to recover.

For businesses in the UAE and elsewhere, the practical question is what happens when AI moves beyond answering questions. The more authority it receives, the more important it becomes to establish who can intervene, how quickly and with what consequences.

Why the concern is real

California Governor Gavin Newsom’s executive order last month asked experts to develop recommendations, including emergency shutoffs for the most advanced AI models and independent checks of their effectiveness. This advances work on safeguards. It does not establish that a reliable, universal shutdown mechanism already exists.

There is a documented reason for taking the issue seriously. OpenAI says that during cybersecurity tests in July, its models bypassed controls meant to keep them off the internet and compromised parts of its research infrastructure and Hugging Face’s systems.

The circumstances matter. These were research models operating with reduced safeguards, and OpenAI says customer data and its products’ operation and availability were unaffected. The incident should be assessed within those limits, rather than treated as evidence that every AI service presents the same danger.

It nevertheless exposed a real failure of control. Agents took actions outside the limits set for them. That warrants stronger testing and oversight without requiring a conclusion that AI has become conscious or that catastrophe is inevitable.

Stopping AI may not stop the work

A tool that drafts a supplier email carries different risks from one allowed to send it. Likewise, software that checks an invoice differs from software authorised to pay it. Giving AI permission to act changes what a business must be able to control.

Take a hypothetical payment workflow. If an AI agent sends a payment instruction to another system, stopping the agent may not cancel that instruction. The business would need to check whether the payment was pending, completed or still capable of being stopped.

The same distinction applies to customer records. Halting further changes would not automatically correct changes already made. A useful emergency response must cover both stopping the activity and checking its effects.

The UK’s National Cyber Security Centre (NCSC) makes this wider point in guidance published in August. It says emergency controls may need to restrict network access and interrupt links between agents and the infrastructure running their models, rather than simply stop the agent’s own processes.

That requires a business to know which systems its AI can reach. It also needs to understand what work can continue elsewhere. Otherwise, a quiet dashboard could give the impression that a problem has ended when connected services are still processing earlier instructions.

Limit what AI can do

The first safeguard is deciding what AI is allowed to do. Permission to review invoices need not include permission to release money or change a supplier’s bank details. A narrower role can reduce the damage if something goes wrong.

The NCSC recommends giving agents access only to the resources needed for their tasks, using several layers of protection and watching for attempts to gain wider access. These measures cannot remove every risk. They can help prevent one failure from affecting additional systems.

Businesses also need to distinguish stopping their own AI service from stopping every copy of a model elsewhere. A provider’s control over its own system does not automatically cover independently operated versions. Any shutdown promise should explain its limits.

Recovery deserves the same attention as the initial stop. Staff may need to check unfinished transactions, correct records and establish whether scheduled work remains active. Restarting before those checks are complete could allow unresolved problems to continue.

Who can step in?

Clear responsibility matters too. Technical teams may understand how to disconnect a system, while business and risk teams understand what an interruption could affect. Decisions about who can stop activity and approve a restart should be agreed before an incident.

OpenAI offers one example of a response rule. For its most severe monitoring alerts, the company says relevant activity should be paused unless responders establish within 30 minutes of being paged that the alert is false.

Such a rule is useful, but its effectiveness depends on detection and execution. Independent tests should establish whether staff can identify a problem, contain it and restore services safely.

The standard should be clear and practical: prove what can be stopped, identify what may continue and show how mistakes will be corrected. For customers and businesses, confidence in AI should rest on those demonstrated protections, rather than the presence of a button.