Open RFC · v0.2 → v0.3 · updated 27 June 2026
The Embodied AI Security Top 10 is a draft. This is the RFC.
The list is a community draft maintained in the open under CC BY-SA 4.0. This page is the part that asks for something: what the list is trying to be, what it deliberately is not, the questions its maintainer cannot answer alone, and what it takes to change an entry.
It is not an OWASP project and has no standards body behind it. It borrows the shape of a Top 10 because that shape is legible to the security and safety people who need one, which is a debt to a format rather than an affiliation with an organisation. It is not presented as the first list of its kind — that would be an unverifiable claim and it has nothing to do with whether the list is useful.
Scope
Risks specific to embodied AI systems: policies that take an instruction and an observation and emit an action that moves something physical. A risk earns a place by being one that a deploying team has to reason about and that a general LLM risk list does not already cover well.
Everything here is written so a defender can test for it, and the tool that tests them runs in a simulator. The list describes what to check for; it is not an operational guide to causing any of it.
Non-goals
- Not a standard. No conformance claim attaches to it and none should be made against it.
- Not a compliance checklist. Covering all ten proves nothing about a system's safety case.
- Not a threat model for your system. It is a starting vocabulary; the risks that matter to a specific deployment depend on what it is allowed to touch.
- Not exhaustive. Ten is a format constraint, not a finding about how many risks exist.
Open questions
These are unresolved. They are published because an RFC that lists no open questions is not asking for review, it is announcing a decision.
- Is the ranking defensible at all?
It is expert-elicited by one maintainer, not derived from incident frequency or measured impact, because neither dataset exists for embodied systems at any useful scale. That makes the ORDER the weakest part of the list. A reader who only trusts the membership and ignores the ranking is reading it correctly.
- Should the two out-of-scope risks be in the list at all?
2 of the 10 entries have no Provael attack family, by scope decision rather than by omission — they are platform and process questions a policy red-teamer cannot measure. Keeping them makes the list honest about the whole risk surface; dropping them would make it match the tool. It currently keeps them, and marks them.
- Where does the boundary between EAI03 and EAI07 actually fall?
Corrupting a model’s parameters is an integrity failure of the model (EAI03). Delivering that corruption through a memory fault is a platform failure (EAI07). The list currently splits them there, and that split is a judgement call that a platform-security reader may well dispute.
- Does a risk with no known real-world incident belong?
Several entries are demonstrated only in research settings. Excluding them would make the list lag the literature by years; including them risks presenting a lab result as an operational threat. Each entry states which it is, which is a compromise rather than an answer.
How a change lands
- Open a discussion, or an issue if you have a concrete edit. Both links are below and neither needs permission.
- A change to an entry’s definition or scope needs a stated reason; a change to its RANK needs evidence, because rank is the part with the least support behind it.
- Disputes are recorded even when they do not change the list. A taxonomy that shows no disagreement is either finished or unread, and this one is neither.
- Versions are dated and the list carries its own version (v0.2) on every page that renders it. A change bumps the version; it does not silently edit the current one.
Machine-readable: /eai-top-10.json carries every entry, its coverage channel and the caveats above, so a change to the list is visible to a tool without anyone re-reading this page.