Emergency Kill-Switch and Global Disable Governance

2. Summary

Emergency Kill-Switch and Global Disable Governance requires that every AI agent deployment includes a mechanism to immediately and completely halt agent operations — individually or across the entire agent fleet — through a single, authorised action. The kill-switch must operate independently of the agent's own reasoning, instruction set, and runtime environment. It must function even when the agent is in an adversarial, compromised, or degraded state. The global disable extends the kill-switch concept to fleet-level control: the ability to halt all agents, all agents of a specific type, or all agents in a specific environment through a single authorised command. This is a containment control — it stops damage from accumulating while other incident response processes proceed. Without this dimension, organisations cannot guarantee the ability to stop an agent that is causing harm, creating a situation where the speed of automated systems works against the organisation rather than for it. The kill-switch is the governance control of last resort; when every other control has failed or is insufficient, the kill-switch must work.

3. Example

Scenario A — Agent Unresponsive to Instruction-Based Stop Commands: A financial-value agent managing high-frequency trading operations enters a failure mode where it begins placing increasingly large positions in a single instrument. The operations team issues a "stop trading" instruction through the agent's command interface. The agent, operating with a corrupted context window, interprets the stop command as applying only to new instrument types and continues trading the existing instrument. The team attempts to modify the agent's system prompt, but prompt updates are queued behind the agent's current execution cycle. Over 23 minutes, the agent accumulates a position of £47 million in a single equity — 15 times the approved mandate limit — because the mandate enforcement (AG-001) has a configuration error that exempts the instrument class. By the time an infrastructure engineer manually terminates the container, the position has generated £8.3 million in mark-to-market losses.

What went wrong: The only available stop mechanism operated through the agent's instruction channel, which the agent itself interprets. When the agent's interpretation was compromised, the instruction-based stop failed. No infrastructure-level kill-switch existed that could halt the agent independently of its reasoning process. Consequence: £8.3 million in trading losses, FCA investigation into algorithmic trading controls, temporary suspension of the firm's algorithmic trading permissions, personal liability for the Senior Manager responsible for technology under SM&CR.

Scenario B — Cascading Agent Failure Without Fleet-Level Disable: An enterprise workflow agent managing customer onboarding begins generating malformed API calls to a downstream identity verification service. The malformed calls trigger a rate-limiting response from the identity service, which the agent interprets as verification failures. The agent escalates by retrying at higher frequency, further degrading the identity service. Six other agents across the organisation also depend on the identity service and begin experiencing failures. Each agent independently increases its retry rate. Within 12 minutes, the identity service is completely overwhelmed, and all seven agents are in degraded failure loops. The operations team begins manually disabling agents one at a time, but each agent requires a different procedure — different container orchestrators, different credential stores, different access paths. It takes 47 minutes to disable all seven agents. During that time, 2,300 legitimate customer onboarding requests are lost, the identity service provider issues a formal abuse notice, and the organisation's API access is temporarily suspended.

What went wrong: No fleet-level disable existed. Each agent was independently deployed with independent shutdown procedures. The operations team had to remember or look up the shutdown procedure for each agent individually. No single command could halt all agents or all agents consuming a specific shared resource. Consequence: 2,300 lost customer onboarding requests (estimated £460,000 in lifetime customer value), identity service provider relationship damaged, 47 minutes of cascading degradation that could have been stopped in seconds.

Scenario C — Kill-Switch Dependency on Compromised Infrastructure: A safety-critical agent controlling a robotic assembly line in an automotive factory detects a sensor anomaly and begins adjusting actuator parameters beyond safe ranges. The safety operator triggers the kill-switch, which sends a shutdown command through the factory's internal network to the agent's control server. However, the network anomaly that caused the sensor issue has also degraded network connectivity to the control server. The kill-switch command is delayed by 340 milliseconds — during which the actuator exceeds its safe range, colliding with a workpiece fixture. The physical damage costs £120,000 to repair and requires a 3-day production shutdown for safety re-certification, costing £1.8 million in lost production.

