Assurance
Security posture
This tool holds unattended admin access to healthcare and school networks, which makes it the highest-value target in the stack. Every layer is designed on that assumption, including the assumption that the supply chain is the target.
In transit
Transport and session crypto
Media and data channels are protected by WebRTC DTLS-SRTP. That is a property of WebRTC, not a bespoke achievement, and it means the TURN relay only ever forwards ciphertext.
Nothing inbound is opened on the customer firewall. The agent dials out on 443, ICE with STUN traverses most networks, and self-hosted coturn is the fallback. This is a hard requirement, proven under test.
Stated, not papered over
The residual risk we accept
Because the control plane serves the JavaScript that holds a technician's session keys, a compromised control-plane server can serve malicious JavaScript and defeat session confidentiality. This is inherent to browser-based consoles. We do not describe the system as end-to-alert encrypted against a compromised server.
Mitigations we carry against it:
Subresource Integrity on console assets.
A strict, nonce-based Content-Security-Policy that avoids inline script.
Signed releases of the console assets, with tamper-evident build provenance.
Who the agent is
Agent identity and key recovery
Each agent generates a unique keypair on enrolment. The private key never leaves the device and lives in the platform keystore (Keychain, DPAPI, or TPM).
Enrolment uses a short-lived, single-use token, rate-limited per tenant. The server pins the agent public key, and each technician-to-agent session is cryptographically authorised.
Re-imaged machines, a control-plane database restored from backup, and planned key rotation all have defined re-enrolment behaviour, so a restore does not silently trust stale keys.
Who the technician is
Technician auth and break-glass
Built-in accounts only, no external SSO dependency: passkeys (WebAuthn) are primary, TOTP is the fallback.
Passkey-only auth has a genuinely hard recovery story, so break-glass recovery is designed deliberately up front, not improvised at 2am. It uses pre-issued, sealed, single-use codes held by two named administrators, with every use loudly audited.
RBAC gates every action. Tenant isolation has explicit automated tests, because cross-tenant leakage is the classic multi-tenant bug in a product you sell.
What is recorded
Least privilege and audit
The agent runs with the minimum rights it needs. Elevation is explicit and logged.
The audit trail is append-only: who connected, to which endpoint, when, for how long, the session type, elevation events, file transfer filenames and sizes, terminal commands, and the fact that input occurred as event counts and timing.
Keystroke content is never logged. Capturing input content in a healthcare setting means capturing patient data and staff credentials into an audit store. This is a hard prohibition.
Audit events queue locally on the agent and survive a server outage. Unusual technician behaviour, connection bursts, out-of-hours access, first-time access to an endpoint, or a new location, is flagged as the insider-threat and compromised-account layer.
Where we sit
Tenant isolation, and what we can and cannot do
Your tenant is isolated in the software. Every read and every write is scoped to your organisation from the signed session, never from anything a browser sends, and a record in another tenant is indistinguishable from one that does not exist. There is no cross-tenant administrator role in the product - not a disabled one, not a dormant one.
Media never passes through us. The picture and the keyboard travel directly between the technician and the endpoint, encrypted end to end; the introduction service that puts the two in touch can read none of it.
We operate the platform, so our staff have database access to it. We will not dress that up: what we have today is that we cannot do anything invisibly. Every session is written to an append-only record you can read, the person at the machine sees a banner naming whoever is connected, and they can end the session themselves at any moment with a button no policy switch removes. That is an audited commitment, not a cryptographic bar, and we would rather say so than claim a guarantee we have not built.
The design that makes it cryptographic is published and costed: your organisation holds a signing key we never see, and an endpoint refuses any session whose authorisation is not signed with it. Then creating an account inside your tenant buys nobody anything, because no machine will act on it. Ask us where that sits if it decides your purchase.
What the end user sees
Consent and notification
A persistent, unmissable indicator is always shown while a technician is connected: a screen border plus a tray or menu-bar item naming the technician and the MSP. It ships with remote control, never after it, and it cannot be suppressed, even for unattended access.
An optional approval prompt can be required per customer or group, with a configurable timeout and auto-deny. The end user can terminate the session at any time from the indicator.
Session recording is optional and its state is shown to the end user distinctly from the connection indicator. Recordings are stored in Australia and deleted on a defined retention policy. They are not yet encrypted at rest, which we say here rather than let you assume otherwise: anyone who can reach the store, including us, can read them until that ships.
The build itself
Supply chain
No hardcoded secrets. Signed agent updates only, staged with rollback.
Reproducible builds where practical, an SBOM generated in CI, and a licence gate (cargo-deny plus an npm equivalent) that keeps the whole dependency graph permissively licensed.
The full threat model, written for a security auditor, sits with the rest of the documentation alongside the data model and protocol.
Documentation →