Two detectives. Same case. Same victim, same crime scene, same set of leads.
The first detective looks around for a minute, lights a cigarette, and tells you he knows who did it. He sketches a likely motive. He gives you a plausible modus operandi. He even tells you, with a confident smile, that he is right 99.9% of the time.
The second detective takes a month. She collects every fingerprint, every camera angle, every receipt, every phone record. She labels each item, logs the chain of custody, and assembles the timeline minute by minute. At the end of the month she names the murderer, walks you through the evidence in the order it was gathered, and hands you a case file a prosecutor can take to court.
Who do you want on the case?
(I know which one I want. I also know which one a judge wants. The two answers are the same.)
The Honest Difference Between the Two
The first detective is a probabilistic processor. He pattern-matches. His brain (or his model) compresses thousands of priors into a fast, confident guess. When he is right, he is impressive. When he is wrong, the cost of that one bad call lands on someone who had nothing to do with the crime.
The second detective is a deterministic processor. Every claim she makes is anchored to a specific piece of evidence. She can show her work. The work survives review. If she is wrong, you can find out exactly where she was wrong, because the wrong inference is sitting on the table with a label on it.
Here's the thing: 99.9% sounds great until you say it out loud, and it falls apart on the witness stand.
In a SOC handling 100,000 events a day, 99.9% accurate means 100 wrong calls a day. Some of those wrong calls are missed intrusions. Some are innocent users locked out of systems. Some are public statements about an incident
that turns out not to be one. None of them are recoverable just because the model was usually right.
Four Professions That Can't Settle for the Guess
There are four professions where probabilistic analysis is useful for hypothesis but reckless for delivery. They share something in common.
Law enforcement arrests people and takes away their freedom. The arrest has to be defensible to a judge.
Audit certifies financial statements that markets price assets against. The opinion has to survive a regulator.
Accounting produces the numbers a court can use to settle a dispute. The ledger has to tie.
Cybersecurity, in the modern enterprise, sits in exactly this same category. We make claims about what happened, who did it, what was taken, when, and through which path. Insurers, regulators, boards, and (increasingly) prosecutors read those claims.
The deliverable in these professions is not the right answer most of the time.
The deliverable is a finding that can be inspected, replayed, and defended. A probabilistic guess (no matter how often it is correct) cannot do this. Not because the guess is dumb. Because the guess can't show its work.
The pitch I keep hearing from AI-native security vendors is some version of our model is 99.something percent accurate on benchmark X.
That is a useful claim during product evaluation. It is the wrong claim to put under an incident report. Two different jobs. One is hypothesis. The other is deliverable.
Probabilistic Where It Helps, Deterministic Where It Counts
I want to be careful here. I am not anti-AI. (Anyone who has read this blog for the last year knows I am building a cybersecurity platform with AI.) Probabilistic models are extraordinary in their right place.
Their right place is hypothesis generation. Here are five places to look first.
Here are three actors whose TTPs resemble what we are seeing.
Here is a candidate theory of the incident, ranked against MITRE ATT&CK.
That is real value, and it speeds investigations up by an order of magnitude.
Their wrong place is the deliverable. This user is the attacker.
This finding warrants a SAR filing.
This incident triggered the 72-hour notification clock.
The way out is not to pick a side. The way out is to know which step you are on.
How Empathetic Processing Gets You There
At WitFoo we built a methodology called empathetic processing. The whole point of it is the bridge between the two detectives. It does the slow detective's work in the data pipeline, so the fast detective can do something useful at the end without breaking anything.
Three disciplines do the work.
Empathetic listening. The system reads vendor logs (Cisco, Okta, CrowdStrike, the rest) the way an experienced analyst reads them. It knows what kind of event each one is. It pulls out the fields that matter. No hand-written parsers, no regex archaeology. The data arrives in a common shape, every time.
Dissonance resolution. The same incident often shows up six to 10 times in your data lake (the firewall logged it, the proxy logged it, the EDR logged it, the cloud audit log captured it, the identity provider noted the authentication, and so on). The system collapses those into one enriched artifact while keeping every contributing source attached underneath. You lose nothing. You stop drowning.
Empathetic speaking. The output is shaped for who is going to read it. An analyst sees a triage view. An AI agent receives a structured object it can reason over without inventing entities. A prosecutor (if it ever comes to that) receives an evidence package with chain of custody intact.
The result is a stream of clean, deduplicated, normalised, attributed artifacts that an AI can think about without first having to do the discovery work that gets it into trouble. Discovery has already happened, deterministically, before the AI sees anything. The AI's job is evaluation, not detection of basic facts. (This is the same point I made in Three Prompts That Turn Your Data Lake Into an Empathetic Processor and, in more theoretical form, in Empathetic Processing and Temporal Link Analysis.)
When you ask the model which theory best fits this graph?
it can answer with citations. When you ask it describe the incident for the SOC report,
it can write the report and tell you exactly which evidence supports each sentence. This is what I have been calling, in conference talks since 2024, perjury-free AI. The AI can take the stand because the evidence underneath it is real, structured, and traceable.
The Trap We Keep Falling Into
The trap is to think you can buy your way out of evidence discipline with a better model. You can't. A faster guesser is still a guesser. (See also: Supersonic Broken Processes. Automating a broken process with AI just makes the breakage arrive faster.)
The detective with the cigarette gets faster when you give him better priors. He does not become defensible. The detective with the case file gets faster when you give her better tools (forensic kits, lab automation, structured chain-of-custody software). She becomes more defensible at the same time.
In cybersecurity, choose the second detective. Build the pipeline around her. Use the first detective for hypothesis at the start of the investigation, then hand the case to her once the leads are warm.
Last Words
Cybersecurity is not actually a technology problem. It is an evidence problem. Every regulatory frame we are stepping into (NIS2 in Europe, the SEC disclosure rules in the US, NZ's Cyber Security Bill, every breach-notification statute on the books) assumes the defender can produce evidence of what happened. The attacker is not the only adversary in the room. The other adversary is the case file you have to produce later.
If your security stack can't show its work, you do not have a security stack. You have a detective with a cigarette and a confident smile, and a one-in-a-thousand chance per call of ruining someone's life.
Pick the other detective.
