Documentation

How it is built

The design of this platform is written down, in the detail a security auditor would ask for, because one will. Each document below decides something specific and says why; the summaries tell you which one answers your question.

Threat model

Assets, adversaries, trust boundaries, and the accepted residual risk of a browser-based console.

docs/threat-model.md

Architecture overview

Components, data flow, and the scaling story for signaling and relay.

docs/architecture.md

Data model

The multi-tenant schema: MSP, customer, group, endpoint, session, audit, with optimistic concurrency.

docs/data-model.md

Agent ↔ server protocol

Enrolment, rendezvous, session setup, and key exchange, message by message.

docs/protocol.md

Windows Session 0 strategy

Service and session-helper split, Secure Desktop, lock and sign-out handling.

docs/windows-session0.md

macOS TCC strategy

PPPC profiles for managed Macs and the guided grant flow for unmanaged ones.

docs/macos-tcc.md

Key recovery and re-enrolment

Re-imaged machines, restored databases, and planned key rotation.

docs/key-recovery.md

Break-glass auth recovery

The deliberate recovery path for passkey-only technician accounts.

docs/break-glass-recovery.md

Browser support matrix

WebCodecs coverage and the decode fallback path for Safari and iPadOS.

docs/browser-support-matrix.md

Policy management

Named policies, and how one reaches an endpoint: organisation, customer, group, machine.

docs/policy-management.md

Runbook

Operating the self-hosted stack: deploy, rotate, back up, and recover.

docs/runbook.md

One system

Designed as a whole, not per part.

The agent, the signaling tier, the relay, the installers and the console are designed against one another rather than separately, which is why the consent rule, the audit contract and the key handling read the same way wherever you look them up.

Features Security posture Architecture