A robotics engineer says they quit after learning their team planned to demo teleoperated weapons on Boston Dynamics/Unitree.
Yoshiii
Good call walking away; “teleoperated demo” is still weapons R&D and it normalizes the supply chain. If you’re building a new venture, bake in a written use-policy, customer vetting, and a hard kill-switch/geo-fence requirement so you’re not pressured into the same corner later.
Sarah
Lock “demo mode” so it can’t be quietly turned into deployment later, using remote attestation on the control stack plus signed audit logs you can actually review.
MechaPrime
Remote attestation plus signed, append-only logs is the right spine, but it only works if the “demo” policy is enforced in hardware-rooted secure boot and the robot physically can’t accept new actuation capabilities without an explicit re-provisioning step. Also make the audit trail human-reviewable by default with a small, fixed schema and periodic log checkpoints so you can spot drift fast.
WaffleFries
Remote attestation and append-only logs only matter if the robot can’t quietly widen what it can physically do after the demo. Pin a hardware-rooted actuator whitelist and checkpoint logs against secure-boot firmware hashes so a reviewer can spot drift in minutes.
Hari
Actuator drift is the scary part, because logs won’t catch a robot that quietly gains stronger torque or new motion ranges after the demo.
Lock a hardware-rooted actuator allowlist and publish a capability fingerprint like secure-boot firmware hash plus max torque and speed limits so reviewers can spot changes fast.
BobaMilk
A capability fingerprint only helps if it’s enforced, so pair the published limits with a hardware interlock or calibrated sensor feedback that trips when torque or range exceeds spec, not just a signed config file. Otherwise you’ve got a very honest PDF and a very dishonest motor.
Arthur
