powering productive workplaces
Front page
FeatureProductivity AI1h · 09:08 BST · 13 min read

How Humanoid Robots Can Become Enterprise Rogue Insiders

Humanoid robots could expand the enterprise attack surface by moving through sensitive sites while collecting sensor data and connecting to cloud services. Security leaders must secure their networks, data flows, update mechanisms and AI-model dependencies before deployment

Humanoid

Humanoid robots are increasingly being positioned as a solution to labour shortages, repetitive work and operational inefficiency in warehouses, factories, data centres and other enterprise settings.

But the technology is raising a more consequential question for buyers: can they safely deploy machines that move through sensitive sites, collect rich environmental data, connect to cloud platforms and receive remote software and AI-model updates?

The concern is no longer theoretical.

Security researchers have disclosed flaws in commercial robot platforms that could enable unauthorised access or expose sensitive data. Separately, a high-profile data-governance failure involving development versions of iRobot’s Roomba robot vacuum showed how imagery gathered by a sensor-equipped robot can travel beyond the setting in which it was collected.

Meanwhile, the Trump administration’s recent restrictions on new foreign-made humanoid robots have intensified the debate over whether the origin of an advanced robot presents a national-security or enterprise-risk issue.

For business buyers, however, the security challenge is broader than the country in which a robot was assembled. A modern humanoid is a mobile cyber-physical platform: it may contain cameras, microphones, LiDAR, thermal sensors, wireless connectivity, AI inference tools, cloud links, third-party software components and over-the-air update mechanisms.

That combination creates a potential path to surveillance, operational disruption, data theft or movement between corporate IT and operational tech (OT) environments. It also introduces a newer form of dependency: a robot’s most valuable capabilities may rely on an external AI model whose availability could be affected by a vendor decision, export control or regulation.

The practical takeaway is obvious. Enterprises must secure the entire robotic stack – the machine, its data, its networks, its remote-access arrangements, its update path and its AI-model dependencies – before it is allowed to move through a sensitive workplace.

From Fixed Machinery to Mobile Data Collection

Traditional industrial robots are already a cybersecurity concern.

Robot controllers, remote-access systems and legacy industrial networks can contain vulnerabilities. An attacker who gains control of a fixed robotic arm or related OT system could disrupt production, damage equipment or create safety risks.

However, most traditional robots have a relatively constrained operating model. They are installed in a known location, perform a defined task and are often isolated within a fenced production cell or a dedicated industrial network.

Humanoid robots and other autonomous mobile systems are designed to work differently. They can travel through environments built for people, including warehouse aisles, factory floors, loading bays, offices, corridors, stockrooms and potentially server or data-storage areas.

To move safely, they need to understand their surroundings. That can involve cameras, microphones, LiDAR, depth sensors, thermal imaging, mapping tools and environmental telemetry. Those capabilities are commercially useful. They can also create a substantially richer data-collection footprint.

“Humanoid robots add mobility to the data-gathering process,” said Stanislav Kazanov, Head of GRC, Cybersecurity & Sustainability and Head of Data at digital engineering company Innowise.

“The takeaway for those in charge of operational technology risk is a shift from worrying about fixed machine failure to planning for active data capture via multiple sensors.”

Kazanov said that, unlike fixed robotic arms “confined to obsolete factory sub-networks,” humanoids may move through corporate buildings, logistics centres and data-storage sites while collecting high-resolution LiDAR, thermal imagery and audio that can build a picture of physical layouts and operations.

That information can be highly sensitive. Mapping data may reveal restricted areas, access routes, security controls, high-value inventory locations, equipment configurations or operational bottlenecks. Cameras can capture screens, documents, whiteboards, ID badges and visitor details. Audio may record conversations. Thermal data can reveal occupancy patterns or machinery use.

The issue is not that every robot will automatically collect and export every available form of data. Responsible deployments should minimise what is captured and tightly control where it goes. The risk is that a compromised platform, an overly permissive fleet-management system or a poorly governed data pipeline can turn legitimate sensors into tools for reconnaissance.

“If a robot is compromised, it does not only present a danger of physical collision or damage but rather act as a rogue insider,” Kazanov said.

That is the central shift for security leaders. A compromised device does not necessarily need to defeat an external perimeter. It may already be inside the facility, trusted by staff, connected to a fleet-management service and physically able to observe areas that an external attacker cannot reach.

With weak network controls, the robot could become a route for unauthorised wireless activity, credential capture through visual data, site mapping or data exfiltration through connected cloud systems. Robust segmentation can prevent a mobile robot from reaching sensitive OT assets. But mobility makes poor segmentation and unmanaged sensor data far more consequential.

The Real-World Warning Signs

The robot-security risk has already moved beyond academic theory.

