Redacting sensitive data#

BitExact proves a redaction happened. What to redact in a recorded run is found two ways: the capture policy's detectors (card numbers, IBANs, credentials, SSNs in context, email addresses and your own patterns - Capture controls) file it for you with bitexact capture backfill, as one two-person redaction request; anything those detectors do not cover is decided by tooling you already use - a PII-detection library, a DLP system, or your own classifiers - running inside your environment. This document describes how that output drives the redaction: one that removes the value where it lives, leaves a signed audit trail, and still verifies.

The division of labor#

• The capture policy, or your detector, decides what is sensitive. bitexact capture backfill --run RUN --by NAME files what the policy in force would not have kept. For anything else, your detector scans a run's recorded payloads and identifies the fields (and spans) to remove. It is the only component that needs to see the plaintext, and it runs inside your environment like everything else.
• BitExact removes it and proves the removal. bitexact redact rewrites the stored manifest write-ahead: a chained redaction audit entry naming the fields and the operator lands on the chain before any value is destroyed, the value and its salt are removed, and the standing field commitment continues to attest that the value existed. The chain still verifies; the plaintext is gone.

Procedure#

1. List the committed field paths of a run. Export it and read each entry's commitments keys (bitexact export <run> -o run.json), or open the step's Integrity tab in the inspector; a selection is step:path (e.g. 3:request.text, 3:response.text). bitexact show <run> prints one line per step and marks redacted paths once a redaction has happened.

2. Detect. Run your detector over the payload at each path and collect the step:path selections it flags.

3. Redact the store, write-ahead.

   bitexact redact <run> --fields 3:request.text,3:response.text

   This is the single-operator path. Where BITEXACT_REQUIRE_DUAL_CONTROL is set — and a deployment handling erasure requests usually should set it — redact refuses by name and the governed two-person flow is the only way through: one principal requests the redaction in the viewer's Redact drawer and a different one approves it there. Both decisions are taken in the viewer because that is where each principal is authenticated; on the command line --by is typed, so under dual control bitexact redaction request and approve refuse too, and only status and reject remain there.

   See Retention and legal hold for the full lifecycle. Either way the act lands as a chained claim on the run.

   Use --steps <n,...> to redact every committed field of a step. The rewrite is atomic and verified after write; a crash mid-redaction leaves the recorded intent, which verification flags until the redaction is re-run to completion. Audit entries themselves can never be redacted.

4. Prove it. bitexact verify <run> still passes; bitexact show reports the number of steps carrying redacted fields, and marks each hidden path [redacted: ...] in place. The open-source verifier independently enforces redaction integrity: a bundle that claims to have redacted a field but still carries its value fails. A recipient learns that redaction occurred and was honest — without ever seeing the removed data.

What to hand an auditor#

An exported, signed bundle of the redacted run. It proves the trajectory is intact and that the redactions it claims were actually applied, while the sensitive data is gone from the evidence. Detection quality is the responsibility of your detection tooling; BitExact's part is the verifiable proof that the redaction was applied and the rest of the record is untouched.