Security

Teleoperation means a person on the internet can move a physical machine. Every robot proves its identity with cryptography rather than a shared secret, every session is encrypted, and nothing needs to be opened on your network for any of it to work.

Robot Identity

During setup, the agent generates an Ed25519 keypair on the robot. The private half never leaves that machine. It is written to /etc/ctrlr_agent/agent_key, readable only by the account the agent runs as, and only the public half is ever sent to us.

Ed25519 is the same signature scheme used to secure SSH and modern web infrastructure. Guessing a key is not a matter of having enough money or hardware: even a billion machines each making a trillion attempts every second would still need longer than the universe has existed.

From then on, that keypair is the robot's identity. Every single time the robot connects, our signaling server issues a fresh challenge and the robot must sign it with its private key to prove it is genuine. A stolen recording of an earlier connection is useless, because the challenge is new each time.

The token used during first-time enrollment is single use and expires. It is consumed the moment the robot registers its key, so an install command that leaks afterwards cannot be used to enroll an impostor.

Until a connection has passed that check, it is allowed to do almost nothing: it can attempt to register and answer keepalives, and that is all. Nothing can be controlled before identity is proven.

Encrypted Sessions

Video, audio and control commands travel over WebRTC, which is encrypted in transit by design. Signaling runs over an encrypted WebSocket connection. The session view displays the connection's security status while you operate.

Operators authenticate through a managed identity provider, and their credentials are verified on every connection rather than once at login.

Network Posture

• The robot makes outbound connections only. It dials out to us. You do not need to open inbound ports, expose the robot to the internet, or give it a public address.
• No port forwarding, no VPN required. A robot behind normal corporate networking works without special treatment.
• The robot's internal messaging stays internal. The link between our agent and your robot's software runs over the machine's own loopback address. It is not reachable from the network at all.

Access Control

Inside an organization, what someone can do is controlled in Command HQ.

• Roles and fine-grained permissions. Operating a robot is a separate permission from managing one, so you can let a contractor drive without letting them change configuration, and let an analyst read history without touching a machine.
• Per-person device access. Someone can be restricted to specific machines rather than the whole fleet.
• Sites. People and devices are scoped to a location, so a local team does not gain visibility of the rest of the organization.
• Deny list. Access can be blocked outright by user, device, IP address or region, permanently or with an expiry, with the reason recorded. This is how you suspend an operator during an investigation, or refuse connections from a region you are not licensed to operate in.
• One operator at a time. A robot already in a live session cannot be silently taken over. Fleet-wide monitoring views show who is driving instead of offering control.

Audit Trail

Every session is recorded with the device, the operator, when it started, how long it ran, and how it ended. Fleet events are logged separately with severities and timestamps, and both can be exported.

"Who moved that robot, and when" is always answerable, for incident review, for insurers, and for demonstrating control over physical equipment.

Your Responsibilities

The following sit on your side of the boundary.

• Do not expose your robot's messaging port to the network. The bridge our agent talks to is unauthenticated and unencrypted by design. It is safe only because it stays on the robot's own loopback address, unreachable from the network. Publish it more widely and anything that can reach it can drive the robot with no credentials at all.
• Anyone with a login on the robot can command it directly. That is true of any ROS machine, and it bypasses CTRL+R entirely, along with its permissions and its audit trail. Accounts on the robot itself are part of your security boundary, not ours.
• Physical access is full access. Someone who takes the robot, or pulls its compute board, has the key file and can impersonate that device. If a machine is stolen or decommissioned, remove it from your organization so its identity stops being accepted, and treat its key as compromised.
• Enrollment commands contain a live token. Do not paste them into shared chats or tickets. If one leaks, regenerate it from the Robot Setup page.
• Review access periodically. Remove members who have left and revoke device access that is no longer needed.
• Physical safety remains yours. CTRL+R controls robots; it does not replace emergency stops, guarding or safe operating procedures on site.