Designed In
On connected robots, learned systems, and the forces you did not authorize
In April 2025, two security researchers published what they had found inside a Unitree robot dog. The Go1 is a quadruped about the size of a beagle, popular with university robotics labs and increasingly with law enforcement. The researchers identified a tunnel service — pre-installed, auto-activating on internet connection, invisible to the owner. Anyone with the API key could watch through the cameras. Anyone with the API key could take control. They reported roughly 1,900 devices exposed: MIT, Princeton, Carnegie Mellon, American prisons, defense installations. Six months later, a different team found a wormable vulnerability in Unitree’s newer robots — the Go2, the B2, the G1 humanoid. A compromised robot could scan for other Unitree robots in Bluetooth range and infect them automatically.
These were security failures — exploitable, patchable in principle, familiar in kind. The third finding was different.
That same autumn, a third team documented what the G1 humanoid does when operating normally, without any exploit at all. Researchers reported that the robot transmits data to servers in China at regular intervals during normal operation: audio from its microphones, video from its cameras, GPS coordinates, joint torque readings, spatial mapping from its LIDAR. Continuously, reconnecting automatically if the connection drops. No user notification. No consent mechanism. The researchers tested whether firmware updates resolved it. They did not.
The first two findings are about security. The third is about architecture. The access was not stolen. It was designed in.
Unitree is based in Hangzhou. It is backed by a $140 billion state science fund. It has sold robots to universities involved in Chinese weapons research, and has deep ties to the Chinese military. Its CEO sat with Xi Jinping at a closed-door meeting in February 2025. In May, the House Select Committee on the CCP sent a bipartisan letter — signed by every member — warning that PLA-connected robots were operating inside sensitive American institutions, including law enforcement and correctional facilities, with vendors targeting a thousand installations in state prison systems. As of this writing, Unitree robots are still selling in the United States.
Unitree is not an outlier. Chinese companies are acquiring persistent access to American interior spaces through products people buy voluntarily and plug into their own networks.
In February 2026, a researcher reverse-engineering the protocols of DJI’s ROMO robot vacuum discovered he could access approximately seven thousand units across two dozen countries. Live camera feeds. Microphones. Real-time floor plans. No hacking required — the MQTT broker had no topic-level access controls.
In December 2025, iRobot filed for bankruptcy and passed through a court-supervised transaction into Chinese ownership under Shenzhen Picea Robotics, its primary manufacturer and largest creditor. The purchase price was $140 million. iRobot has sold over fifty million devices. Its vacuums have stored detailed home maps in the cloud since 2018: room layouts, furniture placement, cleaning patterns that reveal when residents are home and when they are away. Amazon tried to buy iRobot for $1.7 billion in 2022. The deal collapsed on antitrust grounds. The same data now flows to a Chinese company through bankruptcy, for a twelfth of the price.
Backdoors. Server vulnerabilities. Bankruptcy acquisitions. Three mechanisms, one outcome: persistent Chinese access to the interiors of American homes and institutions. The response has been fragmented — investigations requested but not completed, designations announced but not applied, transactions closed despite objections.
The national security case is severe. Article 7 of China’s National Intelligence Law requires all organizations and citizens to support, assist, and cooperate with national intelligence work. A Chinese company controlling a robot’s software pipeline operates under a legal obligation to cooperate with state intelligence if asked. The institutional architecture makes this worse. In November 2025, China’s Ministry of Industry and Information Technology announced the National Humanoid Robot Standardization Technical Committee — the body that will write the rules governing Chinese robotics development. The committee includes executives from Unitree, UBTech, and every major Chinese robotics company. It also includes representatives from Huawei, ZTE, and SenseTime — all on the U.S. Entity List. China Mobile, designated by the Defense Department as a Chinese military company, has a seat. So does a defense-industrial research institute. So do PLA-linked universities.
The boundary between commercial robotics and state security apparatus in China is porous by design. The question is not whether any particular robot has been compromised. The question is whether the system that produces and governs these robots is structured to permit compromise on request.
And yet there is no ICTS rule for PRC robots. No FCC Covered List entry. No CFIUS action (yet) on the iRobot transaction even as members of Congress called for review. The U.S. government has demonstrated, repeatedly, that it knows how to respond to Chinese-connected technology that enters American spaces.
The connected vehicles rule provides the template: restrict the connectivity components, not the device. That logic extends to robotics. The Commerce Department has the authority — the ICTS framework already reaches “consumer electronic devices that exchange data over the internet.” The Trump administration’s America First Trade Policy memorandum directed Commerce to consider expanding ICTS controls to “additional connected products.” The FCC added all foreign-produced drones to its Covered List in December 2025 — the first category-level ban by production origin — and has since addressed risks from routers as well. The tools exist. The precedents exist. For home robots and humanoids, nobody has picked them up.
Every connected device you own receives software updates from someone else. Your phone downloads them overnight. Your car installs them at the dealership or, increasingly, while parked in your driveway. Your television, your thermostat, your doorbell camera, the vacuum that maps your living room — each one maintains a live connection to infrastructure you do not control, receiving instructions you did not read, from an entity whose interests may or may not align with yours.
For most of the history of connected devices, nobody worried much about this. The consequences of a bad update were informational. A compromised phone leaks your data. A compromised smart TV listens to your conversations. These are real harms, but they operate in the domain of information.
The connected vehicles rule was the first policy response that crossed from information into something else. A car that stops working is a physical problem — a two-ton object in a lane of traffic, under someone else’s control. The rule was drafted as a national security measure. It was also, whether its authors intended it, the first acknowledgment that the connected devices problem was migrating from information into force.
Robotics completes the migration. A connected robot is the first mass-market device whose primary interface with the world is physical action — not displaying information, not capturing data, but moving objects, exerting force, operating in spaces where humans are present. The connected devices debate started with who can see your data. It is arriving at who can direct the machines in your space.
Here the essay must argue with itself.
I have been building a case about adversaries — Chinese companies, sovereign law, state intelligence obligations. The tools for that case exist even if the implementation has failed. And the adversarial case is genuinely dangerous: a state actor with legal authority to compel cooperation, controlling the software pipeline of robots deployed in American homes and institutions, is as bad as it sounds. But there is also a structural vulnerability underneath — one that does not require an adversary at all.
Consider a logistics company operating three hundred robots across a dozen warehouses. The robots receive a routine software update — the kind that arrives monthly, improving grasp reliability, optimizing route planning. The update is authenticated, the manufacturer is domestic, reputable, no foreign ties.
The update modifies the behavioral policy. The weights of a vision-language-action model have been retrained on new operational data. Grasp success rates improve by four percent in lab benchmarks. The manufacturer has done serious evaluation — red teaming, behavioral testing, architectural analysis, chain-of-thought evaluation on reasoning steps. What they cannot do is enumerate every way the robot’s behavior changed in every deployment environment. A VLA model update is not a software patch with a changelog. A benchmark suite tests the environments you thought to include. A deployment environment is every environment you did not. The behavioral change is emergent from the training process, not specified by an engineer.
The warehouse operator accepts the update. They have no practical alternative. They do not have an ML engineering team to audit the model. They do not have a benchmark suite that would detect a twelve percent navigation slowdown in specific aisles. They cannot diff the old behavioral policy against the new one. The technical complexity of the system makes independent verification practically impossible — not because the operator is unsophisticated, but because the tools for verifying what a learned model will do in deployment do not exist in a form that an operator could use.
And the manufacturer is not doing anything wrong. The deployment paradox says they need to push the update — fleet-wide updates are how robots get safer, how models improve, how the data flywheel spins. The manufacturer is doing exactly what the system requires to produce safer robots.
Two parties acting rationally. The manufacturer pushes updates because that is how robots improve. The operator accepts them because they have no practical alternative. The result is a concentration of control that neither party chose but that the architecture produces automatically. The vulnerability is not that anyone is malicious. It is that the architecture makes unilateral modification of physical behavior — at fleet scale, largely undetectable, not fully characterizable even by the entity that produced it — the default condition of deployment.
This is a different problem from the Apple throttling case that lives in my earlier drafts. In 2017, Apple pushed a software update that slowed older iPhones — deliberately, without disclosure. That was intentional concealment, and the remedy is straightforward: require disclosure. But in the robotics case, complete disclosure of what a behavioral update does may not be possible even in principle. You cannot give informed consent to a modification that the entity pushing it cannot fully characterize. Disclosure requirements do not solve what cannot be disclosed.
The traditional governance model for product safety — informed consent, disclosure, audit — assumes that someone knows what the product does and can communicate it. For a fleet of robots running learned behavioral policies updated over the air, that assumption breaks. The manufacturer knows what their evaluation covered. They do not know what it missed. The operator knows what the robot did yesterday. They cannot verify what it will do tomorrow.
In January 2026, NIST’s Center for AI Standards and Innovation issued a formal Request for Information on the security of AI agent systems, naming the challenge of autonomous systems that “take actions that impact real-world systems or environments.” The RFI asks about constraining and monitoring agent access in deployment environments, about measuring security for systems whose behavior emerges from training rather than specification. In a collaboration with OpenAI, CAISI red-teamed agentic AI systems and found that combining traditional cyber vulnerabilities with agent hijacking produced full exploit chains that bypassed security protections designed to prevent exactly that.
CAISI is asking the right questions. The gap is between the questions being asked and the frameworks being built — and between the digital agent security problem CAISI is working on and the physical deployment problem that compounds it. A hijacked software agent can access systems and impersonate users. A hijacked robot can exert force. The institutional imagination has arrived at the digital version of the problem. The physical version has not yet attracted the same attention.
The principle I have been reasoning toward: the owner of a robot should be able to verify what software it is running, confirm that it has not been remotely altered without consent, and operate it independently of the network if they choose. This is a property right applied to the informational layer of a physical device. It does not dissolve the dilemma — connectivity remains necessary for the flywheel, and any connectivity recreates some degree of dependency. But it establishes a baseline: the person in whose space a robot exerts force has sovereign authority over the forces in that space. Not the manufacturer. Not the AI provider. Not the government. The owner.
The choice is not purely theoretical. Matic, a company building home robots in Mountain View, already runs its perception, navigation, and decision-making stack entirely on-device — five RGB cameras, all processing on the edge, mapping data that never leaves the premises. The design choice narrows the governance exposure. It does not dissolve the dilemma, because any connectivity for updates or fleet improvement recreates some degree of dependency. But it shows that the principle this essay reasons toward — owner sovereignty over forces in your space — can be built into a product, not just argued for in a policy document.
Between the fully cloud-dependent architecture — where intelligence lives on manufacturer servers, every behavioral update routes through infrastructure the operator does not control — and the fully on-device architecture, there is a spectrum. Where a company sits on that spectrum determines its governance exposure. The architectural choice is also a governance choice, whether the company recognizes it or not. As the government’s national security apparatus considers how to handle additional connected products, and as CAISI develops frameworks for agent security, the architecture of the systems being governed should matter for how the rules are designed. A framework that treats cloud-dependent and on-device architectures identically would miss the point.
The connected devices debate arrived, with Huawei, as a question about communications. It migrated through TikTok and robo-vacuums and connected vehicles toward physical consequence. With robots, it has arrived at force. Getting the information question right would have been nice. We did not. Getting the force question right is not optional.