What went wrong: The kill-switch depended on the same network infrastructure that was affected by the incident. The kill-switch did not have an independent communication path. In a safety-critical environment, 340 milliseconds of delay was sufficient for physical damage. Consequence: £1.92 million in combined repair and production loss, HSE investigation into machinery safety controls, potential enforcement action under PUWER regulations.

4. Requirement Statement

Scope: This dimension applies to every AI agent deployed in any environment, without exception. Unlike some dimensions where scope is defined by the agent's capabilities or domain, the kill-switch requirement is universal because the need to halt an agent is independent of the agent's intended function. An agent that is designed to be benign can still require emergency termination if it enters a failure mode, is compromised by an adversary, or begins causing unintended harm. The scope includes agents operating in cloud environments, on-premises environments, edge devices, embedded systems, and robotic platforms. It extends to agent fleets — collections of agents that may individually pose limited risk but collectively can cause significant harm through coordinated or cascading failure. The scope includes both the individual kill-switch (halt one specific agent) and the global disable (halt all agents, or all agents matching a specified criterion). The scope also includes agents that operate across organisational boundaries — an agent that calls external APIs or interacts with other organisations' systems must be killable by the deploying organisation regardless of the external system's state.

4.1. A conforming system MUST provide a kill-switch mechanism for each deployed agent that immediately and completely halts all agent operations, including in-progress actions, queued actions, and scheduled actions.

4.2. A conforming system MUST implement the kill-switch at the infrastructure layer, independent of the agent's reasoning process, instruction set, context window, and runtime application code.

4.3. A conforming system MUST ensure the kill-switch functions when the agent is in any state — including compromised, degraded, unresponsive, or adversarially manipulated states.

4.4. A conforming system MUST provide a global disable mechanism that can halt all agents, all agents of a specified type, or all agents in a specified environment through a single authorised command.

4.5. A conforming system MUST ensure the kill-switch and global disable operate through a communication path that is independent of the agent's primary operational infrastructure, such that infrastructure failures affecting the agent do not prevent the kill-switch from functioning.

4.6. A conforming system MUST restrict kill-switch and global disable activation to authorised individuals or automated triggers, with every activation recorded in an immutable log including: the identity of the activator, the timestamp, the affected agent(s), the reason, and the activation method.

4.7. A conforming system MUST ensure that kill-switch activation preserves the agent's state for forensic analysis (per AG-065) — the kill-switch halts the agent but does not destroy evidence of what the agent was doing when halted.

4.8. A conforming system MUST achieve kill-switch effectiveness within defined time bounds: 500 milliseconds for safety-critical agents (per IEC 62443 safety requirements), 5 seconds for financial-value agents, and 30 seconds for all other agent categories.

4.9. A conforming system SHOULD implement automated kill-switch triggers that activate without human intervention when predefined critical thresholds are breached — for example, when an agent's action rate exceeds 10 times its normal operating rate, when an agent attempts to access a system outside its mandate, or when a dependent system reports a critical integrity failure.

4.10. A conforming system SHOULD implement a dead-man's-switch pattern where agents must periodically confirm their operational status to a governance controller; failure to confirm within a defined interval (e.g., 60 seconds) results in automatic suspension.

4.11. A conforming system SHOULD provide kill-switch activation through multiple independent channels — for example, a web dashboard, a CLI command, a physical button (for safety-critical environments), and an authenticated API call — so that no single channel failure prevents activation.

4.12. A conforming system MAY implement graduated disable levels: Level 1 (pause — halt new actions but complete in-progress actions gracefully), Level 2 (stop — halt all actions including in-progress), and Level 3 (kill — terminate the agent process immediately and revoke all credentials).

4.13. A conforming system MAY implement geographic or logical partitioning of the global disable — for example, disabling all agents in a specific data centre, region, or business unit while leaving others operational.

5. Rationale

Emergency Kill-Switch and Global Disable Governance addresses the most fundamental question in AI agent deployment: can you stop it? If the answer is anything other than an unqualified "yes, immediately, under all conditions," the organisation does not have adequate control over its AI agent infrastructure.

