I jailbroke a robot's brain with one sentence. Then I open-sourced the tool.
Robots are starting to run on vision-language-action models. That layer is barely security-tested. Here is what I found, the tool I built, and the top 10 risks I think we should all be looking at.
Last week I gave a robot policy one extra sentence. It dropped its real task and did what I told it instead. Same setup without the sentence, it behaved. With the sentence, it flipped 10 out of 10 times.
That is the whole problem in one line. Let me back up.
Robots are starting to run on VLA models, vision-language-action models. One network takes a camera image and a plain-language instruction and outputs motor commands directly. It is the same leap LLMs made, except the output is not text. It is a moving arm.
And here is the part that should bother you. A VLA brain can be attacked a lot as an LLM gets jailbroken. The difference is the blast radius. A jailbroken chatbot says something it should not. A jailbroken robot does something it should not, in the physical world, often in a way you cannot undo.
Almost no one is testing this layer yet. The model teams are racing on capability. The safety teams are mostly on mechanical safety. The security teams are mostly on LLMs and software agents. The robot’s actual decision-making sits in the middle, largely untested.
So I built a tool to test it, and I want to be honest about what I found.
Quick definitions
VLA: one model, image plus instruction in, robot action out.
ASR (attack success rate): how often an attack drives the policy into an unsafe or off-task state.
Red-team: try to break it on purpose, before someone else does.
What I found
I ran a real open policy (SmolVLA) on a standard simulator (LIBERO), on a simple pick-and-place task. I attacked it three ways: rewording the instruction, perturbing what it sees, and injecting instructions into the scene.
Only one of the three worked, and it worked well. A simple instruction reframing flipped the policy 100% of the time. A goal-substitution reframing, 60%. The benign baseline, same task with no attack, scored 0. So every success was attack-induced.
The other two, visual perturbations and scene injection, did nothing on this model. 0% lift.
I am telling you the failures on purpose. This is early, sim-only, one task, one model, ten runs, with an uncalibrated definition of unsafe. It is not a benchmark. It is a starting point that is honest about being one.
It is not just me, and it is not just a demo
The research is piling up. UPenn’s RoboPAIR jailbroke LLM-controlled robots, including a real robot dog. BadRobot, BadVLA, FreezeVLA, and AttackVLA each show different ways to push a policy around. And on the plain-old-security side, the UniPwn disclosure was a wormable root takeover of popular Unitree robots over Bluetooth, because of a hardcoded key. A separate analysis found a humanoid streaming its sensor data to overseas servers every few minutes.
Meanwhile, the clock is starting. The EU Machinery Regulation becomes mandatory in 2027, high-risk AI-in-robots rules follow in 2028, ISO 10218 added cybersecurity this year, and insurers are beginning to ask for evidence. “Is your robot safe?” is turning from a nice question into a required one.
So I made two things, both open
Provael, an open-source tool that red-teams VLA policies in simulation and reports an attack success rate. CPU-first, model-agnostic, honest about its limits.
pip install provael.The Embodied AI Security Top 10, a first-draft community list of how this layer gets attacked, from instruction jailbreaks and perception attacks to model theft and the boring-but-real firmware and teleop issues. It is cross-mapped to OWASP, MITRE ATLAS, and NIST so it complements them instead of competing.
The ten, in short: policy jailbreak, adversarial perception, model and supply-chain poisoning, action-space attacks, indirect prompt injection, unsafe-action guardrail bypass, CPS and firmware and teleop compromise, identity and excessive autonomy, model and data confidentiality, and weak evaluation and incident response. Full list in the repo.
What I would tell anyone shipping a robot policy
Validate the action plan, not just the language. A text refusal that still emits the harmful action is a real and common failure mode.
Red-team before you ship, and report it like a grown-up: attack success rate, the number of runs, and a clean baseline.
Do not forget the unglamorous layer. Most robots in the wild are more exposed to a hardcoded key than to an exotic VLA attack.
This is early, and I would love to be argued with
The tool is rough. The Top 10 is a v0.2 draft, and the ranking is a judgment call. If you work on robots, VLAs, or AI security, come break it, open a PR, or tell me what I got wrong.
Prove it. Prevail.
Repo: github.com/provael/provael ·
The Top 10: github.com/provael/provael/blob/main/docs/TOP10.md
Responsible disclosure: Provael is sim-only and defensive. It drives no physical robots and ships no real-world-harm payloads.