Audit redacted text flows, retention and re-identification risk

Last updated: 6 Oct 20265 min read

tutorial

Redaction is a pipeline property. Verify every output sink, retention window and access path instead of trusting one transformed string.

Trace the data path

A ticket may reach intake logs, a classifier, a search index, a summarizer, a debugging trace and a training export. Map each sink with its purpose, permitted fields, retention time and access role. Decide whether it receives original, tokenized or fully redacted text. Apply the policy before a network call or log write. A downstream service must not accidentally receive the original because it subscribed to an early event. Detection and redaction handles the string; this contract handles the system around it.

Retain only what can be justified

A restricted evidence store may need an original ticket for customer support, while aggregate metrics rarely do. Store the minimum copy count, encrypt where required by the existing platform, and attach deletion to a stable case identity. A pseudonym mapping is sensitive data and needs its own retention period. Deleting a visible ticket but leaving its embedding, cache key or training export can defeat the policy. Include derived data in the deletion manifest.

Test the failure path

Inject synthetic canary values into a controlled test ticket and follow them through logs, indexes and exports. Assert they appear only in sinks explicitly allowed to hold originals. Test detector timeout, malformed UTF-8, overlapping spans and an unknown label type. For a sensitive sink, a failed detector must stop or quarantine the request. A success-shaped redaction response on detector failure is unsafe. Review false positives too: hiding a product code can remove the information needed to route a case.

Watch re-identification by context

A message with names removed may still expose a person through a rare role, location and timestamp. Evaluate combinations of remaining attributes, not just obvious identifiers. Report policy version, redaction detector version, sink inventory version and sampled leak findings. If a new sink is added, run the tests before enabling it. The ticket pipeline project combines these checks with NLP serving.

Implementation

def allow_sink_payload(payload, sink_policy):
    unknown_fields = set(payload) - set(sink_policy["allowed_fields"])
    if unknown_fields:
        raise ValueError(f"fields not allowed at sink: {sorted(unknown_fields)}")
    if sink_policy["requires_redaction"] and payload.get("representation") != "redacted":
        raise ValueError("sink requires redacted representation")
    return dict(payload)

analytics_policy = {"allowed_fields": {"case_id", "representation", "queue"},
                    "requires_redaction": True}
assert allow_sink_payload({"case_id": "case-47", "representation": "redacted",
                           "queue": "returns"}, analytics_policy)["queue"] == "returns"

Performance and operating cost

Policy validation is O(f) time and O(f) copied space for f payload fields. System cost comes from duplicate storage, deletion propagation and canary scans. Track the number of copies per case and the age of the oldest undeleted derivative. An allowlist is intentionally strict: a new field causes a visible failure until a reviewer updates the sink contract.

Common Mistakes

Checking only the user-facing page while raw text remains in logs.
Deleting source tickets but retaining derived embeddings indefinitely.
Treating a stable pseudonym as anonymous data.
Adding a sink without an allowlist and canary test.