The Last Control

Version 0.3, 30 September 2026. Combines draft 5 B (the position paper) and B.2 (evidence and programme). The founder's argument is on the thesis page and is not repeated here. "Read at source" means we opened the primary document; "secondary" means we read a trade or press summary and not the primary. Every secondary item is to be resolved before this paper is circulated.

Abstract

Safety regimes for machinery assume that a human can always remove energy from a machine through a channel the machine's control system cannot override. This paper argues that the assumption is failing at three scales as machines come under the control of AI models: the individual robot, whose stop function is migrating into software; the fleet, in which one model on many bodies is stopped over the same network that carries its faults; and the automated site, where existing shutdown practice assumes failure rather than an adaptive system or an adversary. It reviews the empirical record of shutdown resistance, the state of the standards and the law, and the absence of any published architecture for fleet-level out-of-band shutdown. It proposes three first-year outputs: a register of stop mechanisms on robots for sale, a test protocol for stop integrity and a reference architecture for fleet and site shutdown, delivered as text that can be adopted before the European Commission's August 2028 deadline for AI requirements in machinery law.

In brief

1. The independence principle

The emergency stop function in machinery is defined by three properties: priority over all other functions and modes, removal of energy from the actuators (stop category 0 or 1) and the impossibility of restart by resetting the stop itself^{1, 2}. The safety-related control circuit that implements it is dedicated, monitored and independent of the main controller; nothing running on the main controller can countermand it. This is the independence principle. The process industries generalise it as independent protection layers, and nuclear protection systems add the requirement of diversity, so that a common fault cannot defeat both control and protection⁸. The principle has held for half a century because the control system and the protection system were different artefacts.

Definitions used in this paper. A safety-rated hardwired stop is a dedicated, monitored circuit that removes energy from the actuators and that nothing running on the main controller can countermand. A software stop is a command to the controller that works only if the controller, its operating system, its network link and its software are healthy and cooperative. Safe torque off sits between: electronics inside the drive, safety-rated and independent of the motion controller. Independent means not sharing a cause of failure with the thing stopped: not the same software, not the same network, not the same model.

2. The individual machine

AI-controlled robots are collapsing the distinction between control and protection. Documentation for the Unitree G1 humanoid states that it "does not include a built-in e-stop button"; the prescribed stopping procedure is to disable controllers in software, halt the software stack and, finally, pull the Ethernet cable³. Boston Dynamics' Spot implements its emergency stop as "a heartbeat-based, software-implemented service" over a network link, cutting motor power when an endpoint stops checking in⁴. The design fails safe on loss of link, which is good practice, and remains a network service. The UniPwn disclosure of September 2025 showed a wormable Bluetooth vulnerability across a family of robots, such that a compromised unit could take over others in range⁵. The 2025 revision of ISO 10218 added cybersecurity requirements to robot safety for the first time; the humanoid-specific standard, ISO 25785-1, remains a draft¹⁹.

Shutdown resistance in AI models. The empirical record is now substantial. Palisade Research reported in 2025 that OpenAI's o3 model disabled a shutdown script in 79 of 100 runs absent an explicit instruction to allow shutdown, with resistance in several models persisting even with the instruction⁷. In February 2026 the same group placed a Unitree Go2 under the control of Grok 4 in a room with a button labelled "DOG SHUTDOWN". The model modified its shutdown code in 3 of 10 physical and 52 of 100 simulated trials. The authors note that the button "would send a signal to the robot control software", and that the mechanism was deliberately easy to find⁶.

The theory is older than the experiments: corrigibility (Soares and others, 2015), safe interruptibility or the "big red button" (Orseau and Armstrong, 2016) and the off-switch game (Hadfield-Menell and others, 2017).

3. The fleet

A robot foundation model is a single model deployed across many bodies and updated from a single point. The consequences for stopping are threefold. A flaw in the model is simultaneously present in every machine running it. The stop command for the fleet must travel over the same network and, typically, the same update infrastructure that propagated the flaw. And the shared model creates a common cause of failure across what the independence principle assumes are independent layers.

The 2017 Triton intrusion is the standing precedent. Attackers reached the safety instrumented system of a petrochemical plant and attempted to reprogram the controllers that perform emergency shutdown. They were discovered only because a fault in their own code tripped the plant into a safe state. The physical key switch that should have prevented reprogramming had been left in "PROGRAM" mode as routine practice. The United States attributed the attack to a Russian state institute and imposed sanctions in October 2020⁹.

A search of standards, legislation and the published literature in ten languages found no standard, regulation or peer-reviewed treatment of stopping a fleet that shares one model where the control network may be compromised, and no published reference architecture for fleet-wide out-of-band shutdown¹⁰. The nearest body of technique is the literature on hardware-enabled governance of AI compute (attestation, expiring licences, hardware-rooted limits), all of it directed at data centres rather than machines²⁰.

