When it is online, behaviours and intelligence arrive as signed updates — the robot you unbox is the robot at its least capable.
The risk sits in the same sentence. An update that goes wrong on a device in someone’s living room is a machine that stopped working, in a room you cannot reach. Most of the engineering effort in the update pipeline goes into making that outcome negligible.
Every update is cryptographically signed, and the robot verifies the signature before it applies anything. An unsigned or tampered update is refused outright. If the signing key is unavailable, the deployment fails rather than going out unsigned — the failure mode is a release that does not ship, never a release that ships unverified.
An applied update that misbehaves rolls back automatically to the previous version. For fleets, a release goes to a small percentage of robots first, then a larger one, so a fault is found on a handful of machines rather than all of them at once.
We would rather a robot refuse an update than apply a bad one. A refused update is an inconvenience; a bricked robot in an elderly person’s hallway is a different kind of event altogether.