Key points in this blog
- A robot can remain operational while cyber manipulation changes what it perceives, decides, or does, making cybersecurity part of safety assurance for Physical AI.
- Research such as the UniPwn disclosure and CHAI study demonstrates how trusted system interfaces and visual inputs could redirect robot behavior without triggering a conventional fault.
- Cyber-safety assurance must continue after deployment as software, models, environments, and threats evolve.
Robot safety engineering has long centered on one question: Can the robot remain safe when something goes wrong? Functional safety turns that question into safeguards, fallback modes, operating boundaries, and emergency stops designed to keep faults and failures from becoming hazards.
While that question remains essential, Physical AI introduces another: Can the robot remain safe when an attacker makes something wrong look right?
The distinction matters because a compromised robot may continue operating without crashing, stopping, or raising a fault. A robot can stay operational and still become unsafe — and that changes what safety assurance must cover.
For Physical AI, cybersecurity is not a parallel discipline to safety engineering. It is part of it. When the inputs, models, interfaces, and services a robot depends on can be manipulated, the safety question is no longer only "what if something fails?" It is also "what if something trusted is made to behave wrongly?" If cyber manipulation can change what the robot perceives, decides, or does, cybersecurity becomes part of assuring its safe physical behavior.
How trusted interfaces and inputs can redirect robot behavior
Robots depend on digital inputs, components, interfaces, and services they treat as legitimate. UniPwn and CHAI demonstrate two different ways that trust can be exploited:
UniPwn: A trusted interface enables system compromise
In September 2025, independent researchers Andreas Makris and Kevin Finisterre disclosed UniPwn, a vulnerability chain affecting the Bluetooth Low Energy (BLE) Wi-Fi configuration interface in Unitree Go2, G1, H1, and B2 robots. The chain combined hardcoded AES parameters shared across devices, an authentication bypass, and command injection to root-level command execution. The researchers described the attack path as wormable because a compromised robot could scan for other affected robots within BLE range and attempt to compromise them without further attacker action.
What this proves: a trusted system interface can be the path from network access to behavior-affecting compromise — without any conventional fault being raised.
CHAI: A trusted visual input redirects robot behavior
CHAI, revised in February 2026, embeds deceptive natural-language instructions, such as misleading signs, within a robot's visual environment. The authors evaluated the attack against drone emergency landing, autonomous driving, aerial object tracking, and a real robotic vehicle. The camera continues to capture its environment, and the model continues to produce an inference, but text within the scene can influence the model's intermediate commands and redirect the robot's behavior.
What this proves: trusted perception can be manipulated to redirect physical behavior — and the robot's systems may register no fault throughout.
UniPwn reaches robot behavior through a trusted system interface; CHAI reaches it through trusted perception and reasoning. Both show how a trusted pathway can move a robot beyond its intended task or operating boundaries.
These cases expose a gap in safety assurance: continued operation does not necessarily mean intended behavior. Addressing that gap does not replace fault analysis, functional safety, or physical safeguards. It broadens the conditions under which safe behavior must be demonstrated.
For Physical AI, trust extends beyond individual components to the dependencies that shape what a robot perceives, decides, or does. A weakness becomes safety-relevant when exploiting it can alter any part of that chain.
The operational consequences for robot makers and OEMs are direct:
- A safety case built only around faults can be incomplete if it excludes adversarial manipulation of inputs, models, or control paths.
- Validation limited to fault injection misses behavior-shaping cyber paths that produce no conventional error.
- Software and model updates after deployment can invalidate earlier safety assumptions — without any hardware change.
- Fleet-scale dependencies mean a single device-level weakness can affect behavior across an entire operation.
Addressing these consequences requires a continuous assurance loop across four stages:
- Map the digital dependencies that shape robot behavior — inputs, models, software, services, and control paths — and connect them to the safety case.
- Validate the physical consequences of realistic attack paths before deployment, not just whether an exploit works.
- Defend safety assumptions at runtime by connecting cyber signals with behavioral context and coordinating proportionate responses.
- Reassess after each operational cycle, feeding field findings back into the next round of testing, remediation, and release.
What cyber-safety assurance requires in practice
Once a weakness can influence physical behavior, it can no longer be assessed only as a technical security finding. Robotics teams must evaluate how it could affect the robot's intended task, operating boundaries, and safety functions throughout its lifecycle.
Map the dependencies that shape physical behavior
Cybersecurity by design should begin with the trust relationships behind robot behavior, not only a list of exposed interfaces, components, and known vulnerabilities.
Teams should identify which inputs, models, software, services, and control paths can influence how the robot behaves. Exposure alone does not determine safety relevance. A reachable component may have little influence on physical outcomes, while a model, update mechanism, or command channel with limited access may directly affect movement or task execution.
The key question is: If this trust assumption is violated, what could the robot be made to do?
Connecting that question to the safety case helps teams evaluate cyber risk by its possible physical consequences and pushes the analysis past one machine. Shared firmware, common perception models, telemetry channels, and fleet-management services can turn a device-level weakness into a fleet-wide behavioral risk.
Validate the physical consequence, not only the exploit
Mapping shows where trust resides. Validation shows what happens when that trust is violated. For example:
- Visual or sensor input can remain technically valid while being crafted to mislead perception.
- A model can produce a plausible output under a hidden trigger.
- An authorized interface can carry a command the system should never have trusted.
While these conditions may not produce an obvious fault or network anomaly, they can travel through the robot's normal perception, decision, and control pathways.
Simulation allows teams to reproduce many of these conditions before hardware, people, or live operations are exposed. It cannot eliminate the sim-to-real gap, so teams should revalidate safety assumptions as the system moves toward deployment.
Proving that an exploit works is only part of the assessment. Teams must determine whether it changes task execution, weakens a safety function, or moves the robot beyond its approved operating boundaries. That requires a validation approach that can reproduce adversarial conditions — manipulated inputs, hidden model triggers, unauthorized commands — before hardware, people, or live operations are exposed.
VicOne Radeis supports this process by assessing risks across the robot stack and using attack-driven simulation to validate whether vulnerabilities, manipulated inputs, or AI model risks could change intended behavior before release.
Video 1. VicOne Radeis tests how robots perceive and act under adversarial conditions before real-world deployment.
Defend safety assumptions after deployment
Pre-deployment validation provides evidence at a point in time. After release, software updates, model changes, new vulnerabilities, and real-world conditions that did not appear during testing can all shift the safety picture – without any hardware change.
Runtime assurance should connect cyber signals with behavioral and operational context to determine whether an event is changing what the robot perceives, decides, or does — not merely flag an anomaly — and guide a proportionate response.
Rather than stopping every robot whenever a security event appears, teams should contain the affected path while preserving safe operation where possible. This helps avoid unnecessary consequences for safety, productivity, and service continuity.
At fleet scale, this means identifying which robots are affected, assessing whether the issue could propagate, and coordinating containment without unnecessarily disrupting the entire operation. That requires runtime visibility that connects security signals with behavioral and mission context — not just anomaly detection in isolation.
VicOne Rthena supports runtime assurance by connecting cyber signals with behavioral, mission, and fleet context. It helps teams determine whether a risk is affecting intended behavior and coordinate policy-bounded responses across affected robots.
Closing the cyber-safety loop
Robot safety has always been about keeping machines within intended operating boundaries when the unexpected happens. Physical AI adds an adversarial dimension: nothing may appear broken even when the information, model, or command the robot trusts has been manipulated. That shifts the standard teams must meet — from keeping machines within intended boundaries when something fails, to keeping them there even when something trusted is made to behave wrongly.
If a digital compromise can change what a robot perceives, decides, or does, cybersecurity is no longer only about protecting data or systems. It becomes part of assuring safe physical behavior.
Meeting that standard requires a continuous loop: design around the digital dependencies that shape behavior, validate the physical consequences of realistic attack paths before deployment, and defend the assumptions that safe operation depends on once robots are in the field. Findings from operation must then inform the next cycle of assessment, testing, remediation, and release.
The goal is not simply a more secure robot. It is a robot designed to maintain safe behavior even under adversarial cyber conditions.
Frequently asked questions
Why may traditional functional safety approaches not cover all Physical AI cyber risks?
Traditional functional safety approaches alone may not fully address adversarial cyber risks in Physical AI. While these approaches remain essential for managing faults, failures, and unintended operating conditions, cyber manipulation can alter trusted inputs, models, or services while a robot continues to operate without an obvious fault. Cyber safety assurance complements functional safety by evaluating whether such manipulation could change what the robot perceives, decides, or does.
When does a cybersecurity weakness become relevant to robot safety?
A cybersecurity weakness becomes safety-relevant when exploiting it could change what the robot perceives, decides, or does. This includes risks that alter task execution, weaken a safety function, or move the robot beyond its intended operating boundaries — even when no conventional fault is detected.
How do Radeis and Rthena support continuous cyber-safety assurance?
Radeis assesses and validates cyber-related safety risks before deployment, while Rthena detects and helps contain behavior-affecting risks during operation. Together, they support an assurance loop in which operational findings can inform future assessments, test scenarios, remediation, and release decisions.
For a deeper look at the cybersecurity risks and defense strategies shaping autonomous robotics, download VicOne LAB R7's white paper "Securing the Rise of AI Robots: Cyber Risks, Real-World Threats, and Defense Strategies."
To learn more, explore VicOne’s approach to Physical AI cybersecurity.