Can DLP work without reading employees’ messages?

The second is harder to build and easier to defend.

Surrounding words survive, so a reviewer can distinguish “here is a test fixture” from “here is a real customer, reformat it for me”, which is most of what triage needs, while the value itself is gone.

Note masked, not tokenised. Masking destroys the characters. Tokenisation replaces them with a reference something can reverse. A vendor offering “reversible for authorised investigators” is offering a content store with extra steps.

If your investigative process genuinely requires reading what people wrote, this architecture is the wrong fit, and you should be clear-eyed that the alternative means holding a searchable archive of your employees’ messages.

A vendor confident in the claim will help you run this. One that deflects has told you something.

The claim is easy to make and worth checking line by line, because the difference between a tool that preserves confidentiality and one that quietly does not is the field list.

What leaves the device in our case is a type, a count, a confidence score, a masked snippet, the destination, a risk score, a timestamp and a device identifier. A reviewer reading that knows a message contained three card numbers and went to an unsanctioned host at 14:06. They do not know what the message said, who it was about, or anything else that was in it.

The masked snippet is the field that decides whether the claim survives. It exists so an analyst can tell a real detection from a false one without opening anything, which means it has to show enough context to be useful and not enough to identify a person. Getting the span boundaries wrong by four characters is how part of a real value ends up in a record that was supposed to be safe to store, which is why span accuracy belongs in the test suite rather than in the marketing.

Most real leaks from security products are not exfiltration features. They are a debug line somebody added during an incident and forgot to remove.

A product can classify entirely on the device and still write the unredacted value to a local log, a crash report, a telemetry payload or a support bundle, any of which can be collected later by something that does leave the machine. The architecture diagram is correct and the property is gone. This is why redaction has to happen before the record is constructed rather than before it is transmitted, and why it belongs to a build gate rather than to a code review convention.

The limit worth stating is that this architecture protects the content and not the metadata. Somebody with access to the console can see that a named person sent regulated data to a named destination at a named time. That is a far smaller disclosure than the message itself, and it is not nothing. Where that matters, the answer is access control and retention on the console, not a claim that nothing was recorded.