Trust center

Security architecture

Identity, tenant isolation, roles, audit, encryption and signing — with the known gaps and how to report a vulnerability.

[01]Principles

Hard limits, enforced in the build

Two products, one hard line

Desktop consumer protection uses local warnings, quarantine and restore. An enrolled Android phone also supports explicit anti-theft commands such as lock, alarm, locate and wipe, subject to its permissions. Server administration uses separate authority.
ServerGuard administers servers and may take privileged actions, only at an administrator's instruction and through an audited command lifecycle.
The line is enforced at build time: the consumer service may not import code that can mutate the host.

The interface is untrusted

The desktop app's interface runs sandboxed with context isolation and no Node, filesystem or network access. It can call 11 typed, validated handlers and nothing else.
No API value reaches a process as command text. Server security fixes are structured actions, re-validated at fix time and run without a shell.

Tenant isolation

Every read of organisation data carries a tenant predicate; a lint step fails the build on an unscoped read.
PostgreSQL row-level security is enforced in production (switched on 2 October 2026; about 300 policies at the 13 October deploy). The application role cannot bypass the policies or own tables.

Signed updates

Agent updates are signed; the agent verifies signature, expiry, anti-rollback, hash, size and platform before install.
Releases roll out in 5 / 25 / 50 / 100 % bands with a reasoned rollback.
Known deviation, owner-approved: the root key signs manifests directly and is held on the hub rather than offline. Legacy MD5-verified updates are accepted until 15 October 2026 on the internal channel.

Data minimisation

Unclassified data is treated as restricted by default.
Redaction happens on the device before anything is queued, not as a filter on the server.
Consent is checked on the device and again on the server.

[02]Identity

How a device proves who it is

Consumer devices — implementedAvailable

01
An administrator creates a one-time code.
Codes carry a label and an expiry. A reused code is refused, an expired one is refused.
02
The device redeems it once and receives a token.
The server keeps only a SHA-256 hash of the secret and compares in constant time.
03
The token travels in a header, never in a request body.
So it never reaches request logs. It authorises reporting only — never an administrative action.
04
The server stamps identity onto every event.
A device cannot write events as another device. A retired device is refused before anything else is checked.

Gap: consumer tokens do not rotate yet.

Enterprise devices — designed, not builtComing

Credential: X.509 certificate, bound to organisation and device
Transport: Mutual TLS on every connection
Rotation: Automatic, before expiry, with overlap
Revocation: CRL and OCSP; revocation outranks everything
Trust root: Offline

The two systems are kept separate by design: a consumer token is never upgraded into a certificate, and a certificate never enrols a consumer device.

[03]Tenancy

Keeping organisations apart

One database serves every organisation, so isolation is a property of every query. It has three layers; two are live.

Repository layerAvailable

Every read goes through a repository that requires a tenant. A build-time lint fails on an unscoped read. The tenant comes from the authenticated server or device, never from the request body.

Database row securityAvailable

PostgreSQL row-level security, enforced in production since 2 October 2026 (about 300 policies at the 13 October deploy); the application role cannot bypass them or own tables. Verified with a negative control.

Cross-tenant testsAvailable

Read and write isolation tests for servers, devices, Android fleets, incidents and private stores run in CI as a release gate.

Removing someone from one organisation does not affect their others; permission is re-derived from membership on every call. An owner cannot remove the last owner.

[04]Access control

Six roles, named permissions

Permissions are action strings such as servers:act or audit:read, bundled into fixed roles. Who holds what is decided from stored records — the account and its membership — never from anything in the request.

Organisation roles
Role	Who it is for	Can	Cannot
owner	Runs the organisation	Everything in the organisation, including billing and membership	Operate the platform or other organisations
admin	Administers it day to day	Servers, devices, alerts, rules, policies, members, audit	Buy or change the plan
analyst	Security analyst	Read everything; acknowledge alerts; triage incidents; tune detection rules	Send device or server commands; change policy, members or billing
operator	Technician	Read everything; device and server commands; acknowledge alerts	Touch the hub host, policies, rules, members or billing
viewer	Auditor	Every read, including the audit trail	Change anything
member	Personal account	Its own devices, servers, policies and plan	See other people's devices or the audit trail