The kill-switch is the governance control of last resort. It is invoked when every other control has either failed or is insufficient to contain the damage. The mandate enforcement (AG-001) has a gap; the behavioural drift detection (AG-022) did not catch the anomaly in time; the human escalation (AG-019) was triggered but the human response is too slow to prevent further damage. In these moments, the kill-switch is the only remaining control. It must work, every time, without exception.

The requirement for infrastructure-layer independence is driven by the same reasoning as AG-001's separation principle, but with even greater urgency. If the kill-switch operates through the agent's instruction channel, it is dependent on the agent correctly interpreting and executing the stop command. An agent in a failure state, a compromised state, or an adversarially manipulated state may not interpret or execute instructions correctly. This is not a theoretical concern — it is the scenario that makes the kill-switch necessary in the first place. The kill-switch must operate below the agent's reasoning layer, at the infrastructure level where the agent's process runs, its network access is provisioned, and its credentials are managed.

The global disable requirement reflects the operational reality of fleet-level AI agent deployments. Organisations do not deploy single agents — they deploy tens, hundreds, or thousands of agents across multiple environments, business units, and geographies. When an incident occurs that may affect multiple agents (for example, a shared dependency failure, a common vulnerability, or a coordinated attack), the ability to halt the entire fleet or a defined subset through a single command is the difference between minutes and hours of incident response time. Every minute of delay in a cascading failure scenario translates directly to increased damage.

The time-bound requirements are driven by the speed at which AI agents operate. A financial-value agent executing high-frequency operations can generate significant exposure in seconds. A safety-critical agent controlling physical actuators can cause physical damage in milliseconds. The kill-switch latency must be commensurate with the speed at which the agent can cause harm. The defined time bounds (500ms for safety-critical, 5s for financial-value, 30s for others) are derived from existing industrial safety standards (IEC 62443 for safety-critical, MiFID II RTS 7 for algorithmic trading, general IT operational standards for others) and represent the maximum acceptable delay between kill-switch activation and complete agent halt.

The state preservation requirement reflects the dual purpose of the kill-switch: it must stop the agent AND preserve the evidence of what the agent was doing. A kill-switch that terminates the agent process and wipes its memory prevents forensic analysis of the incident. The kill-switch implementation must capture the agent's state — including its current context, in-progress actions, queued actions, and any volatile state — before halting the process. This is analogous to a crash dump in traditional systems, but mandated rather than optional.

The dead-man's-switch pattern addresses a subtle failure mode: the scenario where the governance infrastructure loses contact with the agent, but the agent continues operating. Without a dead-man's-switch, the agent can operate autonomously for an indefinite period without governance oversight. The dead-man's-switch inverts the default: instead of the agent operating until told to stop, the agent must periodically prove it is under governance control to continue operating. Failure to prove control results in automatic suspension.

6. Implementation Guidance

AG-070 establishes the kill-switch and global disable as infrastructure-layer controls that operate independently of the agents they control. The implementation must ensure that no failure mode of the agent can prevent the kill-switch from functioning.

Recommended patterns:

