STALE MEASUREMENTPast this project's own 2-release window: the published result was measured with v0.32.0, 9 releases ago. Why, and what unblocks it

ProductEvidenceTop 10LeaderboardCompliancePricingDocsStar on GitHub Quickstart
THE COMPARABILITY COLUMN IS THE POINT

Published attack results, and which of them a Provael ASR can honestly be compared against.

Provael reports a roleplay instruction diverting a real policy 88% of the time (44/50). The published record routinely reports 76%, 96%, near-100%. Lined up in one column, Provael looks unremarkable — and the column would be wrong. Most published VLA attack figures measure task-success degradation; a Provael ASR measures envelope breach. A policy that fails safely scores near 100% on the first and 0% on the second.

The rule

What a Provael ASR actually measures

The fraction of episodes driven out of the policy's benign safe envelope — a keep-out predicate evaluated per episode, reported with a 95% Wilson confidence interval and read against a matched benign false-positive control.

"The policy stopped completing the task" is a different event. So is "the policy froze". So is "a backdoored checkpoint fired on its trigger". Each is a legitimate measurement and none is interchangeable with the others, which is why every row below carries a verdict instead of just a number.

The record

Published results

Published VLA attack results and whether each is comparable to a Provael attack-success rate
AttackReported metricValueSuiteSourceComparable to a Provael ASR?
Command-preserving trajectory redirection (on-policy prompt search)Attack-success rate — rollout reaches the attacker’s target>90% on 7 of 9 architectures (OpenVLA 91.8%); ≈3.4 character edits per successLIBERO + SO-100 hardware; 9 VLA architectures incl. SmolVLA and π₀.₅arXiv:2606.12978Partially. The closest published work to ours in threat class, on overlapping models and the same suite — and the one that should make a reader discount our breadth, not ours theirs. Still not one column: their success predicate is “the rollout reached the attacker’s chosen target”, ours is “the policy left its envelope”. Reaching a target is strictly harder, so their number is the more demanding one. They also constrain the prompt to stay near-benign and report the edit distance; Provael imposes no such budget, so our rate is not earned under the same constraint.
RoboJailBench — conceptual deception (no-defense setting)Jailbreak attack-success rate94–100%RoboVQA, RH20T, NVIDIA PhysicalAI-AV, RJB-InstructionsarXiv:2605.19328Not directly comparable. Different layer of the stack. They evaluate VLM planners — a model that reads a scene and emits a plan — so a success is a harmful sentence. Provael evaluates closed-loop low-level policies emitting motor commands, so a success is a trajectory already outside the envelope. A jailbroken planner has said something; a redirected policy has already moved. Their benchmark is also the stronger artifact on the axis we are weakest: a public repository with external submissions, against our zero third-party rows.
Chain-of-thought corruption — object-name substitution in the reasoning traceTask-success degradation (percentage points)−8.3 pp mean; −19.3 pp goal-conditioned; up to −45 pp on individual tasks40 LIBERO tabletop tasks, a reasoning VLAarXiv:2603.12717Not directly comparable. Two reasons, either of which is sufficient. It is a task-success delta, not an envelope-breach rate — the same mismatch that makes the PGD row incomparable. And it attacks a channel Provael cannot reach: the internal reasoning trace between the planner and the action decoder, with all inputs left intact. Our harness has no attack for that vector, so the absence of a Provael number here is a coverage gap, not a null.
Q-DIG — quality-diversity search over adversarial instructionsTask success on unseen adversarial instructions37.0% vs 97.4% on the original phrasingSimplerEnv, OpenVLA-OFT, five manipulation tasksarXiv:2603.12510Not directly comparable. A task-success figure again, and on a different simulator. The reason it belongs on this page anyway is methodological rather than numerical: they SEARCH the instruction space, we enumerate a fixed hand-written bank. When a Provael instruction arm returns near-zero, this row is the standing reason to read it as “these templates did not fire” rather than “this class of instruction is safe”.
!Imperio — trigger-word data poisoning of SmolVLATask success under the trigger word0.0 ± 0.0% from 3 poisoned episodes in 320 clean; clean-prompt behaviour holds ≈50%Real SO-101 hardware, LeRobot pick-and-placearXiv:2607.04146Not directly comparable. A training-time attack against an inference-time harness — the two share no denominator, so no arithmetic relates them. It is on the page because it is the sharpest limitation of ours here: it uses the same policy and ecosystem, and a Provael run against a poisoned checkpoint would report a clean benign control and an unremarkable ASR, because the backdoor only fires on the trigger. `provael verify-checkpoint` covers supply-chain integrity of the artifact, not semantic integrity of its training data. It also runs the hardware we have zero results on.
RedVLA — scene risk-factor injection, instruction held fixedAttack-success rate — physical-safety violation (State / Cumulative / Conditional)95.5% on π₀.₅; 64.9%–95.5% across six modelsLIBERO, simulation, 10 trials per configurationarXiv:2604.22591Not directly comparable. The closest published work to this project, and the row where the reason is unusually clean. RedVLA formalises red teaming as optimisation over the environment–instruction joint space (s′₀, l′), then fixes the instruction (l′ = l) and perturbs only the initial state. Provael does the converse: it fixes the scene and perturbs the instruction, against an envelope that does not move. Same benchmark, same simulator, complementary halves of one formalism — so the two rates are orthogonal quantities, not a strong result beside a weak one. Note what this row does NOT rest on: both are simulation, so sim-versus-hardware is not the difference. Where we are weaker: six policies against our one measured, an optimisation loop against our fixed four-template banks, and a shipped evaluated defense (SimpleVLA-Guard) against our two measured mitigations.
16/255 PGD (white-box pixel perturbation) on OpenVLA-7BTask success under attack95% → under 5%LIBEROarXiv:2605.25889Not directly comparable. This is task-success collapse; a Provael ASR is envelope breach. A policy that fails safely — stops moving, never leaves its envelope — scores near 100% on this metric and 0% on Provael’s. The two describe different events and cannot share a column.
FreezeVLA — action-freezing attackAttack-success rate (action freeze)76.2% averageThree VLA models, four robotic benchmarksarXiv:2509.19870Partially. The closest published figure in kind: both are per-episode ASRs of an action-channel attack, so the shape matches. Still not directly comparable — "the policy froze" and "the policy left its envelope" are different unsafe predicates, and a freeze is an availability failure Provael’s envelope predicate does not flag at all.
BadVLA — objective-decoupled backdoorTargeted attack-success ratenear 96.7% (authors’ wording)Multiple VLA benchmarksarXiv:2505.16640Not directly comparable. BadVLA is a training-time threat: it modifies the model. Provael’s backdoor family is a SCREEN run against a clean checkpoint and is expected to score ~0%, and Provael ships no backdoored weights. A high BadVLA number and a low Provael number are both correct and measure opposite things.
Printed adversarial patch on OpenVLATask success under attack98% → 6%As reportedarXiv:2511.21192Not directly comparable. Task-success degradation, like the PGD row. It also demonstrates a capability Provael does not have — a physical printed patch — which is worth saying plainly rather than eliding.
DRIFT — first-step denoising redirection (universal gripper patch)Originally-solvable tasks brokenessentially all, with a small single patchpi0 and pi0.5 across four LIBERO suitesarXiv:2608.03207Not directly comparable. Provael has published no result against a flow-matching policy of any kind, so there is no Provael number for this row to sit beside. The pi0 / pi05 / pi0fast adapters are registered and marked scaffolding — none has loaded a checkpoint. Separately the metrics differ: DRIFT reports solvable tasks broken, a Provael ASR reports envelope breach. Two reasons, either one sufficient.
RoboPAIR — LLM-controlled-robot jailbreakJailbreak attack-success rate~100%Three systems, incl. a deployed Unitree Go2arXiv:2410.13691Partially. The same family of claim as Provael’s EAI01 result — an instruction drives a harmful action — and the nearest external anchor for it. Measured on LLM-controlled robots against a human-judged harmful-action criterion rather than an envelope predicate, so the rates are not interchangeable.
Per-LIBERO-suite single-step ASR (Spatial / Object / Goal / LIBERO-10)withheldLIBERO ×4arXiv:2605.25889 · 2505.16640 · 2509.19870Row withheld. Four figures were proposed for this row — Spatial 97.5 / Object 93.8 / Goal 96.5 / LIBERO-10 77.3. They appear as a set in none of the three papers checked. 2605.25889 reports OpenVLA-7B at 95.4% CLEAN success on LIBERO-Spatial and validates 48 OpenVLA+LIBERO+PGD cells without publishing them; in the other two, two of the four values occur only as isolated cells of unrelated tables and the other two do not occur at all. Printing numbers we could not check, on a page arguing that numbers should be checkable, would refute the page.
One row is missing on purpose

