Threat model and deployment guidance for reachy-mini-driver. This document covers this package and how it sits in the Device Connect stack; broker ACLs, portal issuance, and MCP client supervision live in upstream components unless noted.

The driver is not a safety-certified robot controller. It forwards bounded motion and media commands to the Reachy daemon and mirrors state for agents.

  [Human supervisor]     [LLM agent host]
         |                        |
         | supervises             | MCP stdio / IDE
         v                        v
              device-connect-agent-tools (invoke_device)
                        |
                        | NATS (portal or local broker)
                        v
              reachy_mini_driver (this package)
                        |
          +-------------+-------------+
          |                           |
   HTTP/WS :8000 (daemon)      ws://:8443 WebRTC (media)
          |                           |
          v                           v
     Reachy Mini hardware      camera / mic / speaker

Settings UI (on-robot app only): http://0.0.0.0:8842 — separate from Device Connect; any host that can reach the robot LAN may read or change app JSON and upload portal credential files.

1. Compromised or mis-prompted agent — calls MCP tools repeatedly (motion spam, audio playback, panorama scans).
2. Mesh participant with valid NATS credentials — same RPC surface as the MCP bridge without going through your IDE.
3. LAN client — reaches daemon :8000, WebRTC :8443, or settings :8842 without portal access.
4. Settings UI attacker — uploads credentials, enables portal, toggles allow_insecure if the port is reachable.
5. Credential thief — reads credential files from disk or backups.

Rely on these outside this repository:

• Device Connect portal — credential issuance, tenant/device binding, broker TLS (when not using allow_insecure).
• NATS account permissions — which subjects a principal may publish/subscribe.
• MCP host policy — which tools the agent may call, rate limits, human approval.
• Network segmentation — firewall robot ports (8000, 8443, 8842) from untrusted Wi‑Fi.
• Reachy daemon — authoritative motion stack and hardware interlocks (if enabled in firmware/daemon).

1. Agent-first control plane — Device Connect exposes many RPCs so supervised agents can operate the robot. Convenience trades off least privilege; narrow MCP allowlists and broker ACLs in production.
2. Advisory leases — command_owner / lease_expires_at support observability and future coordination but do not arbitrate concurrent mesh callers. Multi-agent fleets need an external orchestrator or upstream Device Connect policy.
3. Unauthenticated settings UI — Simplifies robot bring-up (upload .creds, set 127.0.0.1:8000). Acceptable only on a trusted LAN; do not expose 8842 to the internet or guest Wi‑Fi.
4. Plain HTTP / WS to daemon — Matches Reachy’s default local API. On-robot 127.0.0.1:8000 limits remote tampering; remote REACHY_TARGET over LAN is trust-on-LAN.
5. WebRTC and GStreamer side channels — get_media_stream_access intentionally moves bulk video off NATS. Firewall and VPN policy must cover :8443 (and local IPC paths on-robot).
6. **DEVICE_CONNECT_ALLOW_INSECURE** — Documented for local smoke tests and examples/claude_desktop_config.json. Disable for portal or any shared broker.
7. Simulation target — --sim does not touch hardware but still registers a device on the mesh if connected; use distinct device_id values to avoid operator confusion.

• TLS termination for daemon or settings UI inside this package
• Enforcing motion leases or programmatic interlock trips
• TURN/STUN hardening for WebRTC through restrictive NATs
• Content moderation for play_audio_file paths
• Automated credential rotation or HSM storage

For upstream mesh security, see Device Connect and device-connect-agent-tools documentation. For robot-side safety, follow Pollen Robotics operational guidance for Reachy Mini.