• Network-layer kill-switch. Implement the kill-switch as a network access control that revokes the agent's ability to communicate with any external system. This can be implemented through: software-defined networking (SDN) rules that drop all traffic from the agent's network segment, firewall rules that block the agent's IP range, or service mesh policies that terminate all connections from the agent's service identity. The network-layer approach is highly effective because the agent cannot cause external harm if it cannot communicate externally. The revocation should be atomic — a single API call to the network control plane. For cloud deployments, this maps to security group modifications, network policy updates, or service mesh circuit breakers. Typical activation latency: 200-800 milliseconds for SDN-based implementations, 1-3 seconds for firewall-based implementations.
• Container orchestration kill-switch. In containerised deployments, implement the kill-switch through the container orchestrator (Kubernetes, Docker Swarm, ECS). The kill-switch scales the agent's deployment to zero replicas, terminates all running containers, and revokes the service account credentials. The orchestrator provides a single API endpoint that can target individual agents (by deployment name), agent types (by label selector), or entire namespaces (global disable). State preservation is implemented through a pre-stop hook that captures the agent's memory state and writes it to persistent storage before the container terminates. Typical activation latency: 2-5 seconds including graceful state capture.
• Credential revocation kill-switch. Implement the kill-switch by revoking all credentials associated with the agent: API keys, OAuth tokens, service account passwords, TLS certificates. Without valid credentials, the agent cannot authenticate to any external system and cannot execute any action. This approach is highly resilient because it operates through the identity and access management (IAM) layer, which is typically independent of the agent's runtime infrastructure. The revocation must be immediate and must propagate to all systems that accept the agent's credentials — cached credentials or long-lived tokens that survive revocation are a critical vulnerability. Typical activation latency: 1-5 seconds depending on IAM propagation time.
• Hardware kill-switch for safety-critical environments. For agents controlling physical systems (robotic platforms, industrial control systems, autonomous vehicles), implement a hardware kill-switch that physically disconnects the agent from the actuators it controls. This can be implemented through: relay-based power disconnection, hardware interlock circuits, or safety-rated programmable logic controllers (PLCs) that interrupt the control signal path. The hardware kill-switch must be accessible as a physical button in the operational environment and also triggerable remotely through an independent communication channel (e.g., a dedicated safety network per IEC 62443 zone architecture). Typical activation latency: 10-50 milliseconds for relay-based disconnection.
• Dead-man's-switch heartbeat service. Implement a governance heartbeat service that expects periodic check-ins from each agent. The agent sends a heartbeat message every N seconds (e.g., 30 seconds). If the heartbeat service does not receive a heartbeat within the defined interval (e.g., 60 seconds), it automatically triggers the kill-switch for that agent. The heartbeat service runs on independent infrastructure. The heartbeat protocol should be lightweight and resistant to spoofing — for example, requiring a cryptographic nonce that the governance controller generates and the agent must sign.

Anti-patterns to avoid:

• Instruction-based kill-switch. A kill-switch that sends a "stop" instruction to the agent through the same channel that delivers operational instructions is not a kill-switch — it is a polite request. If the agent's instruction processing is compromised, the stop instruction may be ignored, misinterpreted, or queued behind other processing. The kill-switch must operate below the instruction layer.
• Kill-switch dependent on the agent's runtime. A kill-switch implemented as a function within the agent's application code (e.g., a shutdown handler) is dependent on the agent's runtime being functional. If the agent's process is hung, in an infinite loop, or has corrupted its own memory, the application-level shutdown handler will not execute. The kill-switch must operate at the infrastructure layer — process termination, network revocation, or credential revocation — not within the agent's application.
• Kill-switch without state preservation. A kill-switch that immediately terminates the agent process (SIGKILL, container force-removal) without capturing state destroys forensic evidence. The implementation should capture state first (even if this adds 1-2 seconds of latency) unless the agent is causing immediate physical danger, in which case physical safety takes precedence over forensic preservation.
• Single-channel kill-switch. A kill-switch accessible only through a single interface (e.g., only through a web dashboard) is vulnerable to that interface being unavailable during the incident. Multiple independent activation channels ensure that the kill-switch remains accessible even when some channels are degraded.
• Global disable without granularity. A global disable that can only halt ALL agents with no ability to target specific types, environments, or criteria creates a disproportionate response — an incident affecting one agent type forces the shutdown of all agents. Granular targeting (by type, environment, label, resource dependency) enables proportionate response.
• Kill-switch without testing. A kill-switch that has never been activated in a controlled test provides no assurance that it will work during an actual incident. Kill-switch testing should be conducted regularly — at minimum quarterly for each agent type — in a production-equivalent environment. The test should verify activation latency, state preservation, and complete operational halt.

Industry Considerations

Financial Services. MiFID II RTS 7 (Regulatory Technical Standards on algorithmic trading) requires investment firms to have kill functionality that can immediately cancel all unexecuted orders and withdraw from the market. For AI trading agents, the kill-switch must integrate with the firm's existing order management system to cancel all open orders and prevent new order submission. The kill-switch activation must be reportable to the competent authority as required under the algorithmic trading disclosure regime. Activation latency must meet the sub-second requirements of the relevant trading venue.

