Most data security for defense contractors and suppliers is built around one question: was this person allowed to touch this data? Clearance level, program access, need-to-know, the access control matrix. If the answer is yes, the move goes through. The whole apparatus of controlled-data handling is an apparatus of permission.
That apparatus is real and it works. The problem is that the apparatus is also the blind spot.
Your most valuable data does not leave on access someone stole. It leaves on access you granted on purpose. The cleared engineer on the program is supposed to read the drawings. The integration partner is supposed to receive the interface spec. The subcontractor is supposed to pull from the shared repository. Every move is permitted. The danger is the pattern across moves, and permission tells you nothing about the pattern.
The defense-adjacent shape of the problem
Prime contractors get the attention and the audits. The harder surface is everything adjacent: the second- and third-tier suppliers, the engineering firms, the specialty manufacturers, the software vendors who hold controlled technical data without holding the program itself.
These firms move controlled data constantly, and they move it across boundaries that the prime never sees directly. A machined-part supplier holds drawings for three different programs from two different primes. An engineering services firm has the same five senior people rotating across contracts, each contract with its own data scope. A software subcontractor pulls source and test artifacts from a customer repository on credentials that are, correctly, fully authorized.
Controlled Unclassified Information class data does not announce itself as it moves. It looks like ordinary engineering traffic, because it is ordinary engineering traffic, right up until the pattern is wrong.
Where the permitted-pattern blind spot opens
Consider an engineer who works across two programs for the same supplier. On the program ending this quarter, he has legitimate access to a body of controlled technical data. In his last weeks, he reads broadly across that program's repository: more files, more directories, deeper into reference material he rarely touched before. Each read is authorized. He has the access. No policy is violated, no flag fires.
Then the controlled data moves to a destination that is, on paper, fine. A sanctioned file transfer to a partner. A sync to a sharing tool the firm has approved for exactly this kind of collaboration. Approved channel, approved person, approved data classification.
Nothing in a permission-based stack objects, because nothing was impermissible. The access control system did its job perfectly. It granted what it was configured to grant. What it cannot see is that this identity, on this program, at this point in the contract, is moving controlled data in a shape that does not match how this identity has moved data for the prior year.
That shape is the breach. And the shape only exists at runtime, while the data moves. Not before, where a predictive tool guesses which engineer might be a risk and is wrong most of the time. Not after, where a forensic review reconstructs the loss from logs once the technical data is already at the partner, the competitor, or worse.
Watching the movement, not the permission
Runtime data movement governance asks a different question than the access matrix. Not "was this allowed," but "does this move fit the identity behind it."
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not inspect the contents of controlled drawings or source to do this, and it does not have to read your data to see that a movement pattern is wrong. That property matters more in the defense supply chain than almost anywhere, because the data in motion is exactly the data you are most obligated to keep your own tooling out of. Metadata-only by default means the system sees the shape of the move without becoming one more thing reading controlled technical data. Content-aware inspection is available when a specific case warrants it. It is not the price of admission.
Each move resolves to a probabilistic, source-dependent identity: which user, which job, which destination, and whether this fits what that identity normally does on this kind of data. When the departing engineer's reads broaden and the controlled data flows to the approved partner sync, the deviation shows up across layers at once. The access pattern is a deep read of high-value program paths in a compressed window. The job behind the move is unusual for this identity at this point in the program. The destination volume is unusual despite the sanctioned channel.
Any one of those signals, alone, is noise, the ordinary texture of an engineering firm doing engineering work. Together they are a pattern, and a pattern is a case, not an alert. The system writes the case, with the resolved identity and the sequence of moves, so an investigator reads what happened instead of assembling it from raw logs after the fact.
The deployment constraints defense-adjacent firms actually have
Two constraints rule out a lot of security tooling for this segment, and runtime data movement governance is built around both.
The first is data residency and control. Controlled data should not transit a vendor's multi-tenant SaaS to be analyzed. The path from kernel event to written case runs single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, and the events never leave your account. The vendor does not hold your controlled-data telemetry, because the vendor never receives it.
The second is operational weight. Engineering and manufacturing infrastructure does not have room for a heavy agent that sits between systems and the data they move. Hilt stays off the path, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It is never inline. It does not block, drop, or alter traffic. When a pattern crosses the line, it responds with host-level network isolation, quarantine from the control plane, so a host moving controlled data the wrong way is contained at the network without a control standing inline in the way of legitimate program work.
What this does not replace
Your access controls, your clearance and need-to-know enforcement, your boundary defenses: these are doing necessary work, and runtime data movement governance does not replace them. Permission enforcement keeps the unauthorized out. That is the front door, and it should stay locked.
What permission enforcement was never designed to evaluate is the behavior of authorized movement: the same cleared person, the same sanctioned channel, the same correctly classified data, in a pattern that does not fit. That is a different architecture, and it sits alongside what you run, not in place of it.
For a defense-adjacent firm, the question to put to your own stack is concrete. If a cleared engineer with legitimate program access read broadly across controlled technical data in his final weeks and moved it to an approved partner over a sanctioned channel, what in your environment would have resolved that to his identity and called it unusual while it was happening? If the honest answer is the disclosure letter, that is the gap.
If you want to see how the runtime view resolves a move to the identity and the job behind it, we keep it engineer to engineer. Thirty minutes, one of our engineers and one of yours, on your own infrastructure and your own movement patterns.