A shipper hands you customer records. A carrier pulls a manifest. A customs broker reads PII to file an entry. A 3PL syncs inventory against your order feed. One shipment can touch a dozen organizations before it lands on a doorstep, and not one of them works for you. Your platform is the place all of that data passes through, on access you issued on purpose.
That is the business. That is also where the breach hides.
The data that hurts you most does not leave through a hole in the perimeter. It leaves on the connection you built, reviewed, and approved. Every move is permitted. The pattern across moves is the breach.
Third-party risk is not a checkbox here
Elsewhere, vendor risk is a line item in a procurement form. In logistics it is the architecture. Every handoff is a data movement: a partner reading shipment records, a broker pulling customer PII for a filing, a warehouse system syncing against an order feed.
Each of those connections was sanctioned. Someone issued the API key on purpose. Someone provisioned the SFTP account for a reason. The integration cleared a security review. So when data moves through them, every tool you own waves it through, because waving authorized traffic through is the job those tools were bought to do.
Your stack answers "was this move permitted." The answer is almost always yes. It does not answer "does this move fit the pattern." Nothing in the standard logistics security stack does.
What your controls catch, and what slips past
You run real controls and they hold real ground. An API gateway authenticates the partner and rate-limits the connection. A CASB or DLP tool inspects sanctioned SaaS and flags policy violations. EDR watches endpoint behavior for known attack patterns. A SIEM pulls the logs together. They are good at this, and runtime data movement governance replaces none of them.
They share one frame. Each judges a single action against a rule. Is this caller authorized. Does this file match a sensitive pattern. Is this process a known-bad signature. Each answers alone, in the moment.
The threat in a logistics network does not arrive as one bad action. It arrives as a string of permitted ones. A partner integration that reads a few hundred shipment records a day starts reading tens of thousands, after hours, through the same approved channel. A broker account that pulls PII for the lanes it serves begins pulling lanes it has never touched. A warehouse sync that held the same shape for two years widens over three weeks.
No rule breaks. No signature matches. No alert fires. The access was correct. The behavior changed.
Watch the move, not the permission
The pattern is visible in one place: at runtime, while the data moves. Not before, where predictive tools guess and bury the team in false alarms. Not after, in the forensics and the disclosure letter, once the records already sit with the partner that should not have them.
Hilt watches data movement at the kernel, metadata only by default, off the path. One lightweight collector runs single-tenant inside your own cloud (AWS, GCP, Azure, or Ali Cloud) at roughly 0.1% of one core and 4 to 8 MB of memory per host. It never sits inline. It does not read a customer record to see that a record is moving in a way that does not fit.
Each move resolves to a probabilistic, source-dependent identity: which workload or account, which job behind it, where it went, and whether that matches how the identity normally behaves. When the broker account reaches for lanes it has never served, the deviation lights up across layers at once. The job is wrong for that identity. The access is a bulk read of high-value paths in a short window. The volume is off despite the approved channel. Any one signal is noise. Together they are a case, not an alert.
A permission check asks who you are. This asks what the movement just did.
The partner you cannot audit
The riskiest move often happens on a system you do not run. A partner's credentials get phished. A vendor's integration is compromised upstream. The connection is legitimate, the credentials are valid, and at the connection level the data leaving your platform looks like every other day of partner traffic.
No audit closes this. You issued the access on purpose and the business stops if you revoke it. What you can do is watch how the data behaves once it starts moving, so a compromised-but-authorized partner surfaces as a change in pattern, not as a clean log line you read three months too late.
When the pattern turns dangerous, Hilt writes the case and isolates the host at the network, quarantine, from the control plane. It does not block, drop, or alter traffic inline. The collector observes the move; it never stands in the way of the shipment data your customers pay you to move. When throughput is the product, a control that adds latency is a control you cannot run. Off the path is the only profile that survives.
Questions to put to any tool you weigh
The gap that remains is not negligence. It is structural. Permission-based controls were never built to judge the pattern of movement across a network of authorized partners. That gap sits over the exact thing a logistics platform exposes most: customer PII, shipment records, and partner data, moving constantly across a wide vendor network on access you granted on purpose.
Four questions sort the tools that close it from the tools that do not.
Does it judge the move or the permission? A tool that checks authorization passes every partner integration, because every integration is authorized. Ask whether it baselines the movement itself.
Does it have to read the data? Metadata-only by default means you see a partner connection behaving wrong without reading the records flowing through it. Content-aware inspection should be there when you want it, not the price of running the tool.
Can it run on a throughput business? Ask where it sits relative to traffic. Off the path, observing instead of standing in the move, is the only profile a logistics platform can carry without taxing the thing it sells.
Where does the data stay? For customer PII crossing borders, residency is not optional. The path from kernel event to written case runs single-tenant inside your own cloud, never through a vendor's SaaS. Events never leave your account.
If your stack cannot tell you what a given partner integration's data actually did this week, resolved to the job behind it and scored against how it usually moves, that is the gap, and it sits over your most valuable asset.
If you want to be able to answer that, the next step is a short technical conversation, engineer to engineer, about how data moves across your platform. It runs about thirty minutes.