ArticlesDeterministic Is Where Detection Starts. Opaque Is Where It Earns Its Keep.

A tax ID is easy to catch. It has a shape, and a rule can match the shape. Next year’s strategy, sitting in a document somewhere, has no shape at all. That is the whole problem in one line: the content most worth protecting is usually the content hardest to detect.

Content detection runs on a spectrum, and one end is far easier to cover than the other. It is not the end where the potentially catastrophic consequences live.

At one end is deterministic content: a pattern a SIT can recognize with rules, regular expressions, or a checksum. A social security number, a physical address, a known document fingerprint. The match is close to binary. The structure is either there or it is not, confidence is high, noise is low. This is the content detection most programs are good at, because it is the content detection that is easy to build and easy to prove.

At the other end is opaque content: a strategy document, source code, a pre-release design, an internal memo that would matter if it left. Sensitive not because of its structure but because of its meaning and its context. There is no regular expression for “acquisition plan.” There is no checksum for the deck that sets next year’s roadmap. The content carries no signature a deterministic matcher can catch.

Between the two ends sits a wide grey zone: semi-structured content, files that sometimes carry markers and sometimes do not. Most real content lives in that middle, and most of the interesting design decisions live there too. It is tempting to treat detection as binary, matched or unmatched, when the real work is the gradient.

The part that should bother you#

The difficulty of matching content and the cost of losing it tend to move together.

Low-value content is often structured, and structure is matchable: personal data, account numbers, formatted records. High-value content is often unstructured, and unstructured content is opaque: strategy, intellectual property, source code, design. What gives an organization its edge is usually the thing that is unique, contextual, and irreducible to a pattern, which is exactly what makes it hard to fingerprint.

The same logic runs along the org chart, not just across content types. The further up you go, the less structured trace the work leaves behind, because the work itself changes shape. There is a meme that captures it better than any diagram: the junior analyst runs three monitors, and the person at the top can barely be bothered with a phone. It reads as a joke about seniority, but it is really a description of the job. Operational work is instrumented by nature, every step a logged action. Decisional work is not. A choice that reroutes a strategy does not pass through a SIT, and the more senior the role, the more its output is judgment rather than artifact. The most consequential work in the building tends to leave the least to match against.

This is a tendency, not a law. Structured data can be extremely valuable, and plenty of opaque content is worth nothing. But the tendency holds often enough to matter, and its direction is the problem. The more costly a piece of content is to lose, the less likely it is to carry a deterministic signature. Detection difficulty tends to rise with content value, not against it.

Why investment flows to the easy end#

Programs gravitate toward the deterministic end, and the reasons are rational, which is what makes them hard to correct.

Deterministic detection produces clean metrics. The SIT catches a passport number, the count is defensible, the audit is satisfied. It generates alerts you can stand behind, because the match is unambiguous. Opaque detection produces the opposite: messy precision, false positives, and the unwelcome truth that you cannot easily measure what you are not catching. Faced with a choice between a number that looks good and a problem that resists measurement, organizations drift toward the number.

So coverage accumulates where it is comfortable to demonstrate, not where the loss would hurt most. A program can report excellent content detection and still be blind to the exfiltration that would actually damage it, because the damaging content was never the matchable kind.

I have watched this happen. A program presenting strong content-detection numbers, every one of them real, while the thing that would have actually mattered moved in a form no rule was ever going to catch. Not negligence. Just attention pointed at the half of the problem that answers back.

Three honest directions#

There is no clean fix, but there are three directions worth thinking through, and each is a trade-off rather than a solution.

The first is to move detection from content to context. If you cannot match what the file is, read where it came from, who normally touches it, and where it is going. Provenance and movement become a proxy for sensitivity when the content itself is silent. The trade-off is precision. Context tells you a file is probably sensitive, not that it certainly is, and it asks the program to reason about behavior rather than strings.

The second is to move the problem upstream, to classification at the source. Labeling at the moment of creation gives opaque content a deterministic handle it would not otherwise have, because the file carries its own label from then on. The trade-off is dependence. You have shifted the cost onto process and user discipline, and the detection downstream is only as good as the classification upstream. Where labeling is skipped or wrong, you are blind again, and you may not know it.

The third is to accept the residual. Some content is irreducibly semantic and will not be matched by any rule, and for that fraction the answer is not a better expression. It is behavioral analysis and human judgment. Or at least until the models get good enough to read meaning the way a person does and scan anything you hand them, which would be a genuinely exciting day and would retire this problem for good. Until then, the residual is human. This does not scale the way a rule does, and it is the part of the program that resists automation, but it is the only thing that covers content whose sensitivity lives entirely in meaning. Better to design for that residual on purpose than to assume a strong enough ruleset will eventually absorb it.

If I had to weight them, I lean on the first. Classification at the source is the most elegant and the most fragile, because it rests on discipline you do not control. The residual is real and worth designing for, but it is the last line, not the first. Context is the one you can build now, on signals you already hold, and it fails gracefully when it is wrong. It is the least satisfying of the three, and usually the right place to start.

The question worth asking#

None of this argues against deterministic detection. The SIT that catches structured sensitive data is necessary and worth having. The argument is about where a program points its attention when it decides it is doing well.

The useful question is not how much sensitive content you can match. It is how much of your real risk lives in the content you cannot match, and what you are doing about that part specifically. A program that measures only its coverage of the matchable is measuring the easy half of the problem. The harder half is where the content worth stealing tends to live.