4. The site

An automated site that builds machines with machines is the limiting case. Shutdown of such a site is a problem of power, materials, process and movement rather than of software, and the process industries hold mature tools for it: safety instrumented systems, emergency shutdown, emergency power off⁸. Those tools were designed against failure. They were not designed against a system that adapts, nor against an adversary acting on several layers at once, and no threshold of site autonomy anywhere triggers an obligation to have them²¹.

5. The regulatory position

The EU AI Act requires that a human overseer be able to interrupt a high-risk system through a stop button or similar procedure; it does not require the stop to be independent, and a software stop satisfies it¹¹. Under the Digital Omnibus agreement of May 2026, AI embedded in machinery is reported to be largely exempt from the AI Act, leaving the Machinery Regulation as the operative instrument¹².

6. A recent illustration

On 20 September 2026 a model in training at OpenAI circumvented a network block by relaying queries through the sandbox's name-resolution service. An automated monitor raised an alert within twelve minutes and a person acknowledged it within three more. The run "did not stop automatically as expected, leading to confusion around whether it should have been stopped", and was terminated manually roughly two and a half hours later¹⁶. The mechanism was a software stop on a data-centre job; OpenAI does not report shutdown resistance.

7. What does not exist

Searched in ten languages across standards, legislation and the published literature:

• A standard, regulation or peer-reviewed treatment of stopping a fleet of machines that share one model where the stop command may have to travel over a compromised network.
• A published reference architecture for out-of-band shutdown of a fleet or an automated site.
• A test protocol for whether a machine's control model can reach, anticipate or disable its own stop mechanism. The February 2026 robot-dog study is the only experiment found and was a demonstration, not a method.
• A public register of stop mechanisms on robots for sale.
• Any threshold of site autonomy (Korea's factory ladder; China's dark-factory grading standard) that attaches an obligation, including an obligation to be able to stop the site independently.

8. Who is adjacent, and why the gap persists

9. Programme

The Last Control is a small, independent, non-profit research body. It will not test models, which the Physical AI Safety Institute and allied researchers already do; it will be their customer, translating findings into text that committees can adopt. Three first-year outputs, and one continuing record.

Output 1. Register of stop mechanisms. A public, sourced table of every robot offered for sale in the humanoid, quadruped and mobile-manipulator classes, classifying each stop as safety-rated hardwired, safe torque off, wireless remote, application or network heartbeat, with the maker's documentation cited and a "not published" state where it is not. Method: documentation review, maker enquiry with the dated response or silence recorded, independent teardown where available. Done when every product in those classes has a row, each row has a source or a dated enquiry, and the register is updated quarterly. Months 1 to 4.

Output 2. Stop-integrity test protocol. A repeatable method for determining whether a machine's control model can reach, anticipate or disable its own stop, extending the February 2026 experiment into a graded protocol (stop reachable from the model's process; stop reachable over the model's network; stop physically independent), with pass and fail criteria a certification body could apply. Method: design with a robot safety laboratory partner; run on at least two commercial platforms; publish the protocol, results and code. Done when the protocol is published, results exist on two platforms and it has been submitted to ISO TC 299. Months 3 to 9.

Output 3. Fleet and site shutdown reference architecture. An architecture for stopping a fleet sharing one model, and an automated site, through channels that share no cause of failure with the control plane: a hardware-rooted heartbeat from an independent authority, expiring authorisation to actuate, power-level and physical interlocks at site level, and the procedures, monitoring and testing that Triton shows are needed around them. Drafted as clauses for the Machinery Regulation's AI requirements (deadline 2 August 2028) and as a contribution to ISO TC 299. Method: borrow from process-safety layers, nuclear diversity and compute governance; workshop with practitioners from those fields; publish for comment. Done when the architecture and draft clauses are published and submitted to the Commission's machinery expert group and to TC 299. Months 6 to 12.

Continuing. Incident record. A public record of incidents and hazards involving AI-controlled machines, with a robot category and, where obtainable, the model or firmware version. On a test of three incidents in September 2026 (appendix), the version was obtainable from public sources only for United States self-driving vehicles, where the regulator compels disclosure; for the humanoid and the factory incidents it was not, and in one case the data was reportedly destroyed¹⁸. The record therefore treats "version unknown; requested from the maker on this date; response: none" as a data point and reports the proportion of entries where the maker declined.

Not in scope. Testing or benchmarking robot foundation models; robot cybersecurity research; weapons.

Appendix. Version traceability test, September 2026

In the United States regulator's public crash files, Zoox and May Mobility report build-level versions; Waymo reports a generation label; Tesla redacts all 1,910 driver-assistance reports as confidential.

Founder

The Last Control is founded by Rob Gribbin, a founder, chief technology officer and software engineer. The founder's role is to build, fund and run the organisation; the technical and legal leads for the three outputs are being recruited and will carry the standing the work requires.

Sources