The DLP control that removed its own evidence binding

The detector found something suspicious because the evidence looked like a secret

Data-loss prevention rules often look for high-entropy strings. That is a reasonable signal: many credentials, private keys, and tokens look random and have no natural-language context around them.

Cryptographic digests have the same property. They are deliberately high-entropy strings.

In one evidence workflow, a receipt carried a digest that bound a plan, a result, and the artifacts used to produce it. Removing the digest did not just redact an incidental detail. It removed the link that let a later reviewer tell whether the receipt belonged to the thing it claimed to describe.

The DLP rule had done its local job: it saw a secret-shaped value and removed it. The receipt then survived in a form that looked safe but could no longer be verified.

A redacted receipt can be a misleading receipt

There are two different kinds of redaction:

• removing information that a reviewer does not need; and
• removing information required to validate the evidence.

The first improves safety. The second can convert a truthful record into an uncheckable assertion.

Suppose a receipt says that a review passed, but the binding to the reviewed plan is gone. A future reader cannot determine whether the result came from this plan, an earlier draft, or an unrelated run. The record may still be accurate, but it no longer proves enough to support a consequential decision.

That is especially dangerous because the absence is quiet. A clean-looking redaction can be mistaken for a complete receipt unless the verifier knows which fields are mandatory.

Do not solve this by allowing all hashes

The tempting repair is a global exception: “ignore digest-shaped strings.” That would create a new blind spot for values that resemble digests, including real credentials in an inconvenient format.

The safer pattern is a typed, path-bound exception. It permits a digest only when all of the following are true:

1. the record matches one narrowly defined receipt schema;
2. the field name is an expected binding field, not an arbitrary text field;
3. the value has the expected algorithm and format;
4. the record appears only in an approved evidence location;
5. the surrounding receipt passes its own structural validation; and
6. similar values outside that structure are still detected and blocked.

The allow rule is therefore not “this string is harmless.” It is “this exact kind of evidence needs this exact field to remain verifiable.”

The tests have to attack the exception

An exception is complete only when its failure modes are tested. The useful negative cases are more important than the happy path:

This test set changes the discussion from “make the scan stop complaining” to “prove that the new rule preserves both confidentiality and evidence.”

Controls need a shared vocabulary for evidence

DLP, logging, audit receipts, backups, and build systems are often designed as separate layers. Their interactions are where subtle failures appear.

A practical fix is to give evidence artifacts a small, explicit vocabulary:

• what kind of record this is;
• which fields are identifiers, digests, timestamps, or human notes;
• which fields may be redacted;
• which fields are necessary to verify the record;
• and how a consumer should fail when a required field is absent.

That makes it possible for the DLP policy and the receipt verifier to agree on what must remain. It also keeps a later change from relaxing a detector merely because a different system did not label its evidence precisely enough.

The principle is simple: protect secrets aggressively, but do not confuse evidence binding with a secret. If a control removes the only way to verify a claim, the control needs a narrower design—not a broader bypass.