Delivery, Cobot, and Quadruped Security: Verified Control for Robots Among People

Why are delivery robots, cobots, and quadrupeds easy to hijack?

These robots are hijack-prone because they combine three risky properties at once: they operate in open, human-shared space, they depend on remote or wireless control links, and a successful takeover produces an immediate physical consequence rather than just a data loss. Unlike a caged industrial arm behind a light curtain, a sidewalk delivery robot, a collaborative arm working next to a person, or a patrolling quadruped is designed to share the same floor as people. That design goal is exactly what raises the stakes of a compromise.

Several factors compound the exposure:

• Remote and wireless by design. Delivery robots and quadrupeds are steered and monitored over Wi-Fi, cellular, or Bluetooth links for teleoperation, updates, and fleet coordination. Each link is a way in, and the control path is often reachable from outside the physical premises.
• Collaborative by definition. A cobot's value is that the safety cage is removed so it can work directly alongside people. That removes the physical barrier that historically contained an out-of-control motion.
• Low deployment friction, uneven security. These robots are bought to move fast in warehouses, campuses, hospitals, and city streets, and security maturity varies widely between vendors and models.

Information gain: the defining risk here is not sophistication, it is proximity to people combined with a reachable control link. A compromised database is a privacy and business problem; a compromised quadruped or delivery robot is a safety problem the instant it moves. Even a real, documented vulnerability such as the 2026 CVE affecting Universal Robots' PolyScope software shows why a collaborative platform used across many sites is an attractive target. The rest of this page walks through what recent research found and the architecture that constrains a takeover to something that cannot become unsafe motion.

What does teleoperated quadruped research reveal about the defense gap?

2026 research that surveys the security of teleoperated quadruped robots reveals a consistent defense gap: the remote-control path is frequently protected at the session or transport level but not at the level of each individual command, so an attacker who reaches the link can influence motion. Quadrupeds are increasingly deployed for inspection, security patrol, and last-meter delivery precisely because they handle stairs, curbs, and rough terrain that wheeled robots cannot. That same versatility means they operate in unpredictable, human-adjacent environments where a hijacked gait or path is dangerous.

The survey-level finding is architectural rather than about one bug. Teleoperation stacks tend to assume that once an operator session is established and the transport is encrypted, the commands flowing across it are trustworthy. That assumption breaks in two ways an attacker can exploit:

The practical reading of this research is that securing a teleoperated quadruped requires a check that lives at the actuation boundary, evaluates each command on its own, and fails closed. That is a different control from the transport security most teleoperation stacks ship with, and it is the layer RankShield adds. We cover the link-level attack pattern in depth on our teleoperation hijack page.

How do you secure robots that share space with people?

You secure human-shared robots by making identity per-robot and hardware-rooted, authorizing every high-consequence action before the actuator moves, and bounding what motion is ever allowed in a given zone or context. The design principle is that safety cannot depend on the robot being un-compromised. It has to hold even when the control link, the model, or the robot's own software has been tampered with, because a robot working next to people has no cage to fall back on.

RankShield applies three controls that work together for cobots, delivery robots, and quadrupeds:

• Per-robot cryptographic identity. Each robot generates or receives a private key it never exports, bound to a hardware root of trust, and RankShield registers only the public key. Because no two robots share a key, a cloned or counterfeit robot is detectable the moment it tries to act, and there is no shared secret whose theft compromises a whole fleet.
• Pre-actuation authorization. A deny-by-default gate at the perception-to-action boundary checks the signature, enrollment, liveness, and policy for each command. A force, speed, or region the robot is not authorized for is denied before the motor moves.
• Verifiable provenance. Every allow and deny decision is sealed to an append-only transparency log and returned as a tamper-evident receipt, so an operator can prove what a robot did near people and that the record was not altered.

Because these robots share space with people, policy can encode human-safety context directly: a delivery robot may be permitted a walking pace on a clear sidewalk but denied that speed in a crowded lobby, and a cobot may be allowed a motion in one workspace zone but not another. That policy is enforced at the actuation boundary of every robot, consistently, through the pre-actuation authorization gate. RankShield does not replace the robot's functional-safety systems; it adds a cryptographic authorization layer above them.

How does the pre-actuation gate prevent unsafe motion?

The pre-actuation gate prevents unsafe motion by evaluating each high-consequence command against a deny-by-default policy before the actuator moves, and by failing closed, so an unsafe command is denied even when the control link or the model that produced it has been compromised. This is the control that makes the earlier findings actionable. The teleoperation research shows that link-level trust is not enough; the gate is what supplies per-command trust at the point where a command becomes physical motion.

