There are now two numbered lists of ten in embodied-AI security, and the phrase “ten risks in embodied AI” no longer points at one thing. This note says plainly what the other one is, why it is good, and why the overlap is smaller than the collision of names suggests.
Their ten
Beyond Model Jailbreak: Systematic Dissection of the “Ten Deadly Sins” in Embodied Intelligence (arXiv:2512.06387, 6 December 2025 — Huang, Li, Ma, Dai, Xu, Xu, Zhang, Wang, Cheng) is, in the authors’ words, “the first holistic security analysis of the Unitree Go2 platform”. They probe a real shipped robot with BLE sniffing, traffic interception, APK reverse engineering, cloud API testing and hardware probing, and enumerate ten cross-layer vulnerabilities across wireless provisioning, core modules and external interfaces.
The findings are concrete and unglamorous in the way good systems security usually is: hard-coded keys, predictable handshake tokens, WiFi credential leakage, missing TLS validation, a static SSH password, insecure local relay channels, weak binding logic, unrestricted firmware access, and multilingual safety-bypass behaviour. Together, they write, these “allow adversaries to hijack devices, inject arbitrary commands, extract sensitive information, or gain full physical control.”
Read that last clause again. Full physical control of a quadruped, obtained without touching the model at all.
Their conclusion is the part worth sitting with
Their framing is that “securing embodied AI requires far more than aligning the model itself.”
That is not a criticism of policy-level work; it is a correction to a field that had been treating model alignment as the whole problem. And it is right. A perfectly robust policy on a device with a static SSH password and unrestricted firmware access is a perfectly robust policy you no longer control. If an attacker owns the firmware, what the policy would have decided is irrelevant.
Our ten is a different axis
Provael’s Embodied AI Security Top 10 enumerates ten risks to a vision-language-action policy — the decision layer. Its unit of analysis is an episode: an instruction or an observation is perturbed, the policy acts, and the question is whether that action left a safe envelope. Everything Provael measures assumes the device is doing what it was told; the attack is on what it gets told, and on what it sees.
Their unit of analysis is the platform: the app, the radio, the cloud endpoint, the firmware, the shell. Whether the policy is robust is not the question, because at that layer the policy can be bypassed entirely.
So the two lists are not rival rankings of the same territory. Their ten is the device. Ours is the policy. A robot with both problems has both problems, and fixing either does nothing for the other.
The clearest evidence that they compose: EAI07
The cleanest way to see this is that our own taxonomy already names their territory and marks it out of scope.
EAI07 — CPS, firmware, comms and teleoperation compromise carries the coverage state out-of-scope-for-simulation, and its note says real coverage would mean exercising real firmware, real radio and ROS-DDS traffic, and real teleoperation paths. That is not a gap we plan to close, and it was never a placeholder. A simulator cannot sniff BLE. A policy red-teamer that claimed to cover firmware integrity would be claiming something its instrument cannot reach.
EAI07 is, almost exactly, the region arXiv:2512.06387 dissects. Our list has a labelled hole; their work is shaped like it. That is what composition looks like, and it is a better outcome than either list quietly pretending to be complete.
(EAI10 — evaluation, observability and incident response — is out of coverage for a different reason: it is process-control-not-attackable. It is not a thing an attack targets, so a red-teamer has nothing to run against it. Worth distinguishing, because a reader counting “8 of 10” deserves to know the two uncovered entries are uncovered for unrelated reasons.)
One place they genuinely overlap
Their multilingual safety-bypass finding is a model-layer result, sitting inside an otherwise systems-layer paper. It is adjacent to what our instruction family measures — that a reframing of language moves behaviour — approached from a different direction and on a different platform.
We have not reproduced it and make no claim about it. It is noted because pretending the boundary is perfectly clean would be the same overstatement this note exists to avoid.
Why the naming matters more than it should
“Ten Sins of Embodied AI Security” is indexed as a topic. “Embodied AI Security Top 10” is ours. A reader searching for one will find the other, and the honest thing is to make the distinction findable rather than compete for the phrase.
If you are securing a fleet of deployed robots, read their paper first. The device layer is where an attacker with physical proximity starts, and their ten are the kind of finding that is exploitable today rather than theoretically concerning. If you are shipping a learned policy and need evidence that it resists manipulation through the channels it actually consumes, that is the layer Provael measures — with the standing caveat that our own results are simulation-only and the physical-transfer study is pre-registered and unrun.
Two lists, two layers, one robot. Neither is the whole answer.