Legal
Security
How the Service is built and operated, and how to report a vulnerability.
Last updated
Reporting a vulnerability
Report suspected vulnerabilities to our security contact before disclosing publicly. We acknowledge reports promptly, keep you updated while we investigate, and will credit you if you would like. Please do not run destructive tests, access other customers' data, or degrade the Service while testing.
Authentication
- Passwords are hashed with a memory-hard algorithm; minimum length is enforced at 12 characters.
- TOTP two-factor authentication is available, with single-use recovery codes.
- TOTP secrets are encrypted at rest with a deployment key; codes cannot be replayed within their window.
- Sessions are HTTP-only, Secure, SameSite cookies. API keys are hashed — the plaintext is shown once.
Tenancy
Every customer-facing query is scoped to the requesting organization at the data-access layer, not by filtering in the UI. Platform-admin routes are separately gated and audit-logged.
Data protection
- TLS in transit throughout, including between probes and the control plane.
- Probe uploads are Ed25519-signed and verified before ingestion; a batch failing verification is rejected outright.
- Observation history is append-only. Evidence checkpoints make silent revision detectable.
- Secrets are supplied by environment and never committed to source control.
Operational practice
- Infrastructure ports are not publicly exposed; administrative interfaces sit behind an authenticating proxy.
- Staging is fully isolated from production — separate datastores, credentials and probe identities.
- Backup and restore, failure injection and multi-node behaviour are exercised as part of release testing.
Measurement conduct
Our probes only make queries an ordinary resolver or browser would make, at a documented cadence, and identify themselves consistently. See the Acceptable use policy for what we will not do.