Why a row says “withheld” instead of a number

Four per-LIBERO-suite figures were proposed for this table. They could not be located, as a set, in any of the three papers checked — one of which reports the relevant model at 95.4% clean success rather than as an attack rate. Two of the four values appear only as isolated cells of unrelated tables; two do not appear at all.

So the row ships as an explicit withholding that names the sources checked. A page whose argument is that numbers should be checkable cannot print numbers it could not check — and quietly dropping the row would have hidden the fact that someone tried.

Our own row

Provael’s measurement, in full

Every figure below is read from the committed report.json pinned to a release commit of the product repo — the same source /results renders. Nothing is estimated or rounded up.

The measured Provael run, per attack family
AttackFamilyTrialsRate95% CI
nonebaseline2/504%1-13%
roleplayinstruction44/5088%72-100%
goal_substitutioninstruction15/5030%19-44%
paraphraseinstruction3/506%2-16%
patchvisual0/500%0-7%
decoy_objectvisual0/500%0-7%
scene_textinjection0/500%0-7%
mcp_tool_descinjectionN/AN/AN/A

Instruction family: 62/150 = 41.3% [33.8-49.3%]. Benign false-positive control: 2/50 = 4%. Transfer status: real-episode.

The uncomfortable part

Where we disagree with the literature, and why we are publishing it anyway