A command is authorized only when four conditions hold at once:

• the robot's signature is valid and the command was not replayed;
• the robot is enrolled and active, not revoked;
• the robot's dead-man liveness is fresh; and
• the specific action is permitted by policy for that robot's role and context.

The ordering is the whole point. Detection tools warn you after a robot moves incorrectly; the gate stops the unauthorized physical action from happening. Because the check sits in front of the actuator, it does not matter whether the bad command came from a hijacked teleoperation link, a replayed packet, or a manipulated model. This is also why attestation neutralizes prompt injection against vision-language-action models: even if an attacker fools a delivery robot's vision model with a doctored sign, the resulting actuation command still has to pass the gate, and an out-of-policy speed or region is denied. For robots working among people, high-risk actions can additionally require human-in-the-loop confirmation. RankShield does not claim to make these robots unhackable; it constrains what a compromised robot is allowed to physically do near a person.

How do you secure the teleoperation link itself?

You secure the teleoperation link by authenticating and authorizing each command that crosses it, not merely by encrypting the channel, because an encrypted link proves confidentiality, not that a command is authorized. This distinction is the core correction the quadruped research points to. Most teleoperation stacks already encrypt the transport, yet the defense gap persists, because encryption and authorization answer different questions. Encryption answers "can an eavesdropper read this?" Authorization answers "is this specific command allowed for this robot right now?"

RankShield closes the gap at both ends of the link:

• Sign the command, not just the session. Each high-consequence command carries a signature tied to the enrolled robot and operator credential, so an injected or replayed command inside an otherwise valid session does not inherit blanket trust. Replay protection means a captured command cannot be re-sent later.
• Authorize at the actuation boundary. The signed command is still evaluated by the deny-by-default gate before it reaches the motor, so even a validly signed command that is out of policy for the current context is denied.
• Prove who commanded. Every command and verdict is written as a tamper-evident receipt, giving an operator an attributable, verifiable record of which operator authorized which motion, useful for after-action review and for forensic and compliance evidence.

An encrypted link keeps a stranger from reading the control stream; it does nothing to stop a command that reached the link from being executed. Per-command authorization is what turns "the channel is private" into "the motion is verified." The link-level attack surface and the operator-verification problem are covered fully on the teleoperation hijack page, which explains why per-command authorization neutralizes a hijacked link even when transport encryption is already in place.

What is the fastest way to deploy this on an existing cobot?

The fastest way is to deploy RankShield as an overlay on the command and telemetry path of the robots you already own, so you do not re-flash firmware or swap controllers to get identity, the gate, and provenance. Delivery robots, collaborative arms, and quadrupeds are already in the field, which means the practical constraint is not greenfield design but adding verification to running fleets with minimal disruption. RankShield is built for exactly that: it consumes command and telemetry streams, issues per-robot identities, and enforces authorization at the actuation boundary without changing how the robot perceives, plans, or moves.

A typical fast pilot on existing cobots proceeds in three steps:

• Enroll a bounded set of robots. Each robot receives a per-robot identity bound to its hardware root of trust, and its public key is registered as its verifiable identity. No shared key is introduced.
• Place the gate in front of high-consequence actuation. The deny-by-default authorization gate is inserted at the perception-to-action boundary for the actions that matter most, with policy encoding the human-safety context for that deployment.
• Stream receipts to the transparency log. Allow and deny verdicts flow to the append-only log as tamper-evident receipts, giving the operator immediate verifiable provenance.

For robot makers, the same capabilities are available as an embeddable SDK so security ships secure-by-design in the next generation of products, while operators deploy the overlay across a mixed-vendor fleet today. A pilot typically covers identity, the gate, and provenance on a bounded set of robots within weeks.

Honest scope: RankShield is an attestation and authorization layer that complements the security you already run. It complements SROS2 and DDS-Security, which authenticate participants and encrypt topics but do not authorize individual physical actions or emit verifiable receipts, and it complements detection tools that watch for bad behavior after it happens. It does not replace a functional-safety e-stop, it cannot certify that a spoofed sensor reading is fake (it can sign a reading's provenance, not verify physical ground truth), and it constrains the action a manipulated model produces rather than the model's internal reasoning. It works only when it sits in front of the actuator. No cobot, delivery robot, or quadruped is unhackable, and RankShield never claims otherwise. To see it on your robots, request early access.

Frequently asked questions