Zero trust checks the door. It does not watch the person once they walk through it.
The analyst logs in with a valid token, off a managed laptop, from an approved network segment. Posture passes. Authorization passes. Zero trust says yes and turns away. Three hours later that same session pulls the full customer table and pushes it to a storage bucket it has never touched. Every request along the way was permitted. Nothing rang.
That is the gap. Zero trust answers one question well: is this entity allowed to access this resource right now? It never asks the second question: does this move fit the identity behind it. A valid credential doing something out of character looks identical to a valid credential doing its job. The token is real either way.
Identity is checked once, not watched
Verify explicitly. Least privilege. Assume breach. The principles are sound, and they kill the old assumption that being inside the network means being trusted. Keep them.
But least privilege scopes what a credential can reach, not what it does inside that scope. A database administrator needs broad access to production. So when that DBA starts querying tables they have never opened, copying rows to external storage, running admin commands at 3 AM on a Saturday, zero trust sees an authorized identity touching authorized resources. Granted. Granted. Granted. Character is not in the model.
Stolen credentials walk through the same door. An attacker with a phished token or a hijacked session inherits every permission the victim had. MFA narrows the entry path, not the behavior after entry. Once the attacker is in, zero trust cannot tell them from the real user, because it only ever judged the identity, never the moves that identity makes.
The tools watching after the door are looking elsewhere
The usual instinct is that something downstream catches the rest. It mostly does not, because each tool is built around a different question. EDR watches for bad binaries and suspicious commands on the host. CASB watches cloud API calls. Network detection watches traffic shape. None of them asks whether this move, by this identity, out of this job, is anomalous.
Timing makes it worse. By the time those tools look, the data has already moved or been wrapped. Copy a database out over HTTPS and the bytes are encrypted before they leave the host. Network tools see a TLS session to somewhere new, maybe a volume spike, and they lose the part that decides whether the move is dangerous: which job started it, what it touched, whether the pattern fits the identity behind it.
The move is legible in one place, while it happens, at the kernel, before the application packs a payload and before encryption hides it. EDR might flag a known-bad tool. It will wave through a sanctioned one. The signal was never the tool. The signal is the move against the identity that made it.
Governing the move
Catching an anomalous move means knowing what a normal one looks like for this identity, in this role, on this workload. So watch the movement itself, not just the grant. Where is the data going. Out of which job. Touching what. A lightweight collector watches data movement at the kernel, metadata only by default, off the path. Content-aware inspection is there when you want it; the default reads the shape of the move, not the contents of your files. Each move resolves to a probabilistic, source-dependent identity and the job behind it, so no move is judged alone.
That resolution is what single-axis tools cannot reach. A developer pushing code at midnight is fine for that developer, that role, that workload. The same push out of a production workload, or from an identity that has never pushed before, is where the anomaly sits. One unusual move means little. An identity that starts reaching for data it has never opened, out of a job it does not run, toward destinations it has never contacted, all inside a short window, is a different thing entirely. The pattern across moves is the breach. No single move is.
Runtime, because after is too late
A tool that surfaces the move hours later surfaces a forensics report. The data is already gone and you are drafting a disclosure letter. That is the split in the market. Predictive tools guess ahead of time and miss the permitted move. Detection and response tell you once it is over. The move is visible at runtime, on the movement itself, in time to act. That is the third option.
Watching at the kernel makes it cheap enough to run everywhere instead of on a chosen few hosts. The collector sits off the path, around 0.1% of one core and 4 to 8 MB of memory. It never sits inline and never blocks, drops, or alters traffic, so it adds no tax to the work the host exists to do. Because it resolves each move to an identity instead of matching a fixed rule, what reaches you is behavior, not noise. As the picture of normal fills in per identity, per role, per workload, the dangerous pattern sharpens, and you get a case to act on rather than a queue of alerts to sort by hand.
Keep zero trust. Add the move.
Zero trust is not broken here. It is doing the job it was built for: kill implicit trust, enforce least privilege, contain lateral movement from a compromised host, shrink the blast radius. None of that goes away.
Data movement governance answers the question zero trust was never built to ask. It catches the insider working outside their pattern. It catches the stolen credential doing what the real identity never would. It sees the anomalous move that happens after zero trust has correctly said yes, and it responds with host-level network isolation from the control plane (quarantine), containing the host without ever sitting inline.
Zero trust verifies the request. Governance watches the move. One asks whether this identity is allowed to do this. The other asks whether this move fits the identity behind it, given everything that identity has done before. Same access, two questions, and the second one is the one that catches the breach you already permitted.
If your architecture verifies every request and still cannot tell a normal move from a dangerous one, that is worth thirty minutes. We can walk through where the move becomes visible in your own environment on a technical call.