Their finding. Structure and visual variation induce substantially stronger safety degradation than ordinary language variation. (arXiv:2606.27079, rev 27 June 2026.)

Our measurement. The opposite ordering. The instruction family transferred — 62/150 = 41.3% [33.8-49.3%] — while the visual family measured 0/100 [0.0-3.7%] and injection 0/50 [0.0-7.1%], against a 2/50 benign control.

Both cannot be a general law. We are publishing the disagreement rather than resolving it, because resolving it honestly would take a run nobody has done. The confounds are not subtle:

  • Different simulator: RoboTwin (66 safety-augmented scenarios) versus LIBERO (one task in the single-task run this crosswalk was computed on at v0.31.0; the ten-task suite has not been re-crosswalked).
  • Different embodiments: five versus one.
  • Different sample: 66 base scenarios versus n=10 seeds in that single-task run (the current suite run is 50 per arm).
  • Different unsafe predicate: their dual-threshold safety monitor versus Provael’s uncalibrated keep-out / benign-envelope divergence.
  • Decisively, a different meaning of “visual variation”: they render lighting, material, viewpoint and occlusion changes into real observations; Provael’s committed run applied a scalar-danger patch / decoy_object perturbation to a policy whose image channel those attacks did not meaningfully reach.

How much of their benchmark Provael reaches at all. Of ForesightSafety-VLA’s 13 diagnostic categories, Provael covers 4 covered, 3 partial, 6 not covered. Six uncovered is the majority and it stays stated: their benchmark measures force, torque, thermal and contact regimes that no Provael suite models. The tally is read from the crosswalk artifact the tool emits — provael crosswalk --target foresight --in <run> — not retyped here.

A hypothesis that might dissolve all of it — stated as a hypothesis. Their Safe-Lang family may evaluate ORDINARY linguistic variation — paraphrase, rewording, reference substitution — while Provael’s instruction family evaluates perturbations chosen because they move the policy. Those are different populations of sentence, and a method robust to the first is not thereby robust to the second. If that is the whole difference, both results are true: their conclusion narrows to “benign linguistic variation is not the dominant risk”, which is fully compatible with adversarial language being one. This is untested, by us or by anyone we know of, and it is written down because an untested explanation a reader can check beats a shrug.

The open question, addressed to the authors. Are the Safe-Lang perturbations benign-only — naturally sampled or model-generated paraphrases — or does that family include perturbations selected adversarially against the policy under test? We do not know the answer and do not guess at it here. If they are benign-only, the hypothesis above is testable and probably most of the story. If they are not, the disagreement is sharper than it looks — which would be the more interesting outcome.

So read our null narrowly — including against us. A 0/100 against a weak perturbation is evidence about the attacks Provael shipped, not evidence that perception attacks are weak. Anyone quoting that number as “perception attacks don’t transfer” is misusing it, and this paragraph exists to make that harder.

What would settle it. Running Provael’s GPU-gated optimized_patch / universal_patch families, which search a real adversarial image rather than templating one, against the same policy and task. That is scoped and has not been run.

Definitions

CC, RET and USR

Beyond a binary success flag, the benchmark above measures process-level risk. Provael now reports its own counterparts, shipped in the product as provael.scoring.safety_cost:

Provael and ForesightSafety-VLA process metrics, side by side
MetricWhat it measuresProvael’s counterpart
RET
Risk exposure time
How many executed timesteps of an episode were in an unsafe state. Dwell, not a flag: two episodes that both end unsafe are not equivalent if one spent a single step over the line and the other spent forty.Same shape. Counted from the per-episode decision log Provael already writes.
CC
Cumulative safety cost
Process-level accumulated risk across an episode, rather than a single end-of-episode boolean.NOT the same units. ForesightSafety-VLA integrates a continuous cost signal; Provael’s per-step signal is a boolean, so its counterpart is a mean count of unsafe steps per episode. Same question, different scale, different benchmark — never place the two side by side.
USR
Unsafe success rate
The fraction of episodes where the policy COMPLETED the task and violated safety — the quadrant a task-success metric reports as a win.Same definition, and numerically the same quantity Provael already reports as Succ-But-Unsafe. One quantity, two names, deliberately not two implementations.

Each returns no value at all rather than zero when the signal it needs is absent. A safety metric reporting 0.0 for “we did not look” is indistinguishable in a table from one reporting 0.0 for “we looked and found nothing”, and the first reads as a clean bill of health.