Principles

The RC Node creates an outbound authenticated WebSocket connection to RC. A controlled machine does not need a public SSH port, port-forward, or inbound RC listener.

Browser, CLI, API, MCP, and SSH-gateway requests are routed through the hosted service to the already-connected Node.

Workspace membership in the hosted database is not sufficient to execute on a locked Node. Each Node keeps an RC Lock authority snapshot locally.

After the initial lock bootstrap, authority changes require a valid Owner-authorized transition from the Node's current lock generation and hash.

Account creation, browser login, sensitive step-up operations, CLI authorization, and execution-capable MCP approval use WebAuthn passkeys. RC does not store account passwords.

API keys are Ed25519 proof-of-possession credentials. RC stores the public key; every request signs its method, path/query, timestamp, nonce, and body hash.

MCP grants select specific machines and scopes. Execution-capable grants are signed by a passkey-backed control identity and included in RC Lock.

Terminal commands, input, output, signals, and lifecycle messages use a client-to-Node AES-256-GCM session key derived from fresh and pinned X25519 material.

After authorization, browser and CLI clients use a WebRTC DataChannel to the Node. The hosted service performs non-trickle signaling over authenticated HTTP and provides short-lived TURN credentials when configured; browser live metadata uses SSE. ICE may choose a direct or TURN-relayed route, but browser/CLI control ciphertext does not traverse hosted HTTP/SSE.

Standard remote MCP and gateway-terminated SSH do not use this custom end-to-end transport; their trust models are documented separately in the security model.

GitHub Actions publishes native RC and kernel artifacts independently from portable WebAssembly components.

rc update changes managed components. rc upgrade verifies GitHub release digests, refreshes the native platform and core component bundle, and refuses native downgrades.