Industry News

Physical AI cybersecurity gaps let attackers alter robot behavior

Backdoor, Bluetooth and prompt attacks can change robot behavior while every component still works, and a vendor is urging cyber testing across the robot lifecycle.

Rethinking Robot Safety as Physical AI Meets Cybersecurity

A coffee mug was enough. In a 2025 study called GoBA, researchers used an ordinary object as a hidden trigger for a backdoored robot model and reported a 97 percent attack success rate, with no loss of performance on clean inputs. The result sits at the center of a growing argument that physical AI cybersecurity belongs inside robot safety assessments, not alongside them.

The argument comes from VicOne, a Tokyo-headquartered company that sells cybersecurity software and services for vehicles and robots. It frames the problem as a change in the question safety engineers ask. The traditional question is whether a machine stays safe when something breaks. The new one is whether it stays safe when an attacker changes what it sees, decides or does while nothing appears to have failed.

Three layers where a robot can be compromised

VicOne divides the attack surface into training, system infrastructure and runtime perception. Each layer has documented examples.

The training layer starts with BadNets in 2017. That work showed a model could behave normally on most inputs and fail only when a specific hidden trigger appeared. In one example, a subtle pattern made a stop sign read as a speed limit sign, while the model's behavior on other inputs was unchanged.

The technique has since moved from classification to action. At NeurIPS 2025, researchers presented BadVLA, a backdoor attack on Vision-Language-Action models, the class of models that lets a robot see, interpret instructions and produce coordinated movement. When a trigger was present, the robot's action trajectory deviated. Without it, the model largely kept its normal task performance. The backdoor survived task transfers and model fine-tuning. GoBA, the coffee mug study, followed the same pattern.

The infrastructure layer concerns the software around the model. In September 2025, researchers disclosed UniPwn, a Bluetooth exploit chain affecting quadruped and humanoid robots from a major manufacturer. Hardcoded cryptographic keys allowed traffic to be decrypted. Authentication checks were bypassed. Command injection gave root-level execution. The exploit is described as wormable, meaning a compromised robot could scan for nearby units and potentially spread across a fleet.

Middleware is a further exposure. Vulnerabilities in ROS 2 and DDS-based systems can allow arbitrary code execution, or let an attacker use unauthenticated topics to send malicious commands. With enough access, an attacker could override motor commands or swap AI model weights without touching the model architecture. In VicOne's own demonstration, chaining three wireless exploits triggered uncontrolled robot behavior within 60 seconds.

The runtime layer needs neither a firmware change nor a network breach. RoboPAIR, from 2024, showed that carefully structured prompts could push LLM-controlled robots into unsafe trajectories. BadRobot found that in several cases a robot verbally refused a dangerous command while its motion controller carried it out anyway. VLAttack showed that an adversarial patch in the camera's view could reduce a VLA model's task success rate to zero. FreezeVLA showed that a single adversarial image could freeze a robot's decision loop, leaving it unresponsive to later instructions.

Why standard checks can miss these failures

What links these cases is that the hardware keeps working. The camera functions, the model runs and the controller responds, yet the behavior is unsafe because the robot is acting on manipulated perception, reasoning or commands. A model can pass pre-deployment testing and still produce corrupted behavior once a hidden trigger shows up in operation.

VicOne argues that functional safety covers failures and unexpected operating conditions, while cybersecurity extends assurance to deliberate manipulation. It says the two are complementary and that cybersecurity does not replace functional safety.

Humanoid robots and people walking through a modern city street with glass buildings.
IEEE Spectrum

What a lifecycle approach would involve

The company proposes assurance at three stages. During design, teams identify which cyber risks could invalidate the assumptions behind intended behavior. Before deployment, they test whether realistic attacks can push a robot outside its task or safety boundaries. In operation, monitoring checks whether cyber events are starting to affect physical behavior, contains the affected path and keeps the robot operating safely where possible.

VicOne's tooling maps onto those stages: AI model and vulnerability scanning, simulation-based validation, and continuous monitoring. One product, Radeis, is a physical AI safety validator for NVIDIA Isaac Sim that tests how adversarial visual inputs change robot behavior before deployment. For runtime, the company describes security event correlation, behavioral-impact assessment and policy-bounded response supported by edge AI. The stated aim is to isolate a compromised path without halting an entire fleet.

Diagram of end\u2011to\u2011end AI robot security from development to operation monitoring
IEEE Spectrum

Analysis: what this changes and what remains unproven

The strongest point in this body of work is structural. Most of the cited attacks do not break a component. They alter the data or commands a working component relies on. A safety case built only on component availability and fault tolerance would not register them. That gap is real regardless of who is selling the remedy, and it grows as robots rely on learned models that cannot be fully inspected.

The evidence is uneven, though. The attack research, including BadNets, BadVLA, GoBA, VLAttack and FreezeVLA, comes from academic work and is specific. The defensive claims come from a vendor describing its own products. The material does not provide independent test results for Radeis, detection rates for the monitoring approach, or false-positive rates. Nor does it show that policy-bounded containment keeps a robot safe in practice. Those are open questions.

There is also a comparison to draw. Pre-deployment adversarial testing in simulation can only find triggers its test inputs happen to cover. A backdoor keyed to an object like a mug is, by design, hard to find by sampling. Scanning model files and weights is a separate task from scoring behavior, and the material does not say how well either catches a dormant trigger. Runtime monitoring may be the more realistic backstop, but it depends on detecting behavioral drift fast enough to matter for a moving machine.

The UniPwn case is the most concrete reason for urgency. It involves conventional flaws, hardcoded keys and unauthenticated commands, that existing security practice already knows how to prevent. That suggests part of the physical AI cybersecurity problem is ordinary engineering discipline, not new science. The harder, still unsolved part is showing that a learned model stays inside its safety boundaries when someone is deliberately trying to push it out.