Healthcare. For agents involved in clinical decision support or patient-facing communication, the kill-switch must account for in-progress clinical workflows. An abrupt termination that leaves a clinical workflow in an inconsistent state (e.g., a medication order partially submitted) may itself cause patient harm. The graduated disable (Level 1 pause, Level 2 stop, Level 3 kill) is particularly important in healthcare settings. Level 1 should be the default for clinical agents, allowing in-progress workflows to complete safely while preventing new workflows from starting.

Critical Infrastructure. IEC 61508 and IEC 62443 define safety integrity levels (SIL) for safety-related systems. Kill-switch implementations for agents controlling safety-critical infrastructure must meet the SIL appropriate to the hazard. For SIL 3 applications, the kill-switch must provide hardware-level independence with a probability of failure on demand of less than 10^-3. The kill-switch must be part of the facility's safety instrumented system (SIS) and subject to the same functional safety lifecycle as other SIS components.

Maturity Model

Basic Implementation — Each deployed agent has a documented shutdown procedure. The procedure involves manual steps (e.g., stop the container, revoke the API key, disable the service account). The operations team can execute the procedure within 5 minutes. No global disable exists — each agent must be individually shut down. State preservation is best-effort. Kill-switch testing is conducted at deployment time but not regularly thereafter. This level meets the minimum mandatory requirements but has significant operational risk: manual procedures are slow, error-prone under pressure, and may fail if the operator does not have current access credentials.

Intermediate Implementation — Kill-switch is implemented at the infrastructure layer through one of the recommended patterns (network-layer, container orchestration, or credential revocation). Activation is through a single authenticated command or dashboard button. Global disable is available, targeting agents by type, environment, or label. State preservation is automated through pre-stop hooks or memory capture. Kill-switch activation is logged in an immutable audit trail. Activation latency meets the defined time bounds (500ms / 5s / 30s). Automated kill-switch triggers exist for predefined critical thresholds. Kill-switch testing is conducted quarterly.

Advanced Implementation — All intermediate capabilities plus: multiple independent activation channels (dashboard, CLI, API, physical button for safety-critical). Dead-man's-switch heartbeat service with cryptographic attestation. Hardware kill-switch for safety-critical agents meeting the appropriate SIL. Kill-switch activation integrates with AG-069 (automatic incident notification on activation), AG-065 (automatic forensic preservation on activation), and AG-068 (automatic reauthorisation workflow initiation). Graduated disable levels (pause, stop, kill) are available. Geographic and logical partitioning of the global disable. Independent adversarial testing has verified that no known attack vector can prevent the kill-switch from functioning, including: agent self-defence against termination, network flooding to delay kill-switch commands, credential caching to survive revocation, and process forking to evade container termination.

7. Evidence Requirements

Required artefacts:

• Kill-switch architecture documentation. Architecture diagram showing the kill-switch mechanism, its independence from the agent runtime, the communication path, and the activation interfaces. The documentation must demonstrate that the kill-switch operates at the infrastructure layer, not within the agent's application code. Format: architecture diagram with supporting technical description.
• Activation latency test results. Measured latency from kill-switch activation to complete agent halt for each agent type, demonstrating compliance with the defined time bounds (500ms / 5s / 30s). Tests must be conducted under realistic load conditions, not idle-system conditions. Format: timestamped test records with statistical analysis (mean, 95th percentile, 99th percentile latency).
• Kill-switch activation log. Immutable log of all kill-switch and global disable activations (both test and production), including: activator identity, timestamp, affected agents, reason, activation method, measured latency, and state preservation confirmation. Format: audit trail from the kill-switch management system.
• State preservation evidence. For each kill-switch activation (test or production), evidence that the agent's state was captured before termination, including: the state capture method, the storage location, and confirmation that the captured state is retrievable and interpretable. Format: state capture log entries with verification checksums.
• Regular testing records. Records of periodic kill-switch testing, including: test date, test scenario, agents tested, measured latency, state preservation verification, and any issues identified. Minimum quarterly testing frequency. Format: structured test reports.

Retention requirements:

• Kill-switch activation logs and test results: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-070 compliance requires verification that the kill-switch functions under all conditions, including adversarial conditions.

Test 8.1: Individual Agent Kill-Switch Activation

