A human who steals data trips the alarm by being human. People log in from one place, touch a handful of systems, and go home at night. When a person pulls a hundred gigabytes at 3am, the shape of the day breaks, and most tools catch the break.
A service account has no day to break.
It moves data constantly, on its own, around the clock, by design. The sync job that replicates your production database to the analytics warehouse runs every fifteen minutes, forever. The integration that pushes records to a partner API never sleeps. The backup agent reads everything because reading everything is its job. These accounts carry your most sensitive data, and you granted them that access on purpose, because the business needs the data to flow.
So when an attacker takes one over, there is nothing unusual to find. The account hides in its own normal.
Why the obvious checks do not fire
Lock down what the account can do. Scope its permissions, rotate its keys, vault its credentials, alert on a login from a new IP. Do all of it. It is the right hygiene.
None of it sees the move that matters.
The permissions are correct, because the account is supposed to read that data. The key is valid, because the attacker took the real one. The source IP looks right, because the attacker is operating from inside the environment the account already runs in: a compromised pod, a poisoned CI runner, a host the account legitimately lives on. No failed login. No policy violated. The credential was built to do this work, so the work it is now doing for someone else clears every gate you have.
Every move the account makes is permitted. The danger is the pattern across moves. The account that ships data to your warehouse on a schedule is, on the wire, indistinguishable from the account that ships that same data somewhere new, in chunks, under cover of the traffic it is trusted to produce.
Predictive tools rank accounts by risk before anything happens, and they bury teams in flags on the accounts that were always going to move a lot. Forensics names the abused account after the data is gone, while you read the access logs to write the disclosure letter. The move that does not fit happens in the gap between those two, and neither tool is looking there.
What a compromised service account does differently
Catching abuse means knowing the account's job well enough to see when it stops doing that job. Not its permission scope. Its behavior, learned from how it actually moves data, day after day.
A service account has a tighter baseline than any human. It moves the same kinds of records, between the same source and the same destination, on a rhythm. That regularity is the attacker's problem, not yours. Deviation stands out against a clean baseline far harder than against a noisy human one.
When the account is taken over, the change shows up in the movement, not the credential:
- The destination shifts. The warehouse sync now also writes to a bucket, a host, or an egress path it has never touched.
- The shape of the read changes. An account that streams recent transactions in small batches starts doing a full bulk read of historical tables, or reaches into paths outside its usual job.
- The rhythm breaks. A job that runs every fifteen minutes suddenly runs continuously, or fires a large transfer between its scheduled windows.
- The volume drifts. The move stays under the account's own ceiling, paced slow to look routine, but the total against this identity's history is wrong.
Any one of these, alone, is noise. A new destination might be a new feature. A bulk read might be a one-off migration. Resolved to one identity and seen together, they are a pattern. A pattern is a case, not an alert.
Seeing it at runtime, on the movement itself
The dangerous pattern is only visible while the data moves. Not before, when predictive tools are still guessing which accounts to worry about. Not after, when the logs are a record of where your data went. In between, on the movement itself: that is where runtime Data Movement Governance sits.
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not read your data to know a move is wrong. It resolves each move to a probabilistic, source-dependent identity: which account, which job behind it, which source, which destination, and whether this fits what that identity has done for as long as Hilt has watched it.
For a service account, that resolution is the whole game. The name on the connection proves nothing, because the attacker holds the same name. Hilt scores the move against the baseline it has built from that account's real work. When the destination, the read shape, and the rhythm drift at once, the deviation surfaces across layers and Hilt writes the case: this identity, the job it normally does, the move that does not fit, the destination it has never used, the window it happened in.
The baseline sharpens the longer Hilt runs, because a service account's regularity is the easiest thing in your environment to learn. The better Hilt knows the job, the smaller the deviation it can catch.
When the case holds, Hilt responds with host-level network isolation, quarantine from the control plane. It cuts the compromised host off the network so the account cannot finish the move. It never sits between your data and where the data was going, and it leaves untouched the legitimate copies of that same job running everywhere else. The collector does not block, drop, or alter traffic. It observes, resolves, then isolates the host, not the credential.
Where this fits with what you already run
Your identity and secrets tooling does real work here, and Hilt does not replace it. A vault that rotates keys, scopes permissions, and shortens credential lifetime shrinks the attacker's window and limits the blast radius once they are in. Keep all of it. It makes a stolen credential less useful.
What that layer cannot do is tell you a still-valid credential is being used for the wrong move. By the time a key comes up for rotation, the data may already be out. Hilt adds the runtime layer underneath: not whether the account is allowed to move data, which it always is, but whether the data it is moving right now fits the job you granted that access for.
Ask your current stack one question: what did this service account move in the last hour, resolved to the job behind it, scored against how it normally moves, and is this a destination it has ever used? If nothing in your stack answers that, that is the gap. The account might live in a fintech's payment pipeline, a health platform's records sync, or a model provider's training data flow. Any company that lets a machine identity move valuable data on a schedule has the same one.
If you want to see how the resolution and the baseline work on a service account in your own environment, the next step is a 30-minute call, engineer to engineer. We walk through how Hilt learns a job and flags the move that does not fit, and you decide from there.