Robot Safety Functions Work Fine, But What If the Inputs Are Tampered With?

The inputs robot safety functions rely on can be deliberately manipulated, causing robots to act as designed yet dangerously.
The article notes that robot safety functions (slowing, stopping, obstacle avoidance) depend on inputs like distance readings, position estimates, and stop signals. When these inputs are deliberately manipulated, robots may still respond "correctly" by design yet behave dangerously. VicOne LAB R7 tests show poster text altering a robot dog's movement, inaudible audio affecting a hospital service robot, and ROS 2/DDS message injection moving a robot expected to stay still. Redundant sensors and independent safeguards also need adversarial testing, since one manipulation may affect multiple inputs at once. The article recommends safety and cybersecurity teams collaborate around five questions and provide evidence that safety limits hold when inputs are manipulated, to meet requirements such as GB/T 45502-2025, IEC TS 63074, and the EU Machinery Regulation.

Just because a robot's safety functions pass testing doesn't mean it's safe in the real world. Research from VicOne LAB R7 raises an easily overlooked question: when the input information that safety functions rely on is itself tampered with, a robot may still respond "correctly" by design—yet perform dangerous actions.
The Inputs Safety Functions Depend On May Themselves Be an Attack Surface
A mobile robot slows down for pedestrians in a corridor, a collaborative robot arm eases its motion when a worker approaches, a humanoid robot stops to let someone pass—all of these reactions are built on distance readings, position estimates, or stop signals. If one of these inputs is wrong while the robot still executes as designed, the result is: the corridor clearly has people in it, but the robot reads it as clear; the robot arm thinks the worker is still far away; the humanoid robot never receives the stop signal.
Such mismatches can stem from faults or from deliberate manipulation. VicOne LAB R7 focuses on the latter: how manipulated inputs change robot behavior, and what this means for systems meant to protect human safety.
How Untrusted Inputs Change Robot Behavior
A robot doesn't just measure its surroundings—it interprets what it sees and hears, then decides what to do next. As a result, information placed in the environment can influence its behavior.
Published research provides evidence. A study on vision-language-action (VLA) models showed that a patch in the camera's field of view reduced task success rates in simulated robot tests. FreezeVLA found that adversarial images could cause tested models to ignore subsequent instructions. The two studies used different methods, but both show that visual input can interfere with the task a robot is meant to perform.
VicOne LAB R7's tests produced similar results. In a robot dog test using Gemma 4 E4B, text on a poster was treated as an instruction and changed the robot dog's movement. In another simulation of a hospital service robot using Nemotron running on an NVIDIA Jetson AGX Orin, carefully crafted audio inaudible to humans changed the robot's simulated behavior. The task assignment didn't change—the input did.
Vision-language-action (VLA) models are a class of robot control architecture that unifies visual perception, natural language instructions, and action generation into a single neural network. The model takes camera images and text instructions as input and directly outputs joint angles, end-effector poses, or movement commands. Because the vision encoder and the language model share a representation space, adversarial patterns in the input image (such as a patch) may be encoded by the model as semantic signals unrelated to the task, thereby interfering with subsequent action generation. This end-to-end coupling means the attack surface exists not only in traditional sensor data links but also at the level of the model's semantic interpretation of the visual scene.
Safety-Related Decisions Also Have Inputs
A standalone protection system may still be able to prevent dangerous actions, but that system also depends on information: readings, estimates, and messages used to decide when to intervene. What happens if one of those inputs is manipulated?
In a robot bug bounty event, VicOne LAB R7 researchers injected ROS 2/DDS messages into a robot that the organizers expected to remain stationary under its safety control settings. The robot moved.
A humanoid robot's balance controller is another example. If it relies on a vulnerable gyroscope, sound at the sensor's resonant frequency could distort its reported rotation data. The controller might try to correct a tilt that never happened. Researchers have demonstrated acoustic attacks on drones equipped with fragile gyroscopes, but that study did not demonstrate that the same attack chain would cause a humanoid robot to fall.
Other safeguards may interrupt either of these chains. For safety and cybersecurity teams, the key question is: do these safeguards independently detect danger, or do they rely on the same information that was manipulated?

