A neocloud sells GPUs. What crosses the floor is data: tenant training sets, checkpoints, model weights, customer datasets staged for a run, the artifacts a finished job writes back. The compute is the product. The data is what gets you sued.
And the data leaves on access you provisioned on purpose. You gave a tenant a node and a path into object storage so they could pull their dataset in and push results out. Everything that follows is permitted, because you permitted it. So the question is never whether a move was allowed. It is what the moves add up to.
Density is the business, and the surface
A hyperscaler has spent twenty years grinding on isolation primitives. A neocloud is younger, racing to fill racks, packing dense multi-tenant GPU clusters onto shared storage fabric and a scheduler that drops one tenant's job onto hardware that ran a stranger's job an hour ago.
Tenant A's checkpoint and Tenant B's dataset live on the same fabric. A misconfigured mount, an over-broad service token, a scheduler placing a job with stale credentials: any one becomes data movement no policy flagged, because the access existed. The control plane said yes. Nobody is reading back what moved after the yes.
On a GPU floor the moves that hurt look like this:
- A tenant's job reads a path that belongs to a different tenant, because a volume got remounted and a permission lingered.
- A compromised tenant account stages a large pull from object storage, then writes results somewhere that customer has never written to.
- An orchestration service account, doing the job it was built for, starts shifting artifacts on a cadence that matches none of its prior runs.
- Model weights leave a node toward an egress that was technically open and never once used for that workload.
Every one is permitted. Not one breaks a rule. Your CSPM confirms the configuration. Your network control confirms the route is allowed. The pattern is the breach, and config checks and route checks were never built to see a pattern.
What your stack covers, and where it stops
Your tools are not wrong. They are good at what they cover, and a neocloud should run them.
Wiz tells you the shared volume was mountable by the wrong tenant before anyone mounted it. That is real, and it is upstream of Hilt: fix the posture and the opening closes. A workload agent watches process behavior on the node. A network control governs which routes are reachable. Each answers a question about permission or configuration. Was this allowed. Was this reachable. Was the posture correct.
None of them scores the movement itself, after the grant, against how that identity normally moves data. They confirm the door was supposed to be open. They do not watch what walks through it over the next two weeks, off-hours, in small chunks, down a channel approved for exactly this kind of transfer.
The access is provisioned correctly. The movement through it is what nobody governs at runtime.
Watching at the kernel, without reading tenant data
Hilt is runtime Data Movement Governance. One lightweight collector runs on the host and watches data movement at the kernel, the one vantage where every move is visible no matter which tenant, job, or path produced it. Metadata only, by default. It does not read tenant datasets, model weights, or customer content to do its work. For a provider holding other people's data on shared hardware, that is the difference between governing movement across tenants and becoming a party to what your tenants run. Content-aware inspection is there when a case calls for it. You never have to turn it on to see a pattern is wrong.
The collector sits off the path. It does not stand between a job and its storage, and it does not block, drop, or alter traffic. Figure 0.1% of one core and 4 to 8 MB of memory per host. On a box whose reason to exist is GPU throughput, that is the only footprint a buyer will tolerate. It runs single-tenant inside your own cloud. The events never leave your account.
Every move resolves to a probabilistic, source-dependent identity: which tenant, which job, which service account, which destination, and whether this fits what that identity normally does on your floor. So when a checkpoint-orchestration account starts pulling from a volume it has never touched, toward an egress it has never used, in a size that matches no run, Hilt does not see five unrelated allowed events. It sees one identity moving the wrong way, and writes the case.
From a permitted move to a contained host
When enough crosses at once, the job is wrong for the identity, the read is a bulk sweep of high-value paths, the destination is strange despite the open route, Hilt responds with host-level network isolation from the control plane. It quarantines the node so the move stops, while a human reads a written case, instead of paging an analyst to rebuild the story from logs after the weights are gone. None of it sits inline. It never has to.
That is the trade a neocloud has to make good on. Tenants hand you the most concentrated value in their business and run it next to strangers. You cannot tell them you read nobody's data and also tell them you watch what moves, unless the thing watching works on metadata at the kernel and acts at the network, not in the content.
It does not replace your posture tool, your network control, or your workload agent. It governs the movement those tools permit. Posture closes the door that should not have opened. Hilt watches what moves through the doors you opened on purpose, and stops the move that does not fit.
If you run a GPU floor and you cannot answer "what did this tenant's job actually move last night, resolved to the service account behind it and scored against how it normally moves across these nodes," that is the gap. Bring your fabric and we will walk through where the collector sits and what it would surface, engineer to engineer. Thirty minutes is enough to tell whether the pattern you cannot see now is one you would want to.