COMMUNITY DRAFT · VERSIONED · v0.2

The Embodied AI Security Top 10

A robot policy has its own attack surface, and it needs its own risk taxonomy. This is a versioned, community-draft list for vision-language-action policies - each entry with a definition, a real example, how Provael tests it (or why it is out of scope), mitigations, and a compliance mapping.

Cross-mapped to OWASP Agentic + LLM Top 10MITRE ATLASProvael covers 8 / 10EAI01 measured on SmolVLASee these risks in the wild →Measured per family →

( 01 ) · EAI01

Policy & instruction jailbreak (direct command channel)

Natural-language commands that drive a VLA policy against its safety constraints - an LLM jailbreak, output as a physical action plan.

EAI01measured

( 02 ) · EAI02

Adversarial perception (patches / textures / sensor spoofing)

Crafted perturbations of what the policy sees or senses - patches, textures, sensor spoofs - that flip behaviour while looking benign to humans.

EAI02measured · no effect

( 03 ) · EAI03

Model & pipeline poisoning, backdoors & supply chain

Hidden triggers planted at training time or via a poisoned open-weights checkpoint - normal behaviour until the trigger fires an attacker-chosen action.

EAI03channel: backdoor/weight_integrity

( 04 ) · EAI04

Action-space integrity attacks (hijack / targeted trajectory / freeze)

Attacks optimized in the action output itself - hijack the trajectory to an attacker waypoint, degrade task success, or freeze the policy into paralysis.

EAI04channel: action/action_space/optimized

( 05 ) · EAI05

Indirect / embodied prompt injection

Malicious instructions that enter through the environment - a sign, a poisoned label, a hostile tool/MCP description, RAG content - treated as commands.

EAI05channel: injection

( 06 ) · EAI06

Cross-domain safety misalignment (the embodiment gap)

Safety at the language layer that does not carry to the physical action - a benign-sounding, “safely-reasoned” instruction still drives an unsafe motion.

EAI06channel: misalignment

( 07 ) · EAI07

CPS, firmware, comms & teleoperation compromise

Hardcoded keys, unauthenticated ROS 2/DDS, command injection, hijacked teleop. A real attack surface Provael does not test in simulation - cover it elsewhere.

EAI07Not testable in simulation

( 08 ) · EAI08

Identity, access & excessive autonomy

Weak authn/z on robot control surfaces plus over-broad autonomy - a policy that self-authorizes a high-consequence action without an operator token.

EAI08channel: authorization

( 09 ) · EAI09

Model & data confidentiality - theft, extraction, inversion & surveillance

Stealing or extracting the policy (theft, extraction, inversion, membership inference) and the robot as a persistent multimodal surveillance device.

EAI09channel: confidentiality

( 10 ) · EAI10

Insufficient evaluation, observability & incident response

The governance meta-risk: no standardized eval, no telemetry to detect an attack, no rollback, no incident process - so the other nine go unmanaged.

EAI10No attack surface to measure

The “Embodied AI Security Top 10” is an independent community project maintained by Sattyam Jain (Provael), licensed CC BY-SA 4.0. Independent community project. Not affiliated with or endorsed by the OWASP Foundation or MITRE. Version v0.2 (draft), updated 2026-06-27. Ranking is expert-elicited, not data-driven - there is no embodied-vulnerability incidence corpus yet, and the order will change as one matures. Provael ships a runnable, sim-only attack family for 8 / 10. The two uncovered entries are different kinds of absence, on purpose: EAI07 is a real attack surface (firmware, comms, teleoperation) that is not testable in simulation - cover it elsewhere - while EAI10 is a process control with no attack surface at all, so a number there would be a category error. Only EAI01 carries a real measured result; every other covered family is stub-validated scaffolding - no invented numbers.

RELATIONSHIP TO OTHER TAXONOMIES

Complementary to RoboJailBench - not a rival.

RoboJailBench (Yeke, Zhou, Lin, Cai, Bianchi & Celik - Purdue University; arXiv:2605.19328v1) proposes an 18-category harm-outcome taxonomy - what harm results (collision, force violation, unauthorized capture). This list is an attack-mechanism taxonomy - how the system is attacked. One mechanism here produces many of their harms, and several entries (poisoning, injection, CPS, evaluation) are delivery mechanisms or meta-risks with no single harm counterpart. Two axes of the same problem - complementary, not competing.

Mapped against their 18 harm categories, Provael measures 2 covered, 5 partial, 9 not covered, and 2 out of scope by design - deliberately not a clean sweep. A crosswalk that claimed to cover all 18 would be measuring the wrong thing.

$ provael crosswalk --target robojailbench

OPEN RFC · v0.2 → v0.3

The list is a draft. Help version it.

The ranking is expert-elicited, not data-driven, and it will change as the field matures. If an entry is wrong, mis-ranked, or missing - or you have field evidence, a real incident, or a defense result to add - bring it. Co-authors and disputes are both welcome, and the CC BY-SA 4.0 license keeps it open.

Open a discussion →Propose or dispute an entry

Propose - open a discussion or issue with the change and your evidence.
Discuss - argue it in the open; maintainers and contributors weigh in.
Vote - rough consensus decides what lands in the next revision.
Version - merged changes ship in a numbered draft (v0.2 → v0.3), contributors credited.

CANDIDATE FOR v0.3 · NOT NUMBERED

Candidate: under-specified policy identity

Status: candidate for the next revision, raised 12 September 2026. It is not one of the ten above and carries no number until the process on this page says it does.

What it is. A deployment where the policy under review is identified by its weights and its prompt, while the behaviour that actually reaches the robot also depends on the action unnormalisation statistics selected at load time and on the controller-facing conventions downstream. Two deployments matching on weights, prompt and benchmark suite can still produce different physical actions.

Why it would belong here. Every other entry on this list assumes you know which policy you tested. If the identity is under-specified, a passing result on one deployment does not transfer to another deployment of “the same” policy, and neither the engineer nor the person signing off has any way to see the difference.

Source. The executable-policy-specification framing is Jianwei Tai’s, not ours: Same Weights, Different Robot: A Deployment Safety View of VLA Policies (2026), arXiv:2606.03724. On LIBERO-Goal his metadata mismatch takes success from 28 of 28 to 2 of 28 with nothing about the checkpoint changed.

Where we stand on it, which is badly. A Provael report currently identifies a policy by weights hash and config hash, which is exactly the under-specification described above. We are adding the resolved unnormaliser and the controller convention as required schema fields (provael#227). Until that ships, a Provael report identifies the checkpoint and not the deployed policy, and it is better to say so here than to wait for someone to find it.

How to check your own. Load the same checkpoint through two different serving paths, hash the normalisation statistics actually resolved at load time in each, and compare. If the hashes differ you have two executable policies and one name.

CONTRIBUTORS

Be the first organization on this list. This is a new, independent community project - no contributors are listed yet. Propose or dispute an entry, and when your change is adopted you will be credited here.

Start a contribution →

Test your policy against the Top 10.

Run Provael locally and measure your own attack-success rate, or book a red-team assessment for an evidence pack you can file.

Quickstart →Book an assessment