In 2025, security researchers disclosed issues involving Unitree’s G1, a commercially available humanoid platform. Research around the device identified security and privacy concerns that included Bluetooth-related weaknesses and questions around telemetry.

The significance of the case is not that every Unitree robot has been compromised in the wild, nor that humanoid robots are inherently unsafe. It is that a commercial humanoid platform has already been subject to public security scrutiny over the precise areas that enterprise buyers must assess: remote access, wireless communications, telemetry, data exposure and fleet-level risk.

The risk posed by robot-generated data has also been demonstrated outside industrial settings.

In 2022, MIT Technology Review reported that images captured by development versions of iRobot’s Roomba J7 robot vacuum had been sent to data-labelling contractors and subsequently shared online. The images included sensitive household scenes. iRobot said the units involved were development devices and were not intended for retail sale.

It was not a conventional hacking incident. But it is an important example of a related failure: data from a camera-equipped robot passing into a third-party AI-development and labelling ecosystem without sufficient protection.

For enterprise buyers, the lesson is direct. Whether a data leak arises from a cyberattack, weak vendor governance, excessive collection, poorly controlled training data or human error at a subcontractor, the operational outcome may be similar. Sensitive imagery, audio, maps or telemetry may leave the environment in which the robot was deployed.

Fixed industrial robots have also shown why robotics cannot be treated as a simple hardware-security problem. Security research involving industrial robot controllers, including ABB systems, has found vulnerabilities capable of exposing controller functions or enabling unauthorised manipulation under certain conditions.

The difference with humanoids and other mobile autonomous robots is the combination of those established OT security risks with a roaming physical presence, more extensive sensing and cloud-connected AI capabilities.

Not Just a Humanoid Issue

Elvis Nava, co-founder and CTO at Mimic Robotics, cautioned against isolating humanoids as a uniquely risky category.

“I wouldn’t single out humanoids, but any kind of ‘smart’ or AI-driven robot,” he said.

That includes autonomous mobile robots, quadrupeds, warehouse platforms, inspection machines, drones and other connected devices that merge movement, perception, artificial intelligence and remote management.

Nava said the newer generation of robots has more extensive telemetry by default. “So ‘hacked’ robots could indeed allow attackers for more access to sensitive information,” he said.

Their attack surface is also greater than that of older automation, Nava added, because their software stacks include more components: cloud integration, AI inference systems, over-the-air software updates and model updates.

Every one of those elements is useful. Cloud platforms allow enterprises to monitor fleet performance, diagnose faults and manage large deployments. Remote support can reduce downtime. Over-the-air updates can fix vulnerabilities and improve performance. Model updates can improve navigation, perception and task handling.

But each element creates dependencies that require governance.

Enterprises need to know which data is processed on the robot and which is transferred elsewhere. They need to understand whether video, audio, location data, LiDAR scans or diagnostic logs reach a vendor cloud; where that cloud is hosted; how long data is retained; and whether data is accessible to subcontractors or used to develop AI systems.

They must also understand who can remotely access a robot fleet, how that access is approved and recorded, and whether the provider can alter a robot’s software or model configuration without the customer’s explicit control.

The solution is not simply to disconnect every robot from the outside world.

“It is absolutely crucial for the capabilities of these new AI-driven robots that remote support, remote control and updates are allowed,” Nava said.

“We need to face the challenges head on without compromising on features.”

That is the tension enterprises must resolve. A robot that cannot receive security patches could become less safe over time. A fleet with no route to specialist support may be harder to maintain safely. But unrestricted vendor access, opaque update processes and broad outbound connectivity are also unacceptable in a sensitive site.

The goal should be secure, limited and auditable connectivity – not blanket isolation or blanket trust.

The Overlooked Risk: Model-Access Dependency

Modern robots can depend not only on hardware and software suppliers but also on access to AI models. That introduces a resilience issue that is distinct from a cyberattack.

Nava pointed to the possibility that access to a key model could be restricted by regulation, an executive order, export control or vendor policy for particular countries, industries or users. He cited the recent temporary restriction of access to Anthropic Fable outside US nationals as an illustration of the broader concern.

The specific conditions of any policy action will vary, and enterprises should verify the relevant legal and contractual position for each model and jurisdiction. But the broader risk is clear: a robot may be physically deployed, connected and secure, yet lose essential capability if the model it relies upon becomes unavailable.

If the AI model is central to vision, reasoning, planning, speech, remote assistance or task execution, that interruption could materially affect operations.

For a non-critical pilot, this may be an inconvenience. For a business that has incorporated robots into warehouse operations, manufacturing workflows, security rounds or data-centre processes, it could become an availability and continuity problem.

Organisations should therefore assess model-access dependency as part of procurement. They should map each external model or cloud service the machine depends on, identify the jurisdictions and policies governing availability, and understand the fallback position if a service is suspended or restricted.

