Most security stacks treat cloud and endpoint as two different problems. A cloud posture tool watches the workloads. An endpoint agent watches the laptops. They have separate dashboards, separate vendors, and separate budget lines. The split feels natural because the infrastructure looks different: a container in AWS does not resemble a researcher's MacBook.
But the thing you actually care about does not respect that split. Your most valuable data does not live in the cloud or on the endpoint. It moves between them, and through both, on access you granted on purpose.
That movement is one phenomenon. Treating it as two is where the blind spot opens.
Why the split exists
The cloud-versus-endpoint division is an artifact of how security tools were built, not how data behaves.
Cloud security grew out of configuration. Is this S3 bucket public? Does this IAM role have too much reach? Is this workload running a known-vulnerable image? These are posture questions, and they live in the cloud control plane, so cloud tools live there too.
Endpoint security grew out of the device. Is this binary malicious? Did this process spawn something it should not have? Is this laptop patched? These are device questions, and they live on the host, so endpoint agents live there too.
Both are real. Both are good at what they do. Neither was built to answer the question that crosses the boundary: when sensitive data leaves a cloud workload, lands on a user endpoint, and then leaves again to somewhere new, is that one continuous, legitimate job, or is it a pattern that should never happen?
That question has no home in a stack that is split down the middle. Each tool sees its half. The move that matters happens across the seam.
The move that crosses the seam
Here is a concrete shape. A data engineer has legitimate access to a production database in your cloud. He pulls a large extract to a workload he controls, which is normal for his job. From that workload, the data syncs to his laptop through an approved tool. From the laptop, a portion goes to a personal cloud drive through a browser he uses every day.
Every hop is permitted. The database access is in policy. The workload is his. The sync tool is sanctioned. The browser is approved. No configuration is wrong. No malware is present. No single tool in a split stack sees anything it was built to flag.
The cloud tool sees a permitted read by an authorized identity. The endpoint agent sees an approved sync and a normal browser. The pattern, the thing that is actually wrong, lives in none of their fields of view because it is assembled from moves that each tool correctly waved through.
Every move is permitted. The pattern is the breach.
One collector, both sides
Hilt does not solve this by adding a third dashboard that correlates the other two after the fact. It solves it by watching the data movement itself, at the kernel, with the same lightweight collector on a cloud workload and on a user endpoint.
The collector watches data movement at the kernel, metadata only by default, off the path. It runs on a cloud workload in your own account, AWS, GCP, Azure, or Ali Cloud, and it runs on a macOS-compatible user endpoint, and it is the same model in both places. Content-aware inspection is available when you want it; it is not the price of admission, because the system can see that a pattern is wrong without reading your data.
Each move is resolved to a probabilistic, source-dependent identity: which user, which job, which destination, and whether this fits what that identity normally does. That resolution does not change when the data crosses from cloud to endpoint. It is the same identity, the same job, scored against the same baseline. The seam disappears because there was never really a seam in the data, only in the tooling.
When the engineer's extract walks from the production database to a personal drive, the deviation shows up as one connected story: an unusual volume for that job, a destination outside the normal set for that identity, assembled across a cloud read and an endpoint upload that no split stack would have joined. Any one hop is noise. The chain is a case, not an alert.
Why this is a feature, not a billing note
The unification shows up in the pricing too, and it is worth being precise about why that matters.
Hilt prices per collector, per year. One collector covers one host or one workload. The same unit covers a cloud workload (CMG, cloud movement governance) or a user endpoint (EMG, endpoint movement governance). There is no separate cloud SKU and endpoint SKU to reconcile, no per-seat line next to a per-workload line, no two contracts that meet awkwardly in a spreadsheet.
That is not an accounting convenience. It is downstream of the architecture. Cloud and endpoint share one price model because they share one collector, and they share one collector because, to Hilt, they are one way of seeing data move. The clean cloud-plus-endpoint integration that other stacks promise and bolt together with connectors is, here, just what the product is.
The per-collector rate is sized on a short call, because it scales with the volume you actually move, with real discounts at scale. The model itself is fully public: per collector, per year, same unit everywhere.
Where this fits with what you already run
Hilt can stand in for your endpoint sensor, and many clients retire their EDR once it is in place; it watches what your data does once permission has already been granted, across cloud and endpoint at once. Keep an EDR alongside only if you want the malware-and-intrusion layer too, since Hilt does not hunt malware. Your cloud posture tool still tells you the bucket is misconfigured, and it is good at that; Hilt does not evaluate posture. It watches what your data does once permission has already been granted, across both layers at once.
You can swap your endpoint sensor for Hilt, and many clients retire their EDR once Hilt is in place. It is whether anything in your stack today can answer a question that spans the seam: "this identity's data moved from a production workload, to an endpoint, to an external destination, over these hours, and here is whether that matches how that data normally moves." If the cloud tool can answer for its half and the endpoint tool for its half but nothing answers for the whole move, that is the gap, and it is exactly where the dangerous pattern lives.
When the pattern is real, Hilt responds with host-level network isolation, quarantine, from the control plane. It does the same whether the host is a cloud workload or a user endpoint, because the response model is unified for the same reason everything else is. It never sits inline, and it never blocks, drops, or alters traffic to do this. The collector observes the move; the control plane isolates the host.
The bottom line
Cloud and endpoint look like two problems because the infrastructure is two shapes. The data does not care. It crosses the boundary constantly, on access you granted on purpose, and the move that should worry you is usually the one assembled from steps that each half of your stack correctly approved.
One collector model, on both sides, resolved to one identity and one baseline, is what makes that whole move visible instead of two disconnected halves. Not a product bolted to another product. One way of seeing data move.
If you want to see how the same collector reads a cloud workload and a user endpoint as one continuous story, the fastest path is a 30-minute call, engineer to engineer, where we walk through your own architecture.