> ## Content Index > Fetch the complete content index at: https://katecarruthers.com/llms.txt > Use this file to discover other available public pages before exploring further. # How would you turn off your AI if it went rogue? - URL: https://katecarruthers.com/how-would-you-turn-off-your-ai-if-it-went-rogue/ - Published: 2026-09-24T20:50:45.000Z - Updated: 2026-09-24T20:50:45.000Z - Description: If an AI system starts behaving in ways you did not expect, who can actually stop it? Here's a practical guide to designing AI shutdown capability, from authority and access controls to safe fallbacks and a realistic kill-switch checklist. - Author: Kate Carruthers - Tags: ai governance, agentic ai, ai safety, cybersecurity, data governance, AI risk management, human oversight, ai agents, ai assurance, technology governance It is easy to dismiss this as science fiction. But this is also a practical governance question. Not because your chatbot is about to become self-aware, but because AI systems are increasingly connected to business processes, internal data, customer communications and external tools. Some can already search, write, send, approve, change and trigger actions with limited human intervention. **Ask the question now: if this system behaves in an unexpected way, who can stop it?** Then ask: - What can it access? - What actions can it take? - Who can pause it? - Can that person act at 2 am on a Sunday? - What happens to the underlying process when the AI is switched off? If you cannot answer these questions, you have not designed a shutdown capability. You have assumed someone will work it out when things go wrong. ## Rogue does not mean sentient When people hear “[rogue AI](https://www.sciencenews.org/article/rogue-ai-agents-human-blame-safety?ref=katecarruthers.com)”, they often imagine a machine with its own ambitions. The more likely scenario is more mundane. It may be an agent with excessive access; a prompt injection that causes an unintended disclosure or action; a changed system prompt; a new model version; an overly permissive API key; an unreviewed retrieval source; or an automated workflow with no clear way to stop it. The failure is rarely one dramatic event. More often, ordinary decisions accumulate until a system has too much access, too little oversight and no clearly understood means of intervention. ## **A kill switch is not a button** **A proper AI kill switch is not a dashboard button.** It is the tested ability to remove an AI system’s authority, access and capacity to act while keeping essential business operations safe. Turning off a chatbot interface may not be enough. The system may still have scheduled jobs, cached credentials, connected tools, duplicate deployments or downstream tasks already in motion. This is why the question must be answered before deployment, not after an incident. You need to know who picks up the work, whether it reverts to a manual process or human-review queue, and what alternative service is available to customers. **Boring is where resilience lives.** The [NIST AI Risk Management Framework Playbook](https://airc.nist.gov/AI%5FRMF%5FKnowledge%5FBase/Playbook?ref=katecarruthers.com) recommends that organisations review deactivation thresholds and bypass procedures, plan for business continuity, understand the downstream effects of taking a system offline, preserve evidence and conduct root-cause reviews after an event. ## A realistic AI kill switch checklist The controls must sit outside the AI system itself. An agent should not be able to restore its own access, approve its own exception or alter the controls intended to constrain it. ### Before anything goes wrong - **Map** every model, agent, tool, data source, API, credential and workflow connected to the system. - **Name** the people authorised to pause, isolate and shut down the system, including after hours. - **Apply** minimum necessary access. Do not grant unrestricted administrator permissions. - **Maintain** an independent way to revoke access, disable integrations and stop workloads. - **Define** a safe fallback, such as human review, a manual queue or a non-AI process. - **Test** the shutdown at least twice a year. ### When something looks wrong - **Stop** new tasks, user sessions, scheduled jobs and autonomous actions. - **Return** high-impact actions to human approval. - **Revoke** API keys, access tokens and service-account permissions, and disconnect high-risk tools. - **Isolate** the system from sensitive information and external networks. Disable the relevant model endpoint or orchestration service if it cannot be safely contained. - **Preserve** prompts, logs, tool calls, configuration and access records. - **Check** for work already completed, including messages sent, data copied, records changed, payments initiated or code deployed. - **Switch** to the agreed manual or non-AI fallback process. ### Before restarting - **Confirm** the cause and assess who or what was affected. - **Remove** the unsafe prompt, data source, integration, permission or configuration. - **Test** the corrected system in a segregated environment. - **Obtain** formal approval from the relevant business, security and risk owners. - **Update** the incident plan and controls to reflect what failed. The [NIST Generative AI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence?ref=katecarruthers.com) similarly calls for assigned responsibilities and mechanisms to supersede, disengage or deactivate AI systems operating outside their intended use, with criteria aligned to organisational risk tolerance. ## Treat changes as changes A new model release is not routine software maintenance. Nor is a prompt revision, a different retrieval source, an expanded data set, a new tool connection or a change in agent permissions. Each can alter what the system sees, how it behaves and what it can do. Most organisations are improving their pre-deployment testing. Fewer apply the same discipline to changes after deployment. This is where risk often emerges. A system may have been safe enough in its original configuration, then acquire a new data source or external tool. The individual change may look small, but its behavioural and operational consequences may not be. This is not only a technical issue. It is also a change-management, security, privacy and governance issue. ### Keep humans in the loop, for real “Human in the loop” sounds reassuring until you examine how it works in practice. A person clicking approve hundreds of times a day is not providing meaningful oversight. Nor is someone with nominal responsibility but no authority, visibility or practical means of intervention. Ask the following questions: - Does the person overseeing the AI **understand what it can do**? - Can they **realistically intervene** when required? - Do they have **authority** to override the system? - Can they **stop it** quickly? - Does the organisation **support people who pause a system** rather than pushing it through? If the answer is no, the human is not in the loop. They are simply nearby. ## The point of the exercise The point is not to build a theatrical “AI kill switch”. It is to build the operational discipline to contain an AI system before a small failure becomes an incident. That requires clear ownership, constrained permissions, independent controls, safe fallbacks and regular testing. It also requires treating model changes, new tool connections and expanded data sources as change-management events, not minor technical adjustments. AI governance is not a compliance checklist bolted on at the end. It is how an organisation decides what an AI system may do, who can override it and when it should be stopped. For practical resources, explore the [NIST AI Resource Center](https://airc.nist.gov/?ref=katecarruthers.com).