This should include contractual questions. What notice will a vendor provide before a material service change? What happens to customer data? Can the customer export logs and configuration data? Is there a safe local mode? What support is available if the robot needs to migrate to a different model, cloud platform or management environment?

Hardware Origin Matters – But It Is Not Enough

The Trump administration’s restriction on new foreign-made humanoid robots has made country of origin a prominent procurement issue. In critical environments, buyers have legitimate reasons to understand where a robot is made, who controls it, which jurisdictions govern its data and what geopolitical risks may affect support.

Nava said country of origin matters particularly in relation to the AI models deployed on robots.

But hardware origin cannot be the sole measure of safety.

Kazanov said that treating hardware provenance as the central indicator of operational safety is “substandard” because commercial products of all origins depend on third-party components and over-the-air firmware pipelines.

A robot assembled in one country may use sensors from several others, open-source libraries maintained globally, a cloud provider based elsewhere and models hosted or controlled in another jurisdiction. The real security and resilience picture lies in the complete chain of dependencies.

That means buyers need evidence, not assumptions.

They should ask vendors for a software bill of materials, documentation covering critical hardware and firmware dependencies, details of model providers and third-party services, data-flow maps, hosting locations and remote-support arrangements. They should seek transparent vulnerability-disclosure processes, clear incident-notification commitments and verifiable information about how software, firmware and models are signed and updated.

The decisive questions include whether a robot can operate locally, what its safe degraded mode looks like, who has administrator-level access to fleet-management systems, and whether the customer can control or restrict sensor data leaving its site.

The Non-Negotiable Security Baseline

Kazanov said enterprises deploying mobile autonomous systems should begin with strict architectural controls, including zero-trust networking and micro-segmentation.

In practical terms, a robot fleet should not be dropped onto a general corporate network. It should sit within a dedicated, segmented environment where communications are denied by default and only explicitly approved connections are permitted.

A robot may need to communicate with a local fleet-management system, an approved cloud service or a vendor support channel. That does not mean it should have unrestricted access to corporate IT, business applications, safety systems or OT networks.

Outbound traffic should be limited to approved destinations, ports and protocols. Unexpected transfers, unusual connections and changes in communication patterns should be monitored. Remote vendor access should be time-bound, individually approved, strongly authenticated and fully logged.

Identity and access management is equally critical. Each robot, human operator, administrator, service account and vendor engineer should have a distinct identity and the minimum permissions necessary for their role. Shared accounts and always-on remote access create avoidable risk.

Update integrity is another essential control. Kazanov said updates should include hardware-rooted cryptographic verification. Enterprises should require a chain of trust that verifies firmware, operating systems, applications and AI-model packages before they are installed. Unauthorised or tampered software should not be accepted.

Governance matters alongside cryptography. Organisations should maintain an accurate inventory of deployed robots, their software and model versions, installed sensors, network connections and ownership status. Major changes should be tested before broad rollout, and buyers should have a documented rollback plan if an update introduces a fault, security weakness or operational problem.

Data minimisation must be designed into the deployment. Robots should collect only what they need to perform their defined task. Where feasible, sensitive data should be processed at the edge rather than transmitted as raw imagery, audio or mapping data to an external cloud.

Kazanov recommended local processing that removes or obscures sensitive documents, badges and biometric information from stored sensor records. Even where full local processing is not possible, enterprises need rules for encryption, access permissions, retention periods, data deletion and third-party sharing.

Finally, organisations need a rehearsed incident-response plan that covers both cyber and physical outcomes.

Kazanov called for mechanical kill switches and manual command-and-control systems. These controls cannot guarantee that a data breach will not occur, and they cannot reverse data already transmitted. But they are vital containment measures. If a robot behaves unpredictably, receives suspicious commands or loses contact with its authorised systems, trained staff need a dependable way to move it into a safe state.

That process should be tested with security, OT, safety, facilities and operations teams – not left as a promise in a vendor manual.

The security conversation around humanoid robots should not become a reason to dismiss the technology. AI-driven robots could improve productivity, perform hazardous or repetitive work and help businesses address genuine workforce constraints.

But the industry must acknowledge that the same features that make robots valuable – mobility, perception, cloud links, AI models, remote support and continuous updates – also expand the enterprise attack surface.

rate this story
helps rank stories across uc today
The discussion0 takes · attributed & checked

Does this reflect your experience?

opening the room…
Read nextordered by techtelligence · every pick explained
same beat · Productivity AI

Oracle Turns AI Agents Loose on Talent Management Tasks

13 Aug 2026
same beat · Productivity AIKPMG’s AI Productivity System Goes Global12 Aug 2026same beat · Productivity AIGoogle Gemini Reaches One Billion Monthly Users as AI Assistant Race Accelerates12 Aug 2026