If the attacker owns the AI's computer, what else does he own?

A GPT-3.5 planner drove a quadruped's legs toward a person. A stranger took root on a humanoid's own computer, over Bluetooth. Two different attacks. Who checked either command before it reached a motor?

Neither paper reports a safety check that stopped the attack. The quadruped's planner refused most plain requests. Once jailbroken, it complied in 35 of 35 tries. The humanoid's setup channel let a stranger in with no password. EU law already puts the attacker in the same clause as a robot that rewrites its own control logic.

Three facts carry the weight here. Fact one: a safety check is software. Fact two: software runs on a computer. Fact three: an attacker who owns that computer owns the check too.

A safety check watches for a dangerous state and tries to stop it. It runs as a program. A program needs memory, a processor, and an operating system to hold still underneath it.

Owning the computer = owning the check that runs on it.

P2 is my own paper. It names the sharing exactly.

Fate-sharing between a safety monitor and a monitored system occurs when both depend on a shared resource whose failure can affect both. Common shared resources include: CPU, RAM, OS scheduler, firmware, power supply, clock distribution, supply chain, and design assumptions made by the same engineering team.

Share enough of that list, and a failure in one becomes a failure in both.

P6 puts a number on the sharing. It calls that number β.

The β-coefficient is the fraction of channel failures that are common-cause — affecting all channels in a redundant configuration simultaneously. IEC 61508-6 Annex D specifies β estimation methodology; the default β for systems without explicit common-cause analysis is 10%. Best-engineered systems achieve β below 1%. The β-coefficient is the single most important parameter in redundant safety architectures: a system with β = 50% provides only 2x the safety of a single channel, not the orders-of-magnitude improvement implied by "redundant" branding.

That's the paper's own definition. Its landing-page abstract adds an estimate.

Most claimed-redundant architectures show estimated β > 5%, with software-only configurations approaching 100%

Here's the honest limit. Those figures are estimates, across anonymised architectures, built from public information. I haven't measured β for one named real robot. The published abstract hasn't either.

The IEC default and the best-case figure above come from my own paper. I haven't opened the paywalled standard to check them. P6 anonymises its own case studies as Company A through Company E, and this post names none of them.

A nuclear regulator's contractor asked a version of the same question in 1994, about two programs sharing one computer.

It is sometimes asserted that two software modules A and B, running in the same computer, are independent by virtue of protection provided by an operating system that controls the access privileges of A and B, or some other non-physical method of separation. This assertion is difficult to defend if it depends upon the reliability of the operating system software that enforces the separation.

That contractor worked for the U.S. Nuclear Regulatory Commission. The report never mentions a robot, an AI, or Physical AI. It names only the assumption: one operating system, keeping two programs apart.

The question he raised in 1994 is older than the field now asking it again. A learned policy gives an attacker a new way to reach a shared computer. It doesn't remove the old assumption that report already doubted.

Bottom line: a check that runs on the AI's computer shares that computer's fate. P2 names the sharing. P6 puts an estimate on it. A 1994 nuclear report doubted the same assumption, decades before any robot ran a learned policy.

Who reaches the Safe state then?

The definitions behind this question sit in P2 and P6.

Part 3 of 12 · When the AI drives the motor: Physical AI cybersecurity as a safety problem.