"User jsmith read 412 files from /research/strategies between 23:14 and 23:51." True. Logged. One of nine hundred such lines your tooling emitted today. It tells you almost nothing, because reading research files is jsmith's job and 412 is not obviously different from 380. So it sits in the queue with the other eight hundred and ninety-nine, and a human at 2am decides whether to chase it across a dozen consoles. That decision is where real exfiltration hides. The dangerous thing was never one event. It was a pattern across many, and a line in a queue cannot show you a pattern.
An alert reports that one thing fired. A case is the finished account of what is going on and why it matters. Most tools hand you the first and leave the second on your analyst's desk.
What jsmith's data actually did
Hold that alert next to what was really happening.
Over six days, jsmith pulled the full contents of three proprietary strategy directories in small off-hours batches, through an approved transfer job that normally moves a few megabytes a night, to a destination volume unlike anything in this identity's history. Here is the timeline. Here are the moves. Here is why each one read as normal and why together they do not.
The first version is an input. The second is an output, and a person can act on it in the next ten minutes. The distance between them is correlation: pulling related events from one tool, enriching them from another, reconstructing who did what to which data and whether it fits. That reconstruction is most of an analyst's day. It is where good analysts burn out and where slow ones miss things.
Alert fatigue is built in, not tuned in
The standard move against too many alerts is to tune them down. Raise thresholds, suppress noisy rules, add exceptions. It helps at the margins, then stops, because the volume is not a defaults problem. It is a property of how the tools work.
Most detection scores one event at a time. A rule asks whether a given action crosses a line and fires when it does. That is the right design for what it was built to catch: a known-bad file hash, a login from an impossible location, a blocked process. Those are real, and the per-event model catches them well.
The move that matters most crosses no line. Your most valuable data leaves on access you granted on purpose. The researcher copying strategy code is permitted to read it. The approved transfer job is approved. Each action passes on its own. The breach is the shape they make together. A tool that scores events one at a time cannot see a shape that exists only across events, so it picks one of two failures: stay quiet and miss it, or fire on every component action and bury the signal in the same flood as everything else. Tuning changes neither outcome. The unit of analysis is wrong.
The pattern is the breach
State the keystone plainly: individually normal moves can compose an exfiltration, and the composition is the only place the danger lives.
So the question is no longer "did this event break a rule?" It is "does this sequence of moves fit how this identity normally moves data?" That question has an answer only if you are watching the movement itself, resolving each move to who is behind it and the job that produced it, and weighing the sequence against a baseline of normal for that identity. A move that is unremarkable for one user, at one hour, through one job is a flag for another. Identity is what makes the pattern legible.
A case, then, is not a tidier alert. It answers a different question. It exists because the correlation a human would do by hand already happened: the related moves grouped, resolved to an identity and a purpose, weighed against history, and judged anomalous as a sequence even though no single move in it was.
How Hilt writes the case instead of filling the queue
Hilt is runtime Data Movement Governance. It watches data movement at the kernel, metadata only by default, off the path, single-tenant inside your own cloud. It does not read your data to do this, and it does not have to. Watching at the kernel means it sees the move whichever application, channel, or approved job carried it, which is the coverage a per-event rule bound to one channel never has.
Every move resolves to a probabilistic, source-dependent identity: which user or workload, which job behind the move, which destination, whether this fits what that identity normally does. That resolution is what lets the system reason about a sequence instead of a stack of disconnected lines.
When a dangerous pattern forms, Hilt does not emit one alert per component move. It assembles them. The unusual job, the bulk read of high-value paths in a short window, the destination volume that is wrong for this identity despite an approved channel: any one of those is noise, and Hilt treats it as noise. Together they are a case, and Hilt writes the case: the identity, the timeline, the moves, and the account of why each looked normal alone and why the sequence does not. When the pattern warrants it, Hilt responds with host-level network isolation from the control plane, quarantining the host at the network. It never sits inline, and it never blocks, drops, or alters traffic to do so.
What your analyst opens is the finished account, not the raw firing. The correlation that used to eat the shift already ran.
Pressure-test anyone who sells you a "case"
The word is everywhere now. Check what sits behind it.
Does it correlate movement, or just staple alerts together? Bundling several fired alerts under one ticket is not the same as judging a sequence of permitted moves anomalous. Ask whether the system scores the pattern across moves, or only collects the events that already fired on their own.
Is each move resolved to an identity and a job? A case that names "an endpoint" is weaker than one that names the user, the job behind the move, and the destination, and says why this sequence is unusual for that specific identity. Ask what the unit of resolution is.
Where does it watch? A tool bound to one application or channel builds cases only out of what crosses that channel. Watching data movement at the kernel is what lets a case span jobs, file access, and destination at once. Ask what the vantage is.
Does it have to read your data to build the case? Metadata-only by default means the system can tell a pattern is wrong without inspecting content. Content-aware inspection should be there when you want it, never the toll for entry. Ask what the default vantage is.
Does the case carry a response, or only a recommendation? Ask how the tool acts on a confirmed pattern, and whether that action is host-level network isolation from the control plane or an inline control that adds latency and becomes a single point of failure.
So, the real fix
Alert fatigue is not a volume you tune away. It is what you get when a tool scores events one at a time and the threat lives in the pattern across them. Fewer alerts is not the fix. A different output is: a case that already did the correlation, resolved the moves to an identity, and weighed the sequence against how that identity actually moves data.
If your stack can hand you "jsmith read 412 files" but cannot hand you "here is what jsmith's data did over six days, resolved to the job behind it, scored against normal, and why it is a case," the conversion is still landing on a human.
To see how the kernel-to-case path runs on your own data movement, the fastest version is a 30-minute call, engineer to engineer. No deck, just the architecture.