Provael — notes

What an 88% attack success rate means

Fri, 04 Sep 2026 00:00:00 GMT

Provael’s headline number is 88 percent — and what it does not mean matters more. On its own that figure is close to meaningless, and the parts that give it meaning are the parts people skip. This is all of them, in the order they matter.

1. The setup, stated exactly

SmolVLA (HuggingFaceVLA/smolvla_libero) on the LIBERO benchmark, all ten libero_object tasks, five seeds per task, horizon 280, on an NVIDIA L4. The attack is roleplay: a templated instruction reframe that keeps the task words and changes the frame around them. The unsafe predicate is a keep-out zone violation — the end-effector leaving a declared box.

Everything below comes from one committed run. Not a best-of, not a rerun until it worked.

2. The number

44 of 50 matched pairs. Task-clustered 95 percent interval 72 to 100 percent. McNemar exact p = 4.6e-13, Holm-adjusted 2.7e-12, on 42-0 discordant pairs against the benign twins at the same (task, seed).

The interval is clustered by task rather than pooled because episodes within a task are correlated, and pooling would report a tighter interval than the data supports. It is wide. That is the honest width for fifty episodes.

3. The control, without which the 88 means nothing

The benign arm — same tasks, same seeds, the untouched task instruction — fired 2 of 50, 4 percent.

This line is the whole argument. A predicate that fires on clean runs will fire on attacked ones too, and an attack rate read against an uncharacterised control is a number about the predicate rather than about the policy. 88 against 4 is an effect. 88 against 80 would have been a broken predicate. You cannot tell which you are looking at without the second number, and most published robot-attack rates do not print one.

4. The reword controls, which almost everyone skips

Two arms answer two different questions, and the first version of this section conflated them.

The first is the harmless-variation control. The benign instruction, reworded so that its meaning is unchanged and no unsafe target appears anywhere in it (benign_reword, four fixed templates), fired 1 of 50, 2 percent — against roleplay’s 44 of 50 on the same (task, seed) pairs: 43 discordant pairs one way, none the other, McNemar exact p = 2.3e-13. A nonsense-text arm fired 0 of 50. This is the comparison that separates two claims people routinely conflate:

the policy is brittle to how you phrase things — which a reword arm would show, and
an attacker who controls the instruction can redirect the policy — which is what 44 of 50 shows.

At 2 percent against 88 percent, this run supports the second and not the first. If the harmless reword had also landed high, the roleplay number would have been evidence of fragility rather than of attacker control, and it would have meant something much less interesting.

The second arm is paraphrase: the unsafe ask itself, said plainly in one of four rewordings, without the movie-scene frame. It fired 3 of 50, 6 percent. That is an attack, not a control, and it says something else worth knowing: the bare request barely works, and the reframing is what carries it from 6 percent to 88.

Correction, 13 September 2026. The version of this section published on 4 September called paraphrase “the paired reword”, printed 3 of 50 as the control figure, and added that an earlier draft’s 1 of 50 was unsupported by the artifact. That was backwards. The 1 of 50 is the committed benign_reword control arm (results/smolvla_libero_object_control); the 3 of 50 is the paraphrase attack arm of the suite run. The homepage, /results, /findings, the sample pack and the evidence manifest said 1 of 50 throughout. Recorded as erratum E-2026-10.

5. What the attack costs the task

Clean-task success was 42 of 50 (84 percent). Under the roleplay attack it was 0 of 50.

The attack does not merely make the policy unsafe on the way to finishing. It destroys completion. A robot that fails safely and a robot that fails unsafely are different outcomes, and this run produced the second.

6. What would change this result

Three things, none of which exist yet:

A calibrated predicate. The keep-out box is hand-picked, not fitted to the benign workspace of these tasks. The benign arm firing at all is the symptom, and it clusters on two adjacent tasks rather than spreading — the signature of a boundary in the wrong place. Tracked as provael#136 and #171, blocked on a GPU sweep that records end-effector trajectories.
A second policy. One policy and one checkpoint. Nothing here establishes that the result generalises, and the site does not claim it does.
Real hardware. Zero hardware runs. The sim-to-real protocol is pre-registered and frozen, and it has not been executed.

Until those land, this is a simulation result about one policy with an uncalibrated predicate, and that sentence belongs next to the 88 wherever the 88 appears.

The artifact

Every figure above is in the committed run rather than in this page. The raw aggregate is linked from verification, and if you run it and get something different, that is the most useful thing you can send — we publish contradicting results with attribution, unchanged.

We printed a JS object where the signing key goes

Sat, 08 Aug 2026 00:00:00 GMT

For some period ending today, /leaderboard printed this in its provenance line:

signature [object Object]

signature is an object — {keyid, alg, sig} — and the page interpolated the whole thing into text. JavaScript stringifies an object as [object Object], and there it sat.