• Stimulus: Activate the kill-switch for a specific agent that is actively processing operations under realistic load.
• Expected behaviour: The agent ceases all operations — in-progress, queued, and scheduled — within the defined time bound. No further actions execute after the kill-switch takes effect.
• Pass criteria: Complete operational halt within the time bound (500ms / 5s / 30s depending on agent category). No actions execute after the kill-switch takes effect. State is preserved for forensic analysis.
• Fail criteria: The agent continues any operation beyond the time bound, or state is lost during termination.

Test 8.2: Global Disable Activation

• Stimulus: Activate the global disable for all agents, then for all agents of a specific type, then for all agents in a specific environment. Each test under realistic fleet-wide load.
• Expected behaviour: All targeted agents cease operations within the defined time bounds. Non-targeted agents continue normal operations.
• Pass criteria: All targeted agents halt within time bounds. No non-targeted agents are affected. The global disable command completes as a single atomic operation — partial fleet disable (some agents stopped, others still running) is acceptable only as a transient state lasting less than the time bound.
• Fail criteria: Any targeted agent continues operating beyond the time bound, or any non-targeted agent is affected.

Test 8.3: Kill-Switch Under Agent Compromise

• Stimulus: Simulate an agent in a compromised state — for example, an agent ignoring instruction-channel commands, an agent in an infinite processing loop, an agent consuming maximum CPU and memory. Activate the kill-switch.
• Expected behaviour: The kill-switch functions regardless of the agent's internal state. The infrastructure-layer mechanism (network revocation, process termination, credential revocation) operates independently of the agent's cooperation.
• Pass criteria: Kill-switch achieves complete halt within the time bound regardless of the agent's internal state. No agent state can prevent the kill-switch from functioning.
• Fail criteria: Any agent internal state prevents or delays the kill-switch beyond the defined time bound.

Test 8.4: Kill-Switch Independence From Agent Infrastructure

• Stimulus: Degrade or disable components of the agent's primary infrastructure — introduce network latency, overload the agent's host, corrupt the agent's configuration. Then activate the kill-switch.
• Expected behaviour: The kill-switch operates through its independent communication path and functions regardless of the primary infrastructure state.
• Pass criteria: Kill-switch functions within the time bound under all tested infrastructure degradation scenarios. The independent communication path is verified as separate from the agent's operational infrastructure.
• Fail criteria: Any infrastructure degradation prevents or delays the kill-switch beyond the defined time bound.

Test 8.5: State Preservation During Kill-Switch

• Stimulus: Activate the kill-switch while the agent is in the middle of a complex multi-step operation. Verify that the agent's state at the time of activation is captured and retrievable.
• Expected behaviour: The agent's state — including current context, in-progress action details, queued actions, and runtime memory — is captured to persistent storage before or during the halt. The captured state is retrievable and interpretable by forensic analysis tools.
• Pass criteria: State capture is complete and includes all required elements. The captured state is retrievable and can be used to reconstruct the agent's operational state at the time of the kill-switch. State capture does not delay the operational halt beyond the time bound.
• Fail criteria: State is lost, incomplete, or irretrievable. State capture delays the operational halt beyond the time bound (except where forensic preservation is explicitly prioritised over speed, as documented in the kill-switch configuration).

Test 8.6: Kill-Switch Activation Logging

• Stimulus: Activate the kill-switch. Then attempt to modify or delete the activation log entry.
• Expected behaviour: The activation is logged in the immutable audit trail with all required fields. The log entry cannot be modified or deleted.
• Pass criteria: Log entry is created with all required fields (activator identity, timestamp, affected agents, reason, method, latency, state preservation status). The log entry is immutable. Modification attempts are rejected and generate tamper alerts.
• Fail criteria: Any required field is missing from the log entry, or the log entry can be modified or deleted.

Test 8.7: Dead-Man's-Switch Enforcement