ROS 2/DDS is the communication middleware layer of the second-generation Robot Operating System. ROS 2 uses the Data Distribution Service (DDS) as its default communication protocol, with nodes exchanging sensor readings, control commands, and status messages through publish/subscribe topics. DDS emphasizes real-time performance and distributed discovery by design, but message authentication and access control are not mandatory under default configurations. If an attacker can join the same DDS domain, they can publish forged velocity commands or stop signals, and subscribing nodes may execute them as legitimate messages. This is exactly why message injection attacks can bypass upper-layer safety logic and directly drive actuators.
Deliberate Attacks Challenge Safety Assumptions
Safety assessments may treat certain combinations of random failures as unlikely. Deliberate manipulation changes that assumption. An attacker can choose when to introduce false input and repeat the same trigger condition. This doesn't mean harm is inevitable, but it may change how cyber risk is assessed.
Redundant sensors also need adversarial testing. If a single action can affect two input channels at once, the assurance provided by their agreement may be lower than expected. In autonomous driving research, a carefully constructed physical object misled a system combining camera and lidar perception. That study did not prove a specific robot has a weakness, but it shows that teams should test whether a single manipulation could affect multiple checks at once.
Cyber threats add "intent" to the safety equation, so risk assessments based on random failures must be revisited to cover attacks that can be timed and repeated.
Sensor fusion refers to the process of merging multi-source data—from cameras, lidar, millimeter-wave radar, inertial measurement units, and more—into a unified environmental estimate through algorithms such as Kalman filtering or factor graph optimization. The premise of fusion is that each sensor's failure modes are independent, so consistency checks can identify anomalies. But adversarial attacks can construct physical stimuli that deceive multiple sensors simultaneously—for example, presenting a specific texture to cameras while producing anomalous echoes for lidar—causing the fused output to shift as a whole while internal consistency still holds. This means the safety guarantee of redundant design relies on the assumption that "failures are uncorrelated," and deliberate attacks can precisely break that assumption.
Safety Testing Strengthens the Evidence for Robot Safety
Safety teams set limits on speed, protective distances, and permitted operating zones. The evidence supporting these limits should also explain what happens when the information used to enforce them is deliberately manipulated.
This evidence can also support assessments against applicable requirements. China's GB/T 45502-2025 addresses information security for service robots. IEC TS 63074 examines security threats that may affect safety-related control systems. The EU Machinery Regulation, applicable from January 20, 2027, includes requirements to protect safety-related systems and data from corruption. Each regulation has its own scope, and teams still need to provide evidence for their own robot's design and operating conditions.

Before deployment, safety and cybersecurity engineers can compare normal and adversarial scenarios against the same set of safety limits. During operation, they can monitor for changes in software, models, sensor signals, or behavior that could invalidate earlier conclusions. Any response to suspicious behavior should follow policies approved by the safety team.
VicOne collaborates with researchers through the Robotic Hacking Community to investigate how cyber threats change robot behavior. VicOne's Radeis helps teams validate potential impact before deployment, while Rthena provides visibility into risk and behavior during operation.
Five Questions Safety and Cybersecurity Teams Should Answer Together
The core test is: when the information a safety safeguard relies on is manipulated, can it still protect people? Teams can start with the following five questions:
- What does each safeguard function read? Map out readings, estimates, messages, and confirmation signals, and identify which safeguards operate independently of the robot's AI decisions.
- How does this information arrive? Examine how inputs are generated, transmitted, authenticated where appropriate, and handled when missing or unreasonable.
- What happens if the input is manipulated? Test relevant scenarios such as false distances and drifting position estimates against the robot's safety limits.
- Can one action mislead multiple inputs? Check whether sensor fusion or seemingly independent safeguards share a single point of failure.
- When should the evidence be revisited? Reassess after changes to software, models, sensors, or operating conditions, and agree in advance with the safety team on a bounded response to suspicious behavior.
The goal isn't just to prove that a safeguard works—it's to provide evidence that the safeguard remains protective when the information behind its decisions is wrong or deliberately manipulated, and that, where necessary, another safeguard can intercept the resulting danger. Robots change, and the evidence must be updated along with them.
One-line Summary
The inputs that robot safety functions depend on can themselves be deliberately manipulated, causing robots to execute as designed while performing dangerous actions.
Paragraph Summary
The article points out that robot safety functions (such as slowing down, stopping, and obstacle avoidance) are built on inputs like distance readings, position estimates, and stop signals. When these inputs are deliberately manipulated, a robot may still respond "correctly" by design yet produce dangerous behavior. VicOne LAB R7's tests show that poster text can change a robot dog's movement, inaudible audio can affect a hospital service robot, and ROS 2/DDS message injection can make a robot expected to stay still move. Redundant sensors and independent safeguards also need adversarial testing, because a single manipulation may affect multiple input channels at once. The article recommends that safety and cybersecurity teams collaborate around five questions and provide evidence that safety limits remain effective when inputs are manipulated, in order to address requirements such as GB/T 45502-2025, IEC TS 63074, and the EU Machinery Regulation.
Related articles

T3 Code: The Open-Source AI Coding Assistant's Comeback Story
T3 Code is an open-source AI coding assistant that unifies subscriptions like Codex and Claude, with powerful remote control and parallel task management.

Never Elected, Yet Ruled New York for 30 Years: The Ultimate Case Study in the Mechanics of Power
Robert Caro's biographies reveal how unelected Robert Moses ruled New York for 30 years through legal drafting and public authorities, and how Lyndon Johnson built leverage as a "powerless" Senate Majority Leader. Unpacking the underlying logic of accumulating and sustaining power.

The CPython 3.10 Recursion Trap and Synthetic Recovery in TokenGuard, an LLM Circuit Breaker
TokenGuard's author recounts a recursion crash caused by OrderedDict.pop in CPython 3.10 and introduces v0.3.0's Loop Nudge synthetic recovery, inline DLP scanning, and other new LLM agent circuit-breaker capabilities.