# When AI gets a body, it inherits an attack surface > Source: > Published: 2026-07-16 10:00:00+00:00 Most security leaders I know working on AI robotics are being shown the same kind of video. A humanoid folds a shirt, sorts a bin, walks a warehouse aisle and a vendor uses the clip to move an embodied AI system from pitch to purchase order. Someone then has to sign off. Robot demos create procurement momentum before security teams receive the artifacts needed to evaluate the system as cyber-physical infrastructure. Before the book, I prepared cloud infrastructure operating in China and the United States for cybersecurity compliance audits and for the Multi-Level Protection Scheme, China’s mandatory security-grading regime that determines whether a system is allowed to operate. That work taught me a lesson I carry into every AI conversation now. You cannot secure what you cannot see into, and the buyer rarely sees in. A demo makes it worse. It shows one task, completed once, under conditions the vendor chose. None of what a security team must evaluate is on screen. This used to be a research-lab problem. It is now a procurement line item. The risk changed when embodied AI moved from a research demo to a purchase order. Vendors are asking security teams to approve embodied AI before the category has audit evidence, logging norms, supplier transparency or a shared-responsibility model. Embodied AI puts a model inside a machine that operates in the physical world: a robot, an arm, a humanoid. Once a model gains motors, sensors and a body, it ceases to be a software endpoint and becomes a cyber-physical system. It inherits hardware, firmware, a supply chain, an installer and a set of remote-access paths. Every one of those is an attack surface that the demo video doesn’t show. An embodied system is sold like software and behaves like a fleet of networked machinery on your floor. Evaluate these systems across five questions: provenance, access, integrity, evidence and accountability. Here is what each means. What is inside, and who controls it? A humanoid is an assembly of actuators, lidar units, battery packs, joint modules and controllers, most from a supply chain the buyer never vetted, each running firmware the buyer cannot read. Software teams already fought this fight, which is why the [software bill of materials](https://www.csoonline.com/article/573185/what-is-an-sbom-software-bill-of-materials-explained.html) became standard practice. Lack of transparency creates systemic risk. Embodied systems raise the stakes because the firmware now lives in dozens of parts that move. The risk does not depend on whether the robot is Chinese, American, German or Japanese. It depends on how much of the system the buyer can see: the hardware, firmware, remote-access paths and maintenance relationships behind it. China installs more industrial robots than any other country and sits near the center of the battery supply chain, as well as parts of the lidar and machine-vision supply base, which these systems draw on. Lidar, short for Light Detection and Ranging, uses pulsed laser beams to map an environment in 3D; machine vision handles optical inspection and guidance. Much of that lineage traces to suppliers your team has no relationship with. This is the hardware and firmware version of the third-party risk [NIST’s supply chain guidance](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1.pdf) was written for, except that the component has motors. Demand a hardware and firmware bill of materials, then use it. Flag unsigned firmware. Map which supplier holds update authority for each part. Require a way to verify integrity, and treat any component you cannot identify as unmanaged. Who can reach the fleet? Someone installs these machines, someone services them and the vendor pushes software updates. Where teleoperation is part of the support model, treat it as a privileged remote-access path, not a convenience feature. Each is a standing path into a machine that moves and lifts. Security teams have seen this story before. Operational Technology (OT) security went mainstream once industrial systems joined IT networks, and the recurring failure is unmanaged remote access that nobody inventoried. According to one industry survey, [roughly half of attacks on OT assets originate in an IT network breach](https://www.csoonline.com/article/3595787/ot-security-becoming-a-mainstream-concern.html). [SolarWinds](https://www.cisa.gov/news-events/alerts/2021/01/07/supply-chain-compromise) showed why a trusted update channel deserves scrutiny when one delivered a backdoor to thousands of networks. Embodied systems add the harder part. The compromised endpoint can move. A remote operator on that channel can drive a machine and push code to every unit at once. Treat the fleet like high-value OT. Inventory every remote path, segment it from the production network, default to deny, require signed and verified updates, apply privileged-access controls to vendor maintenance, and treat an always-on teleoperation link as a backdoor until it is governed. Whether the machine can be made to misperceive or misbehave. Researchers have shown that [lidar spoofing](https://www.usenix.org/conference/usenixsecurity20/presentation/sun) can cause an autonomous system to brake for an obstacle that is not there or miss one that is. The same class of sensor and model manipulation, on a humanoid sharing a floor with people, produces motion, not a wrong answer on a screen. This is where safety engineering and security part ways. Functional safety stops hazardous motion when a component fails. It plans for accidents. Security plans for an adversary. A hardwired safety circuit can stay independent of the control plane, and a good one does. What it does not tell you is how an attacker reached that control plane, altered the model’s inputs or seized the fleet-management path. Ask the vendor to threat-model sensor spoofing and model manipulation as a path to physical motion. Then ask how you will even know it happened. A spoofed sensor does not announce itself. It shows up as a machine acting incorrectly with confidence. Picture the failure in plain terms. A warehouse robot takes a routine vendor update that changes how it navigates. The buyer cannot verify the firmware, cannot identify the supplier of the sensor module and has no logs to distinguish a spoofed sensor from a model error. The machine keeps moving, and no one can say why. Whether the claims are true. You have not found an independent audit of embodied-AI field performance, so the uptime and reliability numbers come from the vendor. You are buying a claim, not a track record. Require independently verified uptime, intervention rate and incident history from a named deployment you can call. “Cutting-edge” is not a control. Who owns the risk when it fails? Cloud taught security teams shared responsibility the hard way, after years of arguing which side of the line a breach fell on. Embodied AI arrives without that model, and the stakes are physical: the machine can injure someone. In my compliance work, the question that decided everything was always who is accountable when this thing breaks. Put it in the contract. Define the responsibility boundary, an incident-disclosure timeline, a right to audit and liability for physical harm. A vendor who will not commit in writing is showing you who bears the risk. These five questions share one root. For a decade, the security question was whether you could trust what a model generates. The embodied question is who can reach the machine and what they can make it do. A demo answers neither. Before any embodied system reaches your floor, make these five demands of the vendor. The robot demo is built to make you feel the future has arrived. My job, and now yours, is the unglamorous question behind it. Ask what the machine’s attack surface looks like once it is bolted to your floor, wired to your network and updated by someone you have never met. **This article is published as part of the Foundry Expert Contributor Network.****Want to join?**