In 2024, a clip of a small robot called Erbai appearing to persuade 12 larger robots to leave a Shanghai showroom went viral. While the episode was a planned test, it raises a serious question for companies deploying connected robots: could hackers who breach one machine, or the systems that support it, reach an entire fleet?
That risk was examined in a May 5 report by Insikt Group, the research arm of cyber threat intelligence company Recorded Future. The report drew on research into Bluetooth and Wi-Fi set-up systems used by Unitree’s Go2 and B2 quadruped robots, as well as its G1, R1 and H1 humanoid models. It found that the flaws involved hard-coded security keys, weak authentication and a way to send unauthorised commands. An attacker within radio range could gain root-level access, giving them broad control over a robot without physically touching it.
More worryingly, the exploit could spread wirelessly to nearby robots. An attack that begins with one device could therefore affect several machines operating at the same site, potentially interrupting warehouse work, equipment inspections or other automated tasks as operators rush to check, disconnect or return the fleet to manual operation.
In a separate research, Insikt Group found that Unitree’s G1 humanoid robot transmitted sensor and service-state data to an external server every five minutes without the operator’s knowledge. The information could include audio, video and spatial mapping data, which raises concerns when robots operate in factories, laboratories and other sensitive sites.
Singapore will soon have a real-world setting to confront those issues. The new physical AI test bed at Punggol Digital District will allow multiple operators to deploy robots at scale in a mixed-use public area, including for food and parcel delivery, cleaning and security patrols. As AI robots take on work around people and shared facilities, the systems behind them will matter as much as the robots themselves.
See also: Hackers used unpatched routers to access organisations in Singapore, says CSA
Beyond the robot
In many cases, the main security exposure sits in the software and services that run an AI robot fleet. These include staff login accounts, platforms that assign tasks and monitor machines, cloud services that process data and systems that send software updates.
“Historically, attackers tend to choose the most efficient and scalable path available to them. For that reason, I would be more concerned about compromised credentials, management platforms, cloud services, software dependencies or update mechanisms than about an attacker targeting an individual machine directly,” says Juraj Janosik, vice-president of AI at cybersecurity company ESET.
See also: South Korea fines Coupang record US$409 mil for data leak
Moreover, a robot fleet often shares the same login service, management platform or software update channel. “So, if an attacker can compromise one of those layers, they may not need direct access to the machine itself,” Janosik tells DigitalEdge. This means a cyber breach can turn into an operational problem. AI robots used to move goods, inspect equipment, or make deliveries may need to be taken out of service while operators determine which machines and systems have been affected.
The risk exposure is greatest where AI robots have become part of work that cannot be easily stopped. Janosik points to warehouse automation, delivery robots and industrial equipment, where disruption can quickly affect daily operations.
“Most organisations can absorb the loss of one device. The challenge arises when many systems depend on the same software, update mechanism, cloud service or management layer. In those situations, a single weakness can have much wider consequences. Even if no physical damage occurs, the interruption itself can be significant,” he says. For example, a logistics operator using autonomous robots across several facilities could face delays, manual workarounds, safety reviews, and reputational consequences if a trusted software component or central management platform were compromised.
Fixing and tracing
Responding to a security flaw or breach brings its own challenges. The affected machines may need updates, but taking them offline can interrupt the work they are performing. This is especially challenging where AI robots operate near people or handle tasks that cannot easily be paused. “In safety-sensitive environments, patching usually has to be planned, staged and verified rather than applied immediately across the whole fleet,” says Janosik.
Updates can also affect how an AI robot behaves, communicates or performs. Some machines may need to be tested on a limited basis before an update is applied more widely. In certain cases, the system may need to be validated again before returning to service.
Working out what caused an incident can be just as difficult. “Determining whether a machine was compromised, malfunctioned or acted on flawed instructions requires evidence from multiple sources. Investigators may need to look at system logs, network activity, software updates, configuration changes, user interactions and, increasingly, interactions with AI services,” adds Janosik.
To stay ahead of the latest tech trends, click here for DigitalEdge Section
Moreover, the relevant evidence may be spread across systems beyond the robot itself. Janosik explains: “Decisions are no longer made entirely on a single device [as] an autonomous system may rely on cloud-based models, external services, AI agents and third-party tools. As a result, understanding why something happened often means reconstructing activity across an entire chain of systems rather than examining one machine in isolation.”
“This is one reason we have been focusing on visibility across AI workflows. Our recently announced AI security capabilities are designed to help organisations better understand how AI systems are being used by analysing prompts, responses and interactions with external services. The objective is not simply to block threats, but to provide the context needed to investigate incidents, establish what happened and respond appropriately when something goes wrong,” he adds.
Vendor support
One way to prepare for a robot security breach is to settle the terms of vendor support before deployment. “With AI [robots], the relationship with the vendor does not end at deployment. These systems may remain in use for years, and during that time the organisation needs confidence that the vendor can support security updates, disclose issues clearly, and help investigate incidents if something goes wrong,” says Janosik.
Buyers need clarity on how long a product will receive security support, how updates are validated, whether they can be rolled back and what logs or telemetry will be available after an incident. “For autonomous robots, those details are not just technical. They affect operational resilience. At the end of the day, companies should be asking whether they can trust the system not just on day one, but throughout its working life,” he says
