Cloud & AI for regulated, BaFin-supervised teams — from the team behind Redactor. · Consulting →
Security & transparency

Built to be checked, not trusted

Redactor's whole job is keeping secrets and personal data on your machine — so it's built to be verified, not taken on faith. Here's how it's made, what it does with your data, and how to check every release yourself. This is our own engineering report — not a third-party audit (an independent audit is on our roadmap, below).

What it guarantees

100% on-device

Detection and redaction run entirely on your Mac — no accounts, no telemetry, no upload of your content. The only socket is an optional loopback to a local Ollama model, which only ever sees text that's already been redacted.

No secrets at rest

Clipboard and redacted content are never written to disk, logs, or preferences. The round-trip restore map lives in memory only. The opt-in audit log records category counts + timestamps — never the values.

Deterministic & reversible

The same input always produces the same output, byte for byte. 265 checksum- and entropy-validated detectors. Every redaction is reversible through an in-memory map.

Not weaponizable by clipboard input

The one untrusted input is arbitrary copied text. No shell injection (subprocesses use argument arrays, never a shell), loopback-only network, and ReDoS-hardened rules.

How we build & ship it

Every release is independently verifiable — the exact commands are on the download page.

  • Developer-ID signed & notarized by Apple, hardened runtime, stapled ticket — Gatekeeper verifies it on first launch.
  • Signed auto-updates. Sparkle appcast enclosures are EdDSA-signed; the app checks each against a pinned public key before installing.
  • Published SHA-256 checksums for every release at /releases/SHA256SUMS.
  • Pinned dependencies. Sparkle is fetched by verified SHA-256; the detection rules are pinned to a specific gitleaks commit.
  • Hard-gate CI. Every detector must compile under ICU and pass positive/negative test vectors; a precision audit and a ReDoS harness guard against regressions on each change.

Your data

  • The round-trip map (token → original) is in memory only and never written to disk by the app. The CLI writes it only when you pass --map FILE — treat that file as sensitive and delete it after restore.
  • The audit log is opt-in and stores category counts + timestamp + surface only — never matched values or any text.
  • The optional local LLM receives only already-redacted text over loopback to 127.0.0.1:11434. It can only add tokens — it cannot reveal a redacted value.

Report a vulnerability

Found a security issue? We want to hear about it. Please report it privately and give us a reasonable window to fix it before public disclosure. Do not include real secrets in your report.

Shipped: provenance & SBOM. As of v1.1.0, every release publishes keyless build provenance (Sigstore, recorded in the public transparency log) and a per-release SBOM (SPDX) alongside the SHA-256 checksum — see Verify your download. On the roadmap. Everything above is our own engineering report. We're scoping a third-party security audit of the update path, the MCP server, and the detection engine; the full report will be published on this page when it's complete.