Trust at Preloop

How we build, ship and run Preloop, stated as facts you can check

This page lists what we do today and links to the source for each point. Where something is not in place yet, it says so.

Security practices

  • Release checksums. Releases publish a SHA256SUMS file next to the binaries, so you can check a download with sha256sum before you run it.
  • SBOM. Releases ship a CycloneDX SBOM per component (backend, CLI and frontend), built from the shipped artifacts. The SBOMs carry a Sigstore build-provenance attestation, so gh attestation verify <sbom> --repo preloop/preloop shows they came from our release workflow.
  • Windows Defender scan. Before a release is published, the Windows CLI binaries are scanned and run on a Windows runner with Microsoft Defender enabled, and the release stops if Defender flags them.
  • Code signing. Windows Authenticode signing is wired into the release workflow but not switched on yet, so the Windows binaries are currently unsigned. Use the published checksums to verify them.
  • Dependencies. Dependabot checks our Go, Python, npm and GitHub Actions dependencies weekly. Security updates are opened as soon as an advisory lands and are never grouped behind unrelated bumps. CodeQL, secret scanning, OpenSSF Scorecard and a workflow linter run in CI.
  • Disclosure. Report vulnerabilities privately to security@preloop.ai, not in a public issue. Our security policy states the support period (security updates until 31 December 2031) and which release lines get fixes.

Your data

On Preloop Cloud, we store your sessions to give you search, audit trails, cost reports and policy enforcement, and we use them for nothing else. We do not train models on them, and we do not sell or share them. You set retention, and legal holds keep records longer only when you place them. If you self-host, your data stays on your infrastructure; the only thing sent to us is an optional version check, which PRELOOP_DISABLE_TELEMETRY=true turns off. The details are in section 4 of our Privacy Policy and on the Security and Privacy docs page.

Audit and evidence

  • Hash chain. Audit rows are chained per account: each sealed row stores the hash of the row before it, so editing, deleting or reordering a sealed row breaks every hash after it.
  • Verify it yourself. preloop audit verify recomputes every hash on your machine, checks the signed checkpoints, and exits with status 1 on a break, so CI can gate on it. See evidence storage.
  • Retention. You set retention periods in the console under Settings > Records. Rows removed by the retention purge are reported as purged under a stated policy, not as tampering.
  • Legal holds. Artifacts of a session under legal hold are never evicted and never purged.

Availability

  • Status page: not yet.
  • Incident history: when a production incident has customer-visible impact lasting longer than 15 minutes, or exposes customer data whatever its duration, we publish a report on the blog within 72 hours of resolving it: what happened, the impact, a UTC timeline, the root cause, and what we changed.

Compliance

  • The Preloop core is open source under Apache-2.0, so you can read every line that touches your data.
  • Our CRA, EU AI Act, NIS2 and DORA pages are guidance on the evidence Preloop can produce for those programmes. They are not certifications, and Preloop holds no certification today.

Contact