Give an AI a Body and You Give It an Attack Surface

Key points

• Humanoid robots are moving from research labs onto purchase orders before any independent audit standards exist for them.
• 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, then walks a warehouse aisle. Someone signs a purchase order.

Nobody on the security team saw what the demo didn't show.

That's the argument in a detailed analysis 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 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 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's no cryptographic seal proving it hasn't been tampered with, and update authority often sits with a supplier the buyer has no direct relationship with.

Vendors push software updates. Engineers arrive for maintenance. Where remote operation is part of the support model, there's 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: a single corrupted update delivered to thousands of organisations at once. Add motors to that scenario.

The firmware risk isn't theoretical either. Our 10 July story on six flaws in the U-Boot bootloader showed how unsigned startup code in embedded devices can hand an attacker persistent access before the operating system loads. Robots carry the same class of embedded firmware, in dozens of components at once.

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 doesn't exist or ignore one that does. A spoofed sensor doesn't 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's inside the robot (provenance); who can reach it remotely (access); whether its sensors 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 accountability, the guidance is blunt. A vendor who won't commit in writing is showing you who bears the risk.

Should you worry about where the components come from?

Yes, though not only for the reasons usually cited. The CSO Online author notes the risk isn't tied to any single country of manufacture. It depends on how much of the system the buyer can actually see into. Unsigned firmware in a joint controller is dangerous regardless of where that controller was made.

What does a security team actually need before sign-off?

Demand a full hardware and firmware bill of materials naming every supplier and identifying who holds update authority for each component. Treat anything you can't identify as unmanaged. Require cryptographically signed updates. Segment the robots from the main office network with a default-deny policy. Ask for independently verified incident history from a named deployment you can contact directly. Write liability for physical harm into the contract before anything arrives on the floor.

The contract is the control. Everything else is marketing.