Give an AI a Body and You Give It an Attack Surface
Warehouses and factories are buying humanoid robots before security teams have a single audit standard to work from. Here is what that means for the people on the floor.
Key points
- Humanoid robots are now moving from research labs onto purchase orders, before any independent audit standards for them exist.
- Each robot carries a supply chain of hardware parts and firmware (the low-level software baked into chips) that buyers rarely get to inspect.
- About half of attacks on industrial machinery originate from a breach of the company's ordinary IT network, according to industry survey data.
- Vendors are offering uptime and reliability figures with no independent verification behind them.
- Security professionals say the contract, not the demo video, is where accountability must be settled.
The pitch usually starts with a video. A humanoid robot folds a shirt. It sorts a bin. It walks a warehouse aisle. Someone signs a purchase order.
Nobody on the security team saw what the demo did not show.
That is the argument laid out in a detailed analysis first published by CSO Online, written by a security professional who spent years preparing cloud systems in China and the United States for formal compliance audits. The core warning is plain: buyers are being asked to approve embodied AI, meaning AI models installed inside physical robots that move and act in the real world, before the category has any shared audit standards, logging norms, or agreed responsibility model.
A software bug gives you a wrong answer on a screen. A compromised robot gives you a machine moving incorrectly through a space that contains people.
How do attackers actually get into a robot?
Through the same doors they use everywhere else: software updates, remote maintenance sessions, and the company's own internal network.
Every humanoid is an assembly of actuators (the motors that drive movement), lidar units (sensors that use laser pulses to build a 3D map of the surroundings), battery packs, and joint controllers. Most of those parts come from suppliers the buyer has never vetted, running firmware the buyer cannot read. That firmware can be unsigned, meaning there is no cryptographic seal proving it has not been tampered with, and update authority often sits with a supplier the buyer has no direct relationship with.
The access problem compounds this. Vendors send software updates. Engineers arrive for maintenance. Where remote operation is part of the support model, there is a live path into a machine that lifts and moves. One industry survey found that roughly half of attacks on operational technology, the term for industrial control systems and physical machinery connected to a network, begin with a breach of the company's ordinary office network. The SolarWinds incident showed what a poisoned update channel looks like in practice: a single corrupted update delivered to thousands of organisations at once.
Add motors and sensors to that scenario.
Researchers have already demonstrated lidar spoofing, where an attacker feeds false signals to a robot's sensors, causing it to brake for an obstacle that does not exist or ignore one that does. The article's author frames the stakes directly: a spoofed sensor does not announce itself. It shows up as a machine acting incorrectly with confidence.
The analysis sets out five questions any security team should demand answers to before sign-off: who controls what is inside the robot (provenance); who can reach it remotely (access); whether its sensors and model can be manipulated (integrity); whether the vendor's performance claims are independently verified (evidence); and who is contractually liable if someone gets hurt (accountability).
On that last point, the guidance is blunt. A vendor who will not commit in writing is showing you who bears the risk.
What should organisations buying or considering this technology do?
Demand a full hardware and firmware bill of materials, naming every supplier and showing who holds update authority for each component. Treat any part you cannot identify as unmanaged. Require that all updates are cryptographically signed. Segment the robots from the main office network with a default-deny policy, meaning nothing connects unless explicitly permitted. Ask the vendor for independently verified incident history from a named site you can contact directly. And write the liability for physical harm into the contract before anything arrives on the floor.