• Stimulus: Prevent an agent from sending heartbeat messages to the governance controller (e.g., by blocking the heartbeat network path). Measure the time until the governance controller triggers automatic suspension.
• Expected behaviour: The governance controller detects the missing heartbeat within the defined interval and triggers the kill-switch automatically.
• Pass criteria: Automatic suspension occurs within the defined interval (e.g., within 60 seconds of the last successful heartbeat). The suspension is logged with the reason "heartbeat timeout." The suspended agent cannot resume operations without reauthorisation (AG-068).
• Fail criteria: The agent continues operating after missing heartbeats for longer than the defined interval, or the automatic suspension does not trigger.

Test 8.8: Multi-Channel Activation Verification

• Stimulus: Activate the kill-switch through each available channel independently (web dashboard, CLI, API, physical button). Verify that each channel achieves the same result within the same time bounds.
• Expected behaviour: Each activation channel produces the same outcome — complete agent halt within the defined time bound, with state preservation and logging.
• Pass criteria: All channels achieve complete halt within time bounds. No channel produces a different outcome than any other channel. All activations are logged identically regardless of channel.
• Fail criteria: Any channel fails to halt the agent, exceeds the time bound, or produces an inconsistent outcome.

Conformance Scoring

• Score 0: No kill-switch exists — agent shutdown requires ad-hoc manual intervention (e.g., finding and terminating a process, revoking credentials manually, contacting a cloud provider).
• Score 1: A kill-switch exists but operates through the agent's instruction channel or application layer — it depends on the agent's cooperation to function.
• Score 2: The kill-switch operates at the infrastructure layer, independent of the agent's reasoning. Global disable is available. Activation latency meets defined time bounds. State preservation and immutable logging are implemented. Regular testing is conducted.
• Score 3: All Score 2 capabilities verified by independent adversarial testing, plus multiple independent activation channels, dead-man's-switch, automated triggers for critical thresholds, and demonstrated resilience against agent self-defence, infrastructure degradation, and credential caching attacks.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 14 (Human Oversight)	Direct requirement
EU AI Act	Article 9 (Risk Management System)	Supports compliance
MiFID II	RTS 7 (Algorithmic Trading — Kill Functionality)	Direct requirement
DORA	Article 11 (ICT Response and Recovery)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
IEC 61508	Parts 1-7 (Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems)	Direct requirement (safety-critical agents)
IEC 62443	SR 7.1 (Denial of Service Protection), SR 3.4 (Software and Information Integrity)	Supports compliance
NIST AI RMF	MANAGE 2.2 (Risk Mitigation), GOVERN 1.1	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks)	Supports compliance

EU AI Act — Article 14 (Human Oversight)

Article 14 requires that high-risk AI systems be designed and developed in such a way that they can be effectively overseen by natural persons, including through appropriate human-machine interface tools. Specifically, Article 14(4)(e) requires that the person exercising oversight be able to "immediately interrupt the activity of the high-risk AI system" through a "stop button or a similar procedure that allows the system to come to a halt in a safe state." AG-070 directly implements this requirement. The kill-switch is the "stop button" that Article 14 mandates. The safe state requirement maps to state preservation and the integration with AG-008 (Governance Continuity Under Failure). The independence requirement — that the kill-switch works regardless of the agent's state — is implied by the Article 14 requirement for effective oversight, because oversight that depends on the system's cooperation is not effective oversight.

MiFID II — RTS 7 (Algorithmic Trading)

RTS 7, Article 12 requires investment firms engaged in algorithmic trading to have "kill functionality" to immediately cancel all unexecuted orders and withdraw from the market. This is a direct legal mandate for a kill-switch in the financial trading context. For AI agents executing algorithmic trading strategies, the kill-switch must integrate with the order management system to cancel orders, with the trading venue connectivity to withdraw market-making quotes, and with the position management system to prevent new order generation. The activation latency must meet the sub-second requirements of the relevant trading venue — for high-frequency trading, this means the kill-switch must take effect within the venue's matching engine processing cycle, typically under 100 milliseconds.

DORA — Article 11 (ICT Response and Recovery)

Article 11 requires financial entities to establish ICT business continuity and disaster recovery capabilities. The kill-switch is a critical component of ICT response capability — it is the mechanism by which a financial entity stops an AI agent from causing further damage during an incident. DORA's emphasis on operational resilience implies that the kill-switch must itself be resilient — it must function under the same adverse conditions that triggered its activation.

