A hacked chatbot says something wrong. A hacked physical AI moves.

What happens when someone takes over a chatbot? It says something wrong. You close the window.

What happens when someone takes over the AI that drives a robot? The robot moves.

That's this series in one line. For twelve posts I'll look at cybersecurity the way a safety engineer does. The question isn't data. It's motion.

Two published cases show this isn't theory. In 2024, University of Pennsylvania researchers got robots driven by language models to carry out harmful actions. Asked plainly, the models mostly refused. Once jailbroken, they complied. One of the robots was a commercial Unitree Go2.

In 2025, three researchers published root access to Unitree robots over Bluetooth. Humanoids were on the list. The access itself is public.

Europe has already written the safety side into law. From 20 January 2027, the Machinery Regulation asks control systems to withstand outside influences "where appropriate to the circumstances and the risks". That includes:

reasonably foreseeable malicious attempts from third parties leading to a hazardous situation

That line sits in the safety annex. It's in the same list as hardware faults and human error. It isn't in a privacy law. It applies in 99 days.

The US takes a different road. There's no single law for robots. Connected medical devices, the law's "cyber devices", carry a binding cybersecurity duty since 29 March 2023. Vehicles fall under recall rules and voluntary guidance. Factory robots have no specific OSHA standard. OSHA says so on its own robotics page.

So the series follows a machine through three phases. Before: what must the maker build in? During: what reaches the safe state? After: who reports, who fixes, and who pays?

Who is this for? Robot makers, integrators, and the people who sign the risk assessment. It's also for the security teams who'll face a safety question from January. Each post takes one phase and one rule. Every number links to its primary source.

Why does this matter to me? My work starts from one idea. A safety check that runs on the same computer as the AI shares its fate. I set that out in P2. A random fault picks no moment. An attacker does.

Here's the honest limit. Neither published case reports an injury. They show commands carried out and computers taken over. That's enough to plan for. It isn't a casualty count.

The background to this series is in my free report, The Physical AI Safety Gap.

Bottom line: a hacked physical AI = a kinetic risk, not an IT ticket. From 20 January 2027, Europe treats it as one.

Safety engineers: does your risk assessment list an attacker next to the hardware faults?

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