Understanding Robot Security
AI’s next frontier is increasingly physical. Alongside systems that write, code, and answer questions, developers are building machines that interpret their surroundings and act on them. Google’s Gemini Robotics models translate visual information and instructions into robot movements. NVIDIA’s 2026 announcements span robot learning, simulation, and partnerships with manufacturers including Boston Dynamics and Caterpillar.
As robots gain capabilities, they also gain new ways to be compromised, misdirected, or deceived. Familiar cybersecurity protections remain essential, but robots also require us to examine how digital weaknesses affect perception and physical action. Four layers provide a useful reference:
Physical hardware: Sensors, motors, onboard computers, and accessible ports that need protection against tampering and unauthorized access.
Communications: Wi-Fi, Bluetooth, and network connections, plus the internal messages linking sensors, processors, and actuators. All need protection against interception, impersonation, data tampering, and unauthorized commands.
Onboard software: Sensor firmware, motor-control software, operating systems, and perception and AI software that interpret surroundings and guide actions.
Applications and fleet management: Systems that assign jobs, provide remote control, connect robots to business operations, and distribute software and model updates.
These layers overlap, particularly when AI models combine perception and action. They help us locate weaknesses, while the examples below show how those weaknesses can affect a robot’s behavior.
Familiar security weaknesses in a moving machine
The 2025 UniPwn disclosure illustrates the familiar side. Researchers found weaknesses in the Bluetooth-based Wi-Fi setup interface of Unitree robots, including authentication and command-processing flaws that could give a nearby attacker privileged access. The entry point was wireless communication; the weaknesses were recognizable software-security problems. Robots still need the basics of secure design, access control, and patching.
Deceiving the robot
Other attacks target how a robot interprets the world. Vision-language-action models, or VLAs, connect what a robot sees and what it is told to the movements it makes. A robot may appear to understand a task much as a person does, yet process the situation very differently. As chatbots have taught us, impressive performance can coexist with surprising mistakes. When an attacker deliberately exploits those mistakes, reliability becomes a security concern.
In research published at ICCV 2025, investigators developed small, colorful patches that disrupted VLA-controlled behavior, including in physical robot experiments. Something placed in the camera’s view became a way to influence the machine without breaking into its computer. The controlled experiments demonstrate how a robot’s perception can become an entry point for an attack.
Language can also become an attack route. In a study presented at the 2025 IEEE International Conference on Robotics and Automation (ICRA), the RoboPAIR researchers demonstrated that specially constructed prompts could induce harmful behavior in three tested LLM-controlled robotic systems. Results depended on the system and the attacker’s access, but showed how attempts to bypass a chatbot’s safeguards can translate into physical actions when the model controls a robot.
Independent sensing matters here. Humans combine sight, hearing, touch, balance, and awareness of their bodies to interpret events. Robots may have sensors with capabilities humans lack, yet still depend heavily on a single type of sensory input. A system built around vision and one perception model, for example, may have limited ways to detect deception. Several cameras feeding the same vulnerable model do not necessarily provide an independent check. The important question is whether another source of information can reveal that the robot has been fooled.
At the applications and fleet-management layer, shared software can multiply the impact of a weakness. Imagine an update introducing a flaw into 1,000 robots running the same software. This hypothetical fleet could become susceptible to the same trick at once. People can share misconceptions, but we don’t receive identical overnight software updates. This risk is familiar from managing computer fleets; robotics adds the possibility of many machines making the same physical mistake. Staged rollouts and recovery plans help contain that risk.
Building on OT security
At DataTribe, we have long been involved in security for operational technology, or OT, in industrial and critical infrastructure environments. OT security already addresses the consequences of cyberattacks on physical processes: keeping machinery operating safely, controlling remote access, and managing changes without disrupting production.
Robotics builds on that foundation. What expands the challenge is the combination of physical machinery with AI-driven interpretation and decision-making in less controlled environments. A robot may need to decide what an unfamiliar object is, whose instruction to follow, and how to complete a task. Securing those decisions requires testing how the machine can be deceived as well as protecting its software and connections.
Carnegie Mellon’s CyLab is pursuing this broader problem through its Robotics Security and Privacy Initiative. Its research areas include hardware, software ecosystems, AI, supply chains, testing, and human interaction. The categories will sound familiar to cyber experts; the research challenge is understanding how they combine in machines that sense and act around people.
The four layers give us a way to organize robot security. The harder task is understanding how a weakness in one layer changes what the machine does. Operators need to know what can mislead a robot, what independently limits its actions, and how far a shared weakness could spread. As physical AI expands what robots can do, security must help establish the limits within which they can be trusted to act.
