How one breached AI robot can disrupt an entire fleet

In 2024, a clip of a small robot called Erbai appearing to persuade 12 larger robots to leave a Shang­hai showroom went viral. While the episode was a planned test, it raises a serious question for com­panies deploying connected robots: could hackers who breach one ma­chine, 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 com­pany Recorded Future. The report drew on research into Bluetooth and Wi-Fi set-up systems used by Uni­tree’s Go2 and B2 quadruped robots, as well as its G1, R1 and H1 human­oid models. It found that the flaws involved hard-coded security keys, weak authentication and a way to send unauthorised commands. An at­tacker within radio range could gain root-level access, giving them broad control over a robot without physi­cally touching it.

More worryingly, the exploit could spread wirelessly to nearby robots. An attack that begins with one de­vice 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 hu­manoid robot transmitted sensor and service-state data to an exter­nal server every five minutes with­out the operator’s knowledge. The information could include audio, vid­eo and spatial mapping data, which raises concerns when robots operate in factories, laboratories and other sensitive sites.

Singapore will soon have a re­al-world setting to confront those is­sues. 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 deliv­ery, cleaning and security patrols. As AI robots take on work around peo­ple 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 ex­posure sits in the software and servic­es that run an AI robot fleet. These include staff login accounts, plat­forms that assign tasks and monitor machines, cloud services that pro­cess data and systems that send soft­ware updates.

“Historically, attackers tend to choose the most efficient and scala­ble path available to them. For that reason, I would be more concerned about compromised credentials, man­agement platforms, cloud services, software dependencies or update mechanisms than about an attacker targeting an individual machine di­rectly,” says Juraj Janosik, vice-pres­ident of AI at cybersecurity compa­ny 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 op­erational problem. AI robots used to move goods, inspect equipment, or make deliveries may need to be tak­en out of service while operators de­termine 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. Jano­sik points to warehouse automation, delivery robots and industrial equip­ment, where disruption can quickly affect daily operations.

“Most organisations can absorb the loss of one device. The challenge aris­es 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 signifi­cant,” he says. For example, a logis­tics operator using autonomous ro­bots across several facilities could face delays, manual workarounds, safety reviews, and reputational con­sequences if a trusted software com­ponent 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 ro­bots 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 ap­plied 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 return­ing to service.

Working out what caused an inci­dent can be just as difficult. “Deter­mining whether a machine was com­promised, malfunctioned or acted on flawed instructions requires evidence from multiple sources. Investigators may need to look at system logs, net­work activity, software updates, con­figuration 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 be­yond the robot itself. Janosik explains: “Decisions are no longer made en­tirely on a single device [as] an au­tonomous system may rely on cloud-based models, external services, AI agents and third-party tools. As a re­sult, understanding why something happened often means reconstruct­ing 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 work­flows. 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