Two-person rule for destructive commandsoptional · off by default

An organisation can require a second person to approve reboot, shutdown and firewall-disable commands. With it on:

The command is held, not run, and the requester is told it is waiting
A different person with permission to run server commands must approve it
Approval is bound to the organisation and expires after one hour
Every step — request, approval, rejection, withdrawal — is written to the audit trail

Server commands

35 typed actions with their own validation; no free-form shell from the console
Reboot, shutdown and firewall disable need an explicit confirmation and show a preview first
A command reports its real outcome; a failure is shown as a failure, never as queued or done
Each command and its result is stored with who asked for it

[05]Audit

What is written down

Recorded categories

admin: Organisation, membership and audit changes
policy: Device policies and detection rules
enrolment: Device enrolment and retirement
response: Server commands, joined to their real outcome
account: Profile, password, sessions, export and deletion requests

Who can read it

Owner, admin, analyst, operator and viewer roles; personal accounts do not hold the permission
An organisation sees its own rows only. A row whose organisation is unknown is never guessed into one
Incident history is append-only
In the desktop app, consent changes are recorded on the device as privacy events
Automatic pruning of the trail is off, so nothing is deleted yet

[06]Cryptography

Encryption and signing

Encryption and signing in use
What	How	State
Browser and agents to the hub	TLS. Agents verify the hub certificate by default; turning that off is a lab-only switch that warns on every start	Available
Hub to server agent (port 9876)	Plain HTTP with an API key; restrict the port to the hub	Limited
Alert-channel and database-monitor secrets	AES-256-GCM, a separate key per purpose derived with HKDF-SHA256, each value bound to its record	Available
Password vault	Encrypted in your browser (PBKDF2-SHA256, at least 310,000 iterations); the server stores ciphertext only	Available
Breach check for a password	k-anonymity: only 5 characters of its SHA-1 hash leave your browser	Available
Device secrets	Stored as SHA-256 hashes, compared in constant time	Available
Agent updates	Ed25519 signed manifests (Linux, macOS and Windows agents)	Limited
Android app	4.1 was signed with a development key; 4.2 and later with a private release key	Available
Desktop quarantine	Encrypted, versioned container with journalled restore	Not released
Other database contents	Not encrypted by the application itself	Coming

Update verification order, key fingerprints and the signing deviations are on the download page.

[07]Gaps

What is not finished

Known gaps, stated08 open

The Windows agent has been verified on one Windows Server only; Linux is the best-tested build.
A legacy plaintext push path from the hub to agents exists behind a switch that is off; it is scheduled for removal on 31 October 2026.
The update root key is held on the hub, not offline, and signs manifests directly (owner-approved deviation).
Legacy MD5-checked agent updates are accepted on the internal channel until 15 October 2026.
Consumer device tokens do not rotate yet.
Hub security events are not yet automatically pruned.
Off-site backup and restore checks must continue; a saved dump alone does not prove recovery.
Desktop downloads are unsigned pre-releases; signed production installers and wider platform checks remain pending.

[08]Disclosure

Report a vulnerability

How to report

01
Email [email protected] with the subject "Security".
Or use the "Security report" topic on the contact page, which pre-fills it.
02
Describe what you found and how to reproduce it.
The affected URL, app or agent version, the steps, and what an attacker could gain.
03
Give us reasonable time to fix it before disclosing it.
We will tell you when it is fixed.

Report an issue

Please do not

Access, change or keep data that is not yours; test against other people's organisations; run denial-of-service or social-engineering tests; or include exploit details for systems that are not ours.

Not yet published

A formal disclosure policy with response-time commitments and a safe-harbour statement. Until it exists we make no promises we have not written down.