A Cloud Access Security Broker sits between your people and the SaaS apps they use. It enforces who can reach Salesforce, Workday, and Box, on which device, from which network, under which policy. For the problem it was built to solve, sanctioned and unsanctioned SaaS access, a CASB is the right tool, and Hilt does not replace it.
But your most valuable data leaves on access you granted on purpose. The user is sanctioned. The app is sanctioned. The session passes every CASB policy because every policy was written to permit exactly this. What a CASB cannot see is the movement underneath the app: what the data actually did once the session was allowed, and whether the pattern across those moves is the breach.
That is the layer this post is about. Where the CASB owns the SaaS control plane, and where Hilt adds a different kind of visibility under it.
What a CASB does well
A CASB governs the SaaS edge. It discovers shadow IT, the apps employees adopt without telling anyone. It enforces access policy: block this app, allow that one, require managed devices for the third. It applies DLP rules at the API or proxy layer, scanning files for patterns as they move into and out of sanctioned apps. It manages OAuth grants and flags risky third-party app connections. For organizations standardizing on a handful of cloud suites, this is real, load-bearing control, and it is the right place to enforce it.
Two deployment modes carry most CASBs. API-mode connects to the SaaS provider's API and inspects data at rest and configuration after the fact. Inline mode, via forward or reverse proxy, sits in the session path and enforces policy as traffic flows. Both are good at their job: governing the relationship between a user and an application.
The relationship between a user and an application is not where the dangerous pattern lives.
Where the CASB stops
A CASB sees the app boundary. It evaluates the session: is this user allowed into this app, on this device, right now. Once the answer is yes, the data inside that session has been handed off, and the CASB's vantage point ends at the edge of the apps it brokers.
Three blind spots follow from that vantage:
Movement that never touches a brokered app. A service account pulling from a production database to an analytics job. A scheduled sync between two internal systems. A model training run reading a corpus off object storage. None of this passes through the SaaS edge, so none of it is in the CASB's field of view. The most sensitive data movement in many companies happens machine-to-machine, well below the user-to-app layer a CASB governs.
The permitted move that is wrong only as a pattern. A finance analyst with legitimate Box access copies records in small batches, off-hours, over two weeks, through the sanctioned app, on a managed device, from the corporate network. Every session satisfies every CASB policy because every session is, individually, exactly what the policy was written to allow. No single move breaks a rule. The danger is the shape across moves, and a session broker evaluates sessions one at a time.
What happens after the data leaves the app. A CASB can govern the download from a sanctioned app. It cannot follow the file once it lands on the host and moves again: copied to a local directory, staged into a personal sync client, pushed out through an approved channel the CASB does not broker. The data has left the SaaS control plane, and with it, the CASB's line of sight.
These are not failures. They are the edges of what a session broker was designed to do. A CASB answers whether this access is allowed. The harder question is what the data did with the access, and whether that fits.
Where Hilt adds a layer
Hilt watches data movement at the kernel, on the host and on the workload, metadata only by default, off the path. The vantage point is underneath the app, not at the SaaS edge. So the moves a CASB cannot see, machine-to-machine syncs, database reads into analytics jobs, the file that moves again after it lands, are exactly the moves Hilt is positioned to observe.
Each move resolves to a probabilistic, source-dependent identity: which user or service account, which job behind it, which destination, and whether this fits what that identity normally does. The collector does not have to read your data to see that a pattern is wrong. It runs at roughly 0.1% of one core and 4 to 8 MB of memory per host, single-tenant inside your own cloud, and events never leave your account.
Take the finance analyst again. The CASB allowed each Box session, correctly, because each one was permitted. Hilt sees the same activity from underneath and resolves it as a pattern: the job is unusual for that identity, the access shape is a slow bulk read of high-value paths in a short window, the cumulative volume is unusual despite the sanctioned channel. Any one signal is noise. Together they are a case, not an alert. And because Hilt is not bound to the SaaS edge, it also sees the second hop, the file moving again after it left the app, which is past the CASB's boundary entirely.
The response is host-level network isolation: quarantine from the control plane, never inline. Hilt does not sit between the user and the app the way an inline CASB proxy does. It observes the movement and isolates the host at the network when the pattern warrants it. It never blocks, drops, or alters traffic in the session path.
Where Hilt does NOT replace the CASB
Hilt is not a SaaS access broker, and you should not deploy it as one.
It does not discover shadow IT or inventory which cloud apps your employees adopted. It does not enforce who may reach Salesforce on which device from which network. It does not govern OAuth grants, manage risky third-party app connections, or apply policy at the SaaS API. It does not sit in the session path to allow or deny an app at the edge. Those are the CASB's job, and a CASB does them well. Hilt has nothing inline at the app boundary to do them with.
The clean division: the CASB owns the SaaS control plane, who gets into which app and under what policy. Hilt owns the movement underneath, what the data did once the access was granted, resolved to the job behind it and scored against how it normally moves. One governs the door. The other watches what walks through it and where it goes next.
How they work together
The two layers compose, they do not compete. The CASB keeps unsanctioned apps out and enforces access policy at the edge, shrinking the surface to the apps you actually trust. Hilt watches the data movement under those trusted apps and across the hosts and workloads the CASB never sees, and catches the permitted-but-anomalous pattern that, by design, satisfies every access policy on the way out.
A CASB tells you the access was allowed. It was. That is the point, and the reason the dangerous move slips past it. The remaining question, the one a session broker was never built to answer, is whether the data, having been allowed, did something it has never done before.
If your stack can govern which apps your people reach but cannot tell you what the data did underneath them, that is the layer to look at next. We are glad to walk through where Hilt sits relative to your CASB on a 30-minute engineer-to-engineer call, and to be candid about the moves it sees and the ones it leaves to the broker.