Security Overview

The platform is multi-tenant, and isolation is enforced at four independent points so that no single mistake exposes another tenant's data:

1. 1.The session's tenant claim. Every authenticated session carries the tenant identity inside a signed token.
2. 2.Query scoping. Every search is forcibly scoped to the caller's tenant: the tenant filter is added server-side from the session, and the browser never queries the log store directly.
3. 3.Ingest stamping. On write, the ingest service resolves the bearer token to a tenant and a device or source, and stamps those identifiers onto every event, overriding anything the client sent.
4. 4.Tenant filtering in the database. Every query in the data layer filters by tenant.

• In transit: traffic is protected with TLS. The agent requires HTTPS and connects outbound only.
• At rest: data sits on managed providers — the Postgres database and the object storage — that encrypt at rest.

The endpoint agent is the only component that runs with administrative rights on a customer machine, so it is held to a stricter standard.

• Signed releases. Every binary, the release manifest, the index of versions and the per-version checksum list are signed with an Ed25519 release key. The signed manifest names the version, so an old build cannot be passed off as a new one. Installers and auto-update fail closed: a missing or invalid signature or hash aborts the install or the update. The key fingerprint is published for out-of-band comparison, and an agent can trust more than one key so the key can be rotated without breaking the fleet.
• Reproducible builds. Anyone with the source can rebuild a release from its tag and get byte-identical binaries.
• Bill of materials and a vulnerability gate. Each release ships a CycloneDX SBOM, and a release is blocked when a known vulnerability is reachable from the agent's own code.
• One-time enrollment, protected credential. An install command carries a short-lived, limited-use enrollment code — stored hashed and revocable — not a long-lived credential. The agent exchanges it once for its device credential and keeps that in a file only administrators can read, never on a command line and never in the service definition. Revoking a device invalidates its credential.
• No remote shell. The agent performs only actions from a closed list — network blocking, host isolation, and Microsoft Defender scans and signature updates — each mapped to a fixed executable with fixed arguments. The list is enforced in the database too. The agent cannot be told to run a script or an arbitrary command.
• Least privilege on Linux. The service runs sandboxed by the operating system, with the minimum privileges it needs.
• Secret redaction on the host. The agent strips passwords, tokens and keys out of log data before it leaves the machine. On by default.
• Collection is the Customer's choice. Windows command capture is on by default because investigation depends on it, and can be switched off. Browser-visited URLs, device geolocation, Sysmon and AI coding-assistant activity are off by default and only the Customer turns them on.

• Roles. A user holds one of three roles per tenant — admin, editor, viewer — and authorization is checked server-side on every route.
• Two-step verification (TOTP). Any standards-based authenticator app works. The shared secret is stored sealed, a code is accepted once, attempts are rate-limited, and the challenge issued between the password and the second factor is a separate short-lived token that is rejected if presented as a session. Ten single-use recovery codes are issued at enrolment and kept only as hashes. The check fails closed.
• Passwords. Stored as bcrypt hashes; we never store a plaintext password. A password reset is a single-use link, valid for one hour, of which only a hash is stored; using it signs out every open session of that account and does not bypass two-step verification.

• The Service runs on managed providers: hosting and the Postgres database on Railway, log storage on Cloudflare R2. See Sub-processors.
• Secrets and credentials live in environment configuration and are never committed to source control.

Security logs are kept for the window the tenant configures — 30 days by default, up to the contract's ceiling and never past the platform cap of 180 days — and then deleted, or archived first if the tenant turned cold storage on. The detail is in Data Retention.

Email **support@distriib.com** with `SECURITY` in the subject line. What to include, our response targets, safe-harbour terms and the supported versions are in our disclosure policy, and a machine-readable contact (RFC 9116) is served at `/.well-known/security.txt` on the API host.