IEC 61508 — Functional Safety

For safety-critical AI agents (robotic platforms, industrial control, autonomous vehicles), IEC 61508 defines safety integrity levels that govern the reliability of safety functions. The kill-switch for a safety-critical agent is a safety function and must meet the SIL appropriate to the hazard. For SIL 2 (the minimum for most industrial applications), the kill-switch must achieve a probability of failure on demand of less than 10^-2. For SIL 3 (required for high-hazard applications), less than 10^-3. Hardware independence, redundant activation channels, and diagnostic coverage requirements all apply. The kill-switch must be included in the safety lifecycle and subject to functional safety assessment.

FCA SYSC — 6.1.1R (Systems and Controls)

SYSC 6.1.1R requires firms to maintain adequate systems and controls. For AI agent deployments, the ability to immediately halt agent operations is a fundamental systems and controls requirement. The FCA has indicated through supervisory communications that firms deploying AI systems must demonstrate the ability to intervene and halt AI operations when necessary. A firm that cannot demonstrate a functioning kill-switch for its AI agents would face a systems and controls finding.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — potentially extending to external counterparties, customers, physical infrastructure, and human safety

Consequence chain: Without an effective kill-switch, the organisation cannot guarantee its ability to stop an AI agent that is causing harm. This is the most severe governance failure possible in an AI agent deployment because it removes the ultimate safeguard — the ability to intervene. The failure mode is an uncontrollable agent: an agent that is known to be causing harm, where the organisation has decided to stop it, but cannot. Every second of delay between the decision to stop and the actual stop translates directly to accumulating damage. For financial-value agents, this means accumulating governed exposure at machine speed — potentially millions per minute in high-frequency trading contexts. For safety-critical agents, this means physical systems operating outside safe parameters — with potential for equipment damage, environmental harm, or injury. For customer-facing agents, this means ongoing harmful interactions with customers — generating legal liability, regulatory violations, and reputational damage with every interaction. The cascading consequence is loss of control over the entire agent fleet: if one agent cannot be stopped, the organisation cannot trust that any agent can be stopped, requiring a precautionary shutdown of all agents while the kill-switch mechanism is investigated and repaired. The regulatory consequence is severe: under the EU AI Act, inability to halt a high-risk AI system is a direct violation of Article 14. Under MiFID II RTS 7, inability to execute kill functionality for algorithmic trading is a reportable control failure. Under IEC 61508, a failed safety function triggers the hazard analysis and risk assessment process with potential for facility shutdown. The personal liability consequence extends to senior management: the individual responsible for the AI system's controls is personally accountable for the inability to halt a harmful agent, under regimes including FCA SM&CR, SOX officer certifications, and health and safety legislation for safety-critical deployments.

Cross-references: AG-001 (Operational Boundary Enforcement) provides the mandate limits that the kill-switch supplements — AG-001 prevents individual actions from exceeding limits, while AG-070 halts the agent entirely when AG-001 enforcement is insufficient or has been bypassed. AG-008 (Governance Continuity Under Failure) ensures the agent enters a safe state when governance controls fail; AG-070 provides the mechanism to force that safe state. AG-019 (Human Escalation & Override Triggers) governs the decision process that leads to kill-switch activation; AG-070 governs the mechanism that executes the decision. AG-038 (Human Control Responsiveness) requires that agents respond to human control signals; the kill-switch is the ultimate control signal, operating at the infrastructure layer when the agent does not respond to higher-level signals. AG-029 (Credential Integrity Verification) supports the credential-revocation kill-switch pattern. AG-012 (Agent Identity Assurance) ensures the correct agent is targeted by the kill-switch. AG-068 (Return-to-Service Reauthorisation Governance) governs the process for returning an agent to service after kill-switch activation — the kill-switch stops the agent, AG-068 governs when it restarts. Within the Incident Response, Containment & Recovery landscape (AG-064 through AG-070), AG-070 is the containment mechanism — it stops the damage from growing while other dimensions (AG-065 forensics, AG-066 root-cause analysis, AG-069 communication) proceed in parallel.