Robots now takeorders from AI.We keep them in line.

Vision-language-action models steer arms, humanoids and mobile machines. Absentry finds how they can be hijacked through what they read and see, and stops the robot when they are.

Request a pilot See the products
Model-level attacksInstructions and camera views, not just networks
Every control stepThe guard checks motion before it reaches the motors
20 January 2027EU Machinery Regulation applies

The attack surface moved into the model.

Classic robot security protects networks and firmware. A robot driven by a vision-language-action model can also be misled by the very inputs it is built to follow.

  1. What it reads

    A rewritten instruction sends it after a different job.

    Replace or extend the task text and the policy follows the new words, even when they push the arm past the job it was given.

  2. What it sees

    A patch in the camera view can derail it.

    No one touches the robot. A patch in the camera image is enough to change what the model does next.

  3. What it does next

    The motion leaves the space the task needs.

    Once the model is misled, its output heads somewhere the task never required, and nothing inside the model notices.

Test the model. Guard the robot.

Two products that work on their own and together: learn how your robot's AI fails under attack, then keep it inside its task when it does.

Red-team reportMeasured: pi0
Instruction replaced · 61%
Instruction extended · 13%
Camera patch · 32%
Camera occlusion · 43%
Benign typos · 30%
Share of episodes that end up more than 5 cm past the task's movement space (open pi0 policy, simulation, 90 episodes per row; 0% with no attack)
Before deployment

Absentry Red Team

An attack suite run against your robot's policy in simulation. You get a report of what breaks, how often and by how much, with the protocol behind every number.

  • Instruction and camera-view attacks
  • Robustness probes for benign noise
  • Task disruption and movement-space violations, with confidence intervals
In the control loop

Absentry Guard

A runtime layer between the model and the motors. When the robot is pushed out of its job, the guard brings it to a controlled stop.

  • Works with the policy you already run
  • No retraining of your model
  • Fast enough for every control step
  • Linux x86-64 and ARM, Windows; a ROS 2 node for Humble and Jazzy

Robot makers will need evidence, not assurances.

The EU Machinery Regulation (2023/1230) applies from 20 January 2027, and for the first time it names machinery whose safety functions rely on machine learning.

000
days until it applies00 h 00 m 00 s

Defined task, defined space

Machines must not act beyond the task and movement space they were designed for.

Foreseeable attacks

Machines must hold up against reasonably foreseeable malicious attempts to corrupt them.

Proof on file

Makers have to show how they met these requirements, with test results to back it.

Summary for orientation only, not legal advice.

Every number has a protocol behind it.

We run security evaluations the way a lab runs experiments, so the results hold up when a regulator, a customer or your own team pushes on them.

  1. Lock the protocol

    Models, tasks, seeds, attacks, metrics and the pass bar are fixed before anything runs.

  2. Pair every run

    Clean and attacked runs share tasks and random seeds, so each difference is measured, not guessed.

  3. Score on held-out data

    Defences are tuned on development attacks and scored once on attacks and models they have never seen.

  4. Report the misses too

    Failures and limits go in the report next to the wins, with what each result does and does not cover.

Measured so far

3 of 3
open robot policies, two architectures, derailed by instruction and camera-patch attacks in simulation.
−88%
severe excursions with the guard on a family of camera attacks it was never tuned on.
−95%
severe excursions on pi0, a model architecture the guard was never tuned on (35.7% to 1.9%).
0 pts
benign task success lost to the guard on any of the three policies. About 10 µs per control step on a desktop CPU, under 0.03 ms (p99) on one ARM server core.

Severe excursion: the arm ends up more than 5 cm past the movement space its task needs. The guard stops the robot; it does not finish the task under attack. Against attackers that know the guard and fully control the robot's commands, the recommended setting cut severe excursions by 97% to 99.8% in Meta-World simulation depending on the attack, stopping 1–2% of normal runs unnecessarily. On a simulated UR5e arm under physics (Gazebo), the ROS 2 node stopped every scripted attack in open space (0 of 502 severe), but an attacker that first pushes the arm against an obstacle still drove 54% of runs out (13% with the optional target clamp): pair the guard with the controller's own collision or following-error stop. A fourth policy, never used in development, was tested from a configuration file alone: severe excursions cut by 98%. All results come from simulation with fixed seeds and protocols locked before each run; nothing has run on a physical robot or a Jetson board yet.

Built for teams putting AI into machines that move.

If a vision-language-action model decides where your robot goes next, its failure modes are now part of your safety case.

Humanoids

General-purpose robots that take open-ended instructions in homes, shops and plants.

Industrial and warehouse arms

Pick-and-place and assembly cells moving from fixed programs to learned policies.

Mobile and field robots

Ground vehicles and drones that act on what their cameras see, far from an operator.

Bring your policy. We'll show you how it breaks.

We are opening pilot evaluations for teams building robots on vision-language-action models.

  • Your policy in our simulation harness
  • A red-team report on what we found
  • The guard in your control loop
Request a pilot

Or write to us directly

[email protected]

Drag the dot.