A bank spends more per head on security than any other industry, and still loses the data from the inside. Capital One, 2019: 100 million accounts. The person responsible held legitimate credentials and API access. Nothing flagged the drift until terabytes had already left.
That is the pattern across insider losses. The credentials are real. The access was granted on purpose. What no tool in the stack watches is the move itself, while the data is moving. Authentication events, API calls, network traffic: all logged, all monitored. The path the data takes after access is granted goes unwatched.
Every Control Checks the Move at the Moment of the Move
Picture the stack a bank runs. Endpoint detection at the application layer. Network monitoring at the perimeter. SIEM pulling logs from both. CASB for cloud services, DLP for egress. On paper, the gaps are covered.
Each of those controls asks one question at the instant of the move. Is this user authenticated. Is this call under the rate limit. Is this destination approved. The answer is yes every time, because every individual move is permitted. The danger never lives in a single move. It lives in the sequence, and nothing in the stack reads the sequence.
A trader copies client data to an external drive. The application layer reads "legitimate user, authenticated session." DLP might catch the drive if someone configured it for USB, which means someone had to guess the vector first. The move itself goes unrecorded: this data, off this host, to this destination, by a process that has never moved data this way. Banks treat that move as plumbing. It is the control surface they are missing.
Three Moves That Pass Every Check
Start with a DevOps engineer at a mid-sized trading firm. Production database access, justified by on-call duty. For six months they query client account tables at 2 AM local, small result sets, the standard query tool every time.
The SIEM logs each authentication. All clean. The result sets sit below the DLP threshold. The network monitor sees encrypted TLS to the database, exactly what it expects. What it never sees is the query tool staging those results locally and pushing them to personal cloud storage. Both halves are permitted alone.
query_tool (authenticated user session)
├─ reads from the client account table (expected)
└─ pushes results to an outside destination (unexpected, no business justification)
The EDR sees query_tool. Signed, allow-listed, authorized user. It does not tie the read of client data to the move that carries it out. By the time the bytes hit the network the cloud client has already encrypted them, and network DLP reads TLS to a known provider as routine for a DevOps role. Resolve the move to the job behind it and the anomaly is plain: this tool read client account data and then sent it outside, a sequence it has never produced on this host.
Now a data analyst at a retail bank. Read access to transaction records for fraud work, audited quarterly. Her Python script queries the warehouse, runs real analysis, writes results to a network share. Daily at 9 AM for two years.
Then a second run appears at 11 PM. Same queries, same share, logged as successful both times, documented as "automated retry logic." The 11 PM run writes to a subdirectory symlinked to an external SFTP mount. Network monitoring flagged that traffic once, then signed off on it as a "third-party vendor integration."
Application logs show Python running SQL and writing files. Authorized. Network logs show SFTP to an approved vendor. Authorized. The divergence only shows in the movement: writes that used to land on a local share now cross out of the environment. Same job, same person, data leaving across a boundary it never touched in two years.
Last, a contractor at an investment bank with read-only API credentials for client portfolios. Rate-limited, logged. He uses portfolio_viewer, an internal tool that calls the portfolio API. Every call carries his credentials, stays under the limit, lands in the gateway log.
He has edited his local copy. Alongside the normal calls, it pulls portfolio data in parallel, throttled to stay under the threshold, and hands the responses to a second path out of the environment. The gateway sees authorized calls from an authorized tool and has no reason to look further. Network monitoring sees HTTPS to internal APIs and HTTPS to an external bucket, both expected for the role. Watch the movement and it surfaces: portfolio_viewer is pulling client portfolio data on this user's credentials and sending it outside, a move it has never made on this host. The way the data moves no longer matches the job the tool is supposed to do.
The Threat Already Has Credentials
Banks build for audit and for the perimeter. Identity governance, segmentation, encryption: every one of those controls assumes the threat is unauthorized access. Insiders, stolen credentials, and compromised vendors all hold authorized access. The perimeter lets them through because letting authorized access through is its job.
Catching them means watching the move at runtime, while the data moves. Not at the API layer, where authorized actions look authorized. Not at the network layer, where encrypted traffic looks encrypted. At the point where the move happens and resolves to the job behind it.
That discipline is Data Movement Governance, and it is what Hilt does. One lightweight collector watches data movement at the kernel, the vantage where the move is visible. It runs metadata only by default, off the path, so it reads how data moves without reading your data. Content-aware inspection is there when you want it; you do not need it to catch the pattern.
The collector stays small: roughly 0.1% of one core and 4-8 MB of memory, single-tenant inside your own cloud, so events never leave your account. Off the path, it never sits inline and never blocks, drops, or alters traffic.
Each move resolves to a probabilistic, source-dependent identity: who or what is moving the data, and the job it belongs to. Hilt weighs the move against the behavior of the person, the role, and the workload around it. When a move breaks from all three at once, that is the high-confidence anomaly, and it arrives as a case with the narrative attached, not one more raw alert. The response is host-level network isolation, quarantine driven from the control plane, applied to the host the pattern is forming on.
Your existing tools handle unauthorized access, malware, and outside attackers, and they should keep doing it. Hilt is additive: it covers the case that already holds credentials and works inside your perimeter, where the only tell is how the data moves. Banks spend enough on security. The open question is whether anything they run is watching the data move. If you want to see how that watching works on your own hosts, we can walk through it in a 30-minute technical call.