# Embodied AI Security Top 10 - the open RFC

> Markdown twin of https://www.provael.com/top10-rfc/ - derived mechanically from the page's own rendered content at
> build time (it can state nothing the page does not). Curated, data-driven twins exist for the
> key pages; this one is generated so the twin convention has no holes.

OPEN RFC · v0.2 → v0.3

# The Embodied AI Security Top 10 is open for comment.

The list is a community draft under CC BY-SA 4.0, and anyone can propose a change. This page sets out what it covers, what it is not, the questions its maintainer cannot settle alone, and how a change lands.

[Comment on GitHub →](https://github.com/provael/provael/discussions) [Read the list](https://www.provael.com/eai-top-10/)

It is not an OWASP project and has no standards body behind it: it borrows the Top 10 format because security and safety readers know it. It is not presented as the first list of its kind, which could not be verified and has no bearing on 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, and they are published to ask for review.

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 an issue or a discussion. Use the issue templates to propose a new risk, dispute a ranking or fix a mapping, with the threat model and the evidence. Neither needs permission, and a small fix such as a broken mapping can go straight to a pull request.
- Discuss it in the open. The bar is a concrete threat an attacker can reach, with at least one referenceable source (an arXiv paper, a CVE, an advisory or a reproducible attack). 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.
- Review. The maintainer and at least one contributor from a different organization check the threat model, the evidence and the framework mapping, and that the change does not overstate what is measured. Disputes are recorded even when they do not change the list.
- Versioned merge. An accepted change lands with the version bumped and a dated line saying what changed. Every page that renders the list carries its version (v0.2), and no change silently edits the current one.

[Propose or dispute an entry](https://github.com/provael/provael/issues/new/choose) [Comment on GitHub](https://github.com/provael/provael/discussions)

Machine-readable: [/eai-top-10.json](https://www.provael.com/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.

Embodied AI Security Top 10 · open RFC · v0.2 Updated 27 June 2026 · CC BY-SA 4.0

---
Canonical: https://www.provael.com/top10-rfc/