Absentry

Security for robots that take their orders from AI models.

Vision-language-action models now steer robot arms, humanoids and mobile machines. Absentry tests how easily they can be hijacked through what they read and see, and keeps the robot inside its job when they are.

Movement space Start Task goal Stopped

Normal run. The arm follows its task inside the movement space.

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.

What it reads

A replaced or extended instruction can send the robot after a different task, or past the one it was given.

What it sees

A patch or object placed in the camera view can derail the policy without anyone touching the robot.

What it does next

Once the model is misled, the motion it outputs leaves the space the task needs, and nothing in the model notices.

Test the model. Guard the robot.

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

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

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.

20.01.2027

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.

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 running pilot evaluations with 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