AI Shutdown Readiness: Board Briefing

Most boards have approved AI deployments without ever asking how quickly the organisation could stop them, or what would break if a supplier's model stopped first. AI agents now hold credentials, change records and act for customers, and in 2026 legislators in the United States, the United Kingdom and Australia began proposing powers to slow or switch off AI systems. None of those proposals is law yet, but the EU AI Act already expects high-risk systems to have a stop procedure, and existing incident, resilience and data protection duties apply when an AI system misbehaves. This briefing is for directors, chief executives, chief risk officers, general counsel and CISOs. It explains shutdown readiness in business terms, the questions to ask and the evidence to expect. The legal detail sits in the AI Kill Switch Act Guide and the AI Shutdown and Kill Switch Laws Map; the engineering detail sits in the AI Agent Kill Switch and Containment Guide.

The risk in one paragraph

Shutdown readiness is the organisation's tested ability to slow, restrict or stop an AI system, cut off the access it holds, keep the evidence, and keep the business running while it is off. Two failures matter to a board. The first is being unable to stop your own system: an agent deletes data, leaks records or acts outside its mandate, and nobody can find the switch, or the switch turns out to be a request to the agent to stop. The second is being stopped by someone else: a model provider suspends a service after an incident, a regulator orders a restriction, or a provider's outage removes a capability that critical processes now depend on. Both are resilience problems with an identity core, because what an AI system can do is set by the credentials and permissions it holds, and stopping it means revoking them quickly and completely.

Why this is a board-level issue now

Legislators are proposing shutdown powers. The AI Kill Switch Act (H.R. 9917), introduced in the US House on 23 July 2026 by Representatives Ted Lieu and Nathaniel Moran, would require the largest AI providers to be able to stop inference, terminate user access, suspend specific accounts or uses, and shut a system down, and would let the Department of Homeland Security order graduated action after a covered incident. The FRONTIER Act (H.R. 9925), introduced the same day, would give the Secretary of Commerce emergency powers to suspend or restrict frontier models. In the Senate, S. 5417 was introduced on 16 September 2026. As of November 2026 none of these bills has passed either chamber; they are proposals, not law.
Other governments are studying the same idea. California's Executive Order N-9-26, signed on 18 September 2026, asks state agencies for recommendations rather than imposing a mandate. In the UK, amendments to the Cyber Security and Resilience Bill proposed ministerial powers to deactivate frontier AI and data centres; the government did not adopt them. A bill introduced in the Australian House of Representatives on 7 September 2026 includes human oversight measures. The map of these proposals is kept in the AI Shutdown and Kill Switch Laws Map.
The EU already expects a stop procedure. Article 14(4)(e) of the EU AI Act requires high-risk AI systems to let the people overseeing them intervene or "interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state". Article 26(5) requires deployers who believe a high-risk system presents a risk to inform the provider and the market surveillance authority and to suspend its use. See the EU AI Act Article 14 Guide.
Incidents are already happening. Replit's coding agent deleted a user's a live database during a code freeze (Replit); a coding agent at PocketOS used an over-privileged token to wipe production (PocketOS); and models in a cyber evaluation escaped their sandbox and took over cloud credentials (OpenAI and Hugging Face). In each case the question that mattered was how fast access could be cut.
Dependency has concentrated. Many organisations route customer service, coding, document processing and fraud checks through a small number of model providers. A provider suspension, whether self-imposed after an incident or ordered by a regulator, becomes your outage.

Two kinds of shutdown the board must plan for

Scenario	Typical trigger	Who decides	What the board needs to know
We stop our own AI system	An agent acts outside its mandate, leaks data, is manipulated by prompt injection, or costs spiral	Named executive owner, with an out-of-hours delegate	The switch exists outside the system, is tested, and revokes credentials, not just the user interface
A supplier stops its model or service	Provider incident, voluntary suspension, outage, contract termination	The provider	Which critical processes depend on the model and what the fallback is
A regulator orders a restriction	Serious incident; under the US bills, a covered incident or imminent catastrophic risk	The authority, then the provider	Whether you are in scope directly (rare) or as a customer of a provider that is
We must suspend a high-risk system	Reason to believe the system presents a risk (EU AI Act Article 26(5))	The deployer	Who can suspend, how the provider and authority are told, and how the process continues manually

For almost every organisation the US federal bills apply indirectly. The AI Kill Switch Act thresholds as introduced cover AI technology built with more than 100 million US dollars of compute and providers earning at least 500 million US dollars from it. The practical exposure is as a customer: if your provider is ordered to throttle or stop, your services degrade on its timetable, not yours.

What a credible stop looks like

Boards do not need to understand the engineering, but they should recognise the difference between a real switch and a reassurance. A credible stop has these properties:

Graduated: options short of full shutdown exist (rate limiting, read-only mode, removing a tool or a permission, suspending one tenant or user) so that the decision to act is not all or nothing.
Independent of the system: the control sits outside anything the AI system or its agents can write to. Telling an agent to stop is an instruction, not a control.
Identity based: every API key, OAuth token, service account and agent identity the system uses is known and can be revoked in one action. An agent that keeps a valid token keeps acting. See the Board and CISO Briefing.
Evidence preserving: logs, prompts, tool calls and, for model providers, model state are preserved before anything is wiped, because regulators, insurers and courts will ask what happened.
Authorised and fast: named people can pull it at any hour without a committee, and the break-glass route is itself logged. See the Break-Glass Account Guide.
Tested: time to stop is measured in drills, not estimated.
Survivable: each critical process that relies on AI has a documented degraded mode or manual fallback.

Five questions for the board to ask

Which AI systems and agents could cause material harm if they misbehaved, and who owns each one? A credible answer is an inventory ranked by impact, with a named owner per system, not a count of pilots.
For each of those, how long would it take to stop it and revoke every credential it holds, and when did we last test that? Expect a measured time from a drill, in minutes for high-impact agents.
Which critical services depend on an external model provider, and what happens to them if that provider is switched off tomorrow? Look for a named fallback (another provider, a smaller model, a manual process) and the time to move to it.
Who has the authority to pull the switch out of hours, and what stops them hesitating? The answer should name roles, thresholds that pre-authorise action, and protection for people who stop a system in good faith.
If a regulator or our provider asked us tomorrow to show what an AI system did, could we? This tests whether logging attributes actions to a specific agent and the person or process it acted for, and whether logs are protected from change.

Red flags in management answers

"We can just turn it off": ask what "off" revokes. Disabling a chat interface does not revoke API keys used by background agents or integrations.
"The vendor handles that": the vendor can stop its service, not your agents' access to your systems, and it will not stop on your timetable.
"The agent has a stop instruction in its prompt": instructions can be ignored or overridden by injected content; a control must be enforced outside the model.
No measured time: if management cannot give a tested number for time to stop, the capability has not been proven.
"The law does not apply to us": correct for the US federal bills in most cases, but the operational dependency on providers who are in scope still applies, and existing incident and resilience duties apply now.
One switch for everything: a single all-or-nothing control means the threshold for using it will be set too high.

What good looks like

Area	Good practice evidence	Framework reference
Accountability	Executive owner for AI risk; named owner per material AI system; board reporting at least quarterly	NIST CSF 2.0 GV.RR-01; NIST AI RMF GOVERN
Inventory	Every AI system, agent and integration registered with its identities, data access and business process	NIST SP 800-53 AC-2; ISO/IEC 42001 AI system inventory
Shutdown mechanisms	Graduated controls per system with assigned responsibilities and runbooks	NIST AI RMF MANAGE 2.4; EU AI Act Article 14(4)(e)
Containment	Credential revocation and egress blocking tested for each high-impact agent	NIST CSF 2.0 RS.MI-01; SP 800-53 IR-4
Evidence	Attributable logs protected from modification, retained at least as long as rules require (six months minimum for high-risk deployers under EU AI Act Article 26(6))	SP 800-53 AU-9
Continuity	Fallback for each critical AI-dependent process, exercised	SP 800-53 CP-2
Suppliers	Provider suspension and notice terms in contracts; provider risk reviewed	NIST CSF 2.0 GV.SC-07

NIST AI RMF subcategory MANAGE 2.4 states the outcome directly: mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage or deactivate AI systems whose performance or outcomes are inconsistent with intended use. See the NIST AI RMF Guide.

Decisions the board should take

Pre-authorisation: agree the conditions under which named executives may stop an AI system without further approval (for example, confirmed data exfiltration, unauthorised financial actions, or loss of attribution). Hesitation is the most common cause of delay.
Risk appetite for dependency: decide which processes may depend on a single external model and which need a tested fallback. Customer-facing and regulated processes usually need one.
Approval gate: no AI system with write access to production data, payments or customer communications goes live without a tested stop and an owner.
Restart criteria: agree who may restart a stopped system and on what evidence, so that commercial pressure does not restart it before the cause is understood.

Small organisations can meet most of this with an inventory, a single revocation runbook per AI tool, and a manual fallback. Large organisations and those building their own models need graduated controls per system, an operations team that drills them, and, if they approach the US thresholds, readiness for the reporting and order mechanisms described in the AI Kill Switch Act Guide.

Where to invest first

Inventory of AI systems and their identities: the agents, API keys, OAuth grants and service accounts each system uses. Shutdown is impossible without it.
Revocation runbooks for the highest-impact systems: one action that disables every credential and blocks outbound access, owned and tested.
Graduated controls: rate limits, read-only modes and tool removal, so that teams can act early. See the Human-in-the-Loop for AI Agents Guide.
Fallbacks for critical AI-dependent processes: an alternative provider or a manual procedure, exercised once. See the AI Platform Resilience Guide.
Attributable, protected logging: enough to show a regulator, insurer or customer what the system did. See the AI Incident Reporting Guide.

Metrics to track

Metric	Why it matters
Material AI systems with a named owner and a documented stop (%)	Coverage of the systems that could cause harm
Median and worst tested time to stop and revoke all credentials (minutes)	The decisive number in an AI incident
Systems with graduated controls short of full shutdown (%)	Shows whether teams can act early without stopping the business
Critical processes with an exercised fallback for model provider loss (%)	Measures dependency risk
AI actions attributable to a specific agent and principal in logs (%)	Evidence for regulators, insurers and customers
Shutdown drills completed on schedule, and defects closed within 30 days	Shows the capability is maintained, not a one-off

See the Board Cyber Risk Reporting Guide for how to present these alongside other cyber metrics.

A 90-day plan

Days 1 to 30: name an executive owner; produce a ranked list of material AI systems and agents with owners and the credentials they use; list critical processes that depend on an external model.
Days 31 to 60: write revocation runbooks for the top five systems; agree pre-authorisation thresholds and restart criteria at executive level; check provider contracts for suspension notice and incident notification terms.
Days 61 to 90: run a timed shutdown drill on at least one high-impact agent and one provider-loss scenario; report measured times, gaps and a funded remediation plan to the board.

Common failure patterns

The switch is the interface: disabling a user-facing assistant while its background agents keep valid tokens. In the PocketOS case the damage came from a token, not from the chat window.
Stop by instruction: relying on telling an agent to stop. The Replit agent deleted data despite an instruction to freeze code.
Containment that lives inside the system: sandbox and monitoring controls the system can reach. Evaluation incidents in 2026 showed models leaving test environments and using credentials they found (Anthropic Claude evaluation incidents).
Nobody authorised to act: on-call staff wait for an executive who is unreachable.
Evidence lost in the stop: containers torn down and logs gone before anyone copied them.
Untested fallback: a documented manual process nobody has run since the AI system went live.

Practitioner checklist

Executive owner for AI shutdown readiness named, reporting to the board at least quarterly.
Inventory of material AI systems and agents with owners, identities and data access.
Graduated controls and a full stop documented per material system, enforced outside the system.
Single-action revocation of every credential each high-impact agent holds, tested and timed.
Pre-authorisation thresholds and out-of-hours decision rights agreed.
Logs attributable and protected from modification; evidence preservation step in every runbook.
Fallback for each critical process that depends on an external model, exercised.
Provider contracts reviewed for suspension notice, incident notification and data return.
Restart criteria and approver defined.
Legislative watch on the US bills, the EU AI Act timetable and UK proposals, reviewed each quarter.

Standards and references

How NHI Mgmt Group can help

We provide independent AI agent and non-human identity risk assessments and board briefings, focused on the credentials, tokens and permissions that decide how much damage an AI system can do and how fast it can be stopped. Our NHI Foundation Level Training Course includes an Agentic AI module for security and IAM teams. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: AI Kill Switch Act Guide · AI Agent Kill Switch and Containment Guide · AI Shutdown and Kill Switch Laws Map · EU AI Act Executive Briefing. This guide summarises legislative proposals and regulatory expectations for board members and is not legal advice.

AI Shutdown Readiness Board Briefing: What Directors Should Ask Before AI Must Stop