Every security control makes a choice about where it stands relative to your traffic. That choice decides almost everything else about it: how fast your workloads run, what happens when the control fails, and whether the infrastructure team will ever let it near production.
There are two places a control can stand. Inline, between your data and where it is going. Or off the path, watching the move without standing in it.
Most of the tools that promise to stop data from leaving stand inline. That is how they stop it. The cost of standing there is the thing nobody puts on the datasheet.
What inline buys, and what it costs
An inline control sits in the flow. Traffic passes through it on the way out. A proxy, a firewall rule, an inline data loss prevention appliance, a packet filter: each one reads the move as it happens and decides whether to let it continue.
The appeal is obvious. If you are standing in the doorway, you can close the door. Inline controls can block.
The cost shows up in three places.
First, latency. Every move now waits for a decision. For most office traffic this is invisible. For a workload where microseconds are the product, it is disqualifying. A trading firm does not get to add a hop to order processing because the security team wants visibility. The infrastructure team owns that call, and the answer is no.
Second, failure mode. A control in the path is a thing that can fail in the path. When an inline appliance falls over, you choose between fail-open, where traffic flows unwatched, and fail-closed, where traffic stops. Neither is a good morning. The control you added to reduce risk has become a new way to take the whole thing down.
Third, blast radius. Anything inline is a single point of failure for everything that passes through it. You scale it, you cluster it, you babysit it, because the day it is wrong, it is wrong for all of production at once.
These costs are why so many teams running latency-sensitive or high-throughput workloads have quietly accepted partial coverage. The performance profile of an inline control is incompatible with their infrastructure, so they do without and hope the rest of the stack catches things.
Off the path means observing, not intercepting
Off the path is the other choice. The control does not sit in the flow. It observes the move from the side, as it happens, and never stands between your workload and the wire.
This is the architecture Hilt uses. One lightweight collector watches data movement at the kernel, metadata only by default, off the path, single-tenant inside your own cloud. It sees the move. It does not carry the move. Traffic does not wait on it, does not route through it, and does not stop if it stops.
The difference is not a tuning detail. It is structural. An inline control is part of the transaction. An off-the-path collector is a witness to the transaction. A witness can be wrong, can be slow, can be restarted, and the transaction is untouched. That is the entire point.
Because the collector observes rather than intercepts, the overhead is the overhead of watching, not the overhead of standing in the way. On the order of 0.1% of one core and 4 to 8 MB of memory per host. For latency-sensitive infrastructure the performance penalty is effectively zero, because the collector reads the move instead of waiting on it.
The objection: if it does not sit inline, how does it stop anything?
This is the real question, and it deserves a straight answer.
Off the path means the collector never blocks a move at the moment of the move. It is not in the doorway, so it cannot close the door on a single packet. If your security model depends on stopping the individual transmission inline, off the path is not that.
But here is the wedge, and it is the whole reason inline blocking matters less than it seems. Your most valuable data leaves on access you granted on purpose. The move that costs you is a permitted move. Every inline control you own already lets it through, correctly, because each individual action is allowed. An inline blocker positioned to catch policy violations does not fire on a move that violates no policy.
Every move is permitted. The pattern across moves is the breach.
A researcher copies proprietary code in small chunks, off-hours, through an approved transfer channel, over two weeks. No single action breaks a rule. An inline control evaluating each move sees nothing to block, because there is nothing, per move, to block. The danger is the shape of the whole sequence, and the shape is invisible to anything deciding one move at a time.
Seeing the pattern requires watching the movement itself, at runtime, resolved to who is doing it and the job behind it. Hilt resolves each move to a probabilistic, source-dependent identity: which workload, which user, which job, which destination, and whether this fits what that identity normally does. When the deviation forms, it shows up across layers at once. The job is unusual for that identity. The access is a bulk read of high-value paths in a short window. The destination volume is unusual despite the approved channel. Any one signal alone is noise. Together they are a pattern, and a pattern is a case, not an alert.
How an off-the-path control responds
Observing is not the end of the story. When the pattern resolves into a case, Hilt responds with host-level network isolation, quarantine, issued from the control plane. The host is cut off from the network. The move that was forming does not complete.
Notice what this is not. It is not packet filtering. It is not an inline decision made on the wire. The collector never dropped, altered, or held a single move on its way out. The response comes from the control plane, acts at the level of the host, and lands because the pattern was seen in time, not because the collector was standing in the flow waiting to swat one transmission.
You get the thing inline controls promise, a move that does not complete, without the thing inline controls cost: the latency, the failure mode, the blast radius of a box in the path.
Where this fits with what you already run
Off the path does not mean you tear out your inline controls. It means you stop asking them to do a job they were never positioned to do.
Your proxies and inline DLP enforce policy on the moves that should be policy decisions. Keep them. They are good at evaluating whether an action is allowed. Your endpoint sensor catches malware, exploits, and live intrusions, the work Hilt does not do. Hilt can stand in for the endpoint sensor on the data movement side, and many clients retire their EDR once it is in place; keep one alongside only if you want that malware and intrusion layer too.
What none of them can do, because of where they stand, is evaluate the pattern of movement across permitted actions by legitimate identities through approved channels. That work needs a vantage off the path, watching the move at runtime, resolving it to an identity, and scoring it against how your data normally moves. It is a layer your stack was not designed to carry, added without putting a new box in the flow.
If you are weighing a control that claims kernel-level visibility, the question to ask first is where it sits relative to your traffic. Inline buys a block at the cost of latency, a failure mode, and a single point of failure. Off the path buys the pattern, in time to act, at the cost of almost nothing.
If that tradeoff is one your infrastructure team would want to see drawn out properly, it is a short, engineer-to-engineer conversation, about thirty minutes, to walk through exactly where the collector sits and what it costs in your environment.