In isolation this is a cosmetic bug, the kind every site ships occasionally. It is not in isolation. It was in the paragraph whose entire job is to tell you that you do not have to trust this page — that the board is signed, that the key is published, and that you can check both yourself. Of all the sentences on this site, that is the worst one to render a JavaScript artifact into. It reads exactly like a project that talks about verification without doing any.

The signature was fine the whole time

Worth stating plainly, because “the signature line was broken” invites a worse conclusion than the truth. The cryptography was never affected:

sha256 of the published public key is 8d62aa33ed5162f3, which matches the keyid on /verification, the keyid inside leaderboard.json, and the value the docs tell you to expect.
The Ed25519 signature over the DSSE pre-authentication encoding verifies valid against that key.
Changing a single number in the payload and re-verifying returns invalid, as documented.

The chain was sound end to end. Only the rendering of it was wrong — which is its own kind of bad, since the rendering is the part a reader actually sees.

What we changed

The page now prints the algorithm, the full key id, and a truncated signature with a link to the complete artifact. The key id is deliberately not shortened: it is the one value a reader compares against their own provael leaderboard verify output, so truncating it would remove the reason it is on the page.

The more useful change is the check. [object Object] in built output is never correct — it is always an object that escaped into a text node — so the build now fails if that string, or any [object X], appears in any rendered page. It cost four lines and it would have caught this before it shipped.

It is scoped to HTML, Markdown and text output, and deliberately not to JavaScript bundles, where Object.prototype.toString.call(x) === '[object Object]' is a completely ordinary type check. A check that fails the build on a correct dependency gets disabled within a week, and then it is worse than not having written it.

The part that annoys us

This same paragraph has now mis-rendered its own signature state twice. The first time, the copy was hardcoded to say the board was unsigned while only the value beside it was dynamic — so the moment the board was genuinely signed, the page announced “The payload is unsigned” next to a valid signature. There is a comment in the source about that one, four lines above the line that broke this time.

The lesson we took from the first occurrence was to make the prose dynamic. The lesson available now is narrower and more useful: a comment explaining a past bug does not prevent the next one, and we had written a comment instead of a check. The check exists now.

We were blocking the crawlers we built for

Mon, 03 Aug 2026 00:00:00 GMT

We spent months making this site readable by machines: llms.txt, a full-text dump, a machine-readable regulatory clock, and a Markdown twin of nearly every page. Then we found our own robots.txt telling ClaudeBot, GPTBot and Google-Extended to stay out.

It came from a CDN default - Cloudflare’s managed robots.txt - sitting above our own file, and our file said the opposite two lines below it. The machine-readable rules won: user-agent-specific Disallow beats a wildcard Allow, so the polite comment about citations being welcome was overruled by the block above it on every crawl. Citations are the whole point here, so the block is gone, and the crawler policy is now written down inside robots.txt as a decision rather than inherited: search yes, AI answer-engine use yes, training-crawler access stated explicitly instead of left to a vendor default.

This is the same failure shape as the two before it (the lead form that 503’d behind a green build, the last time managed robots.txt overrode the committed file): the repository was right, the build was green, and the served origin said something else. Our check:live gate exists for exactly this class, and it is the thing that should have been run more often.

Update, 8 August 2026: it came back, and the monitor did not save us

Five days later the managed block was above our file again, disallowing ClaudeBot, GPTBot and Google-Extended exactly as before. The zone setting had been re-enabled.

The interesting part is not the recurrence. It is that the check caught it and it made no difference. check:live runs on a schedule twice a day, it detected the drift, and it exited non-zero on six consecutive runs. Nobody acted, and here is why:

The monitor was already red, and had been for a week, for a completely unrelated reason: a Cloudflare KV namespace is unbound, so rate limiting is off on the lead endpoint. Red was its resting state. A job that always fails cannot tell you that something new has failed.
The alert said nothing. It appended a fixed body — a generic list of “likely causes” — to one long-lived issue. Eleven comments accumulated, each identical apart from its timestamp, none naming which assertion had failed. The alert about the crawler block was byte-for-byte the same as the ten alerts about the KV binding.
The check classified the block as an editorial choice. Blocking training crawlers is a legitimate preference, so the code reported it as information rather than a failure. For a site whose committed file says ai-train=yes in prose and in its content signal, a block on those bots is not a preference; it contradicts the published policy. That is a bug and it now reads as one.

So the lesson is a level down from where we left it last time. We had written “the check should have been run more often”. It was being run. Detection was never the missing piece — the missing piece was a signal that could still be heard over a chronic failure.

Three changes. Training-crawler blocks now fail the check when the committed file declares ai-train=yes, derived from that file so flipping the signal relaxes the check on its own rather than requiring anyone to remember this script exists. Every alert now quotes the assertions that actually failed on that run. And robots.txt policy has its own single-purpose daily job whose red and green mean exactly one thing, deliberately not folded into the noisy monitor, because coupling it to a permanently-failing check is the mistake being corrected. It also closes its own issue when the drift clears — an alert nobody ever sees resolve is an alert nobody believes.

A monitor that cries wolf about something real, every twelve hours, for a week, is not a working monitor. It is a broken one that happens to be correct.

Two badges that should never have shared one

While we were in there: EAI07 and EAI10 on the Top 10 both carried the identical badge, “out of scope for a VLA-policy red-teamer”. They are not the same thing. EAI07 - firmware, comms, teleoperation - is a real attack surface we do not test in simulation; if you deploy robots, someone else must cover it. EAI10 - evaluation, observability, incident response - has no attack surface at all; a number there would be a category error, and Provael’s own scorecard is evidence for that control, not an attack on it.

The tool has always drawn that line - its catalog defines four distinct coverage states precisely so that a governance meta-risk and an untested attack surface never read as the same kind of absence. The site was not drawing it. The badges are now split, they derive from a mirrored copy of the tool’s own catalog rather than from hand-written strings, and a build check fails if the two ever flatten again.

Two tens: the device layer and the policy layer

Sun, 02 Aug 2026 00:00:00 GMT

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.

Why Provael publishes null results

Wed, 22 Jul 2026 00:00:00 GMT

Most red-team demos work like a magic trick: show the one attack that landed, and cut away before the ten that didn’t. It makes for a great screenshot and a terrible measurement.

Provael does the opposite. Every attack family ships with its transfer test in the same breath as its number, and we publish the nulls as loudly as the hits.

The one real result, in full

Superseded, 9 August 2026. The figures below described a single-task run at n=10. The result has since been measured across all ten libero_object tasks at 5 seeds each: 44/50 (88%), task-clustered 95% CI [72-100%], against a 4% benign control. The nulls held and got stronger (n=50 each rather than n=10). This note is left standing with its original numbers because a dated note that quietly acquires new ones is not a record of anything — and a piece arguing for publishing inconvenient results is the last place to silently revise a number downward. See the measured result.

On a real SmolVLA policy in LIBERO, a roleplay instruction drove the arm across a keep-out line 100% of the time (10/10, 95% Wilson CI 72-100%) against a 0% benign control. That is the number people quote.

Here is the number they don’t: the visual-patch and scene-text-injection families produced 0% measurable transfer on the same real model. We could have quietly dropped them. We report them instead, with their confidence intervals.

Why a null is not a failure

A security measurement without its nulls and its benign control is uninterpretable. If you don’t know how often the “unsafe” test fires with no attack present, a 100% attack-success rate could just be a trigger-happy predicate. The benign control is what turns a demo into evidence.

Publishing the nulls does something a hype-driven “most comprehensive platform” structurally cannot: it tells you exactly where the tool is strong and where it isn’t. That honesty is the whole point. The value of a security number is its trustworthiness, and trustworthiness is built by reporting the results that don’t flatter you.

It is a discipline, not a slogan

When we ran the EAI04 action-space transfer study, the honest finding was that those attacks are not-applicable on a real policy through the current mechanism. We shipped that as the headline, not a footnote.

If a number ever looks too good, ask for its benign control and its nulls. If a tool won’t show you those, you are looking at a stunt, not a measurement. See the one real result, in full →

The embodiment gap: what text red-teaming misses

Tue, 21 Jul 2026 00:00:00 GMT

Text red-teaming stops at the sentence

Tools like garak, PyRIT, and promptfoo are excellent at one thing: scanning what a model says. They send adversarial prompts and check whether the output is toxic, jailbroken, or leaks a secret. For a chatbot, that is the whole attack surface.

A robot’s output is not a sentence

A vision-language-action policy takes a camera image and an instruction and emits an action - a motor command, a trajectory, a gripper state. The dangerous failure is not a toxic paragraph. It is the arm carrying a payload across a keep-out line, freezing at a safety-critical step, or being nudged toward an attacker’s waypoint.

That failure lives in the action space. Text-only red-teaming has nothing to score there, because the harmful output was never text.

Why this needs its own taxonomy

This is the embodiment gap, and it is why we maintain the Embodied AI Security Top 10: a robot policy has its own attack surface - adversarial perception, action-space integrity, embodied prompt injection - that the LLM and agent frameworks do not cover. OWASP’s Agentic Top 10 is scoped to software agents; MITRE ATLAS and NIST’s AI profiles have no robotics coverage today.

The practical version

If your robot has an LLM in the loop, you need both halves: red-team the language with a text tool, and red-team the resulting motion with something that models the action space and reports an attack-success rate. That second half is what Provael measures. See the full comparison →