One row in your payroll database is a person, fully drawn. Home address. Date of birth. Social Security number. The account the paycheck lands in. What the medical plan covers and who the dependents are. Immigration status. There is no test copy of this and no redacted version. The real record is the only record, and you hold one per employee.
So you locked the platform down. Encryption at rest and in transit, role-based access, audit logs, SSO, SOC 2. Keep every bit of it. None of it answers the question that decides whether the data is actually safe.
That question is not whether a move was allowed. Almost every move out of an HR system is allowed. It is whether the pattern across the allowed moves still looks like work.
The exports are supposed to happen
Employee data is built to leave. Payroll runs push compensation and bank details to a payment processor. Benefits sync to carriers and brokers. A general ledger export carries salary into accounting. An HRIS integration mirrors the org chart into your identity provider, your ticketing tool, and whatever SaaS apps onboarding touches. Reporting jobs drop CSVs for finance and the analytics warehouse. Offboarding hands a record to a background-check vendor.
Each of those flows is configured, approved, and logged. An HR platform that did not move employee data would not be an HR platform.
So the theft and the routine sync look the same to anything watching for unauthorized access. The permission check passes either way. What separates a normal benefits sync from the same connection quietly draining the employee table is the pattern, and the pattern is the one thing your access layer was never built to read.
What the blind spot looks like here
Three shapes, every move in them individually allowed.
A reporting integration is scoped to read employee data for a weekly headcount export. Credentials valid, access correct. Across two weeks it starts pulling full records, including bank and tax fields it never touched, in larger reads, at hours nobody runs reports. No permission was exceeded. The role allowed all of it from the start. The behavior is what changed.
A payroll administrator who has given notice exports compensation and PII in small slices over several days, through the same reporting tools she opens every morning, to a destination already approved for exports. Each export clears policy. Bulk reads of the highest-value fields by one identity in the days before a known last day: that is the breach, and no single export contains it.
A third-party benefits vendor reached through a partner integration gets compromised. The connection is right. The token is valid. Only the volume and the timing of what passes through it move. The permission stays correct while the behavior turns.
In all three the platform's controls did exactly their job and confirmed the actor was allowed. They were never asked whether this identity, running this job, at this hour, moving this much of this kind of data, fits how the data moves on a normal Tuesday.
Why your stack does not close it
Access controls judge permission one request at a time. They are good at it. They do not hold a baseline of the movement itself stretched across months.
DLP and CASB watch the application and network layers and catch the loud cases: a database screenshotted into an email, a bulk download to personal cloud storage. Worth catching. But they ask whether a given action was allowed, not whether the run of allowed actions behind one identity has gone wrong. A slow, low-volume drain through an approved channel reads as ordinary traffic.
Audit logs record that the exports happened. You read them once the disclosure letter is already in draft. The data left before you opened the file.
This is not slack diligence. It is where the tools sit. They check the door. The danger is the pattern of who keeps walking through it, carrying what, how often, to where.
Seeing the pattern while it moves
A dangerous pattern is only visible while the data is moving. Predictive tools guess ahead of it and bury the team in false alarms. Forensics name it after the loss. Runtime is the only vantage that catches it forming.
Hilt watches data movement at the kernel, metadata only by default, off the path. It reads that a pattern is wrong without reading the payroll file, and it does not sit between your data and its destination. The collector is single-tenant inside your own cloud, about 0.1% of one core and 4 to 8 MB of memory per host. It never blocks, drops, or alters traffic.
Each move resolves to a probabilistic, source-dependent identity: which integration or user, which job, which destination, and whether that fits what the identity normally does. When the reporting integration starts pulling fields it never read, in larger volumes, at off-hours, the deviation lands on several layers at once. The job is wrong for that identity. The access is a bulk read of high-value fields in a tight window. The destination volume is off despite the approved channel. One signal is noise. The three together are a pattern, and a pattern is a case, not an alert.
When the pattern crosses into a real anomaly, Hilt responds with host-level network isolation, quarantine from the control plane, so the move stops without anything sitting inline in your payroll path. The events that built the case never leave your account.
What you carry, and the gap over it
Run an HR and payroll system and you hold the most sensitive data many customers will ever hand a vendor, plus the regulatory weight that rides with it: GDPR, CCPA, HIPAA where benefits and health data overlap, and a lengthening row of state privacy laws. Your access controls and audit logs are necessary. Keep all of them.
What they do not give you is a baseline of how employee data actually moves, so the export that clears every permission check but breaks the pattern surfaces as a case while there is still time. Hilt does not replace your access layer, your DLP, or your audit trail. It adds the runtime layer the rest of the stack was never built to cover: the move itself, resolved to the job behind it and scored against how the data normally moves.
Ask what this integration's data actually did over the last two weeks, resolved to the identity and the job behind it, against how it normally moves. If you cannot answer, that is the gap, and it sits over the most personal data you hold.
If that answer is worth having, the fastest way to see how it maps to your environment is a 30-minute, engineer-to-engineer call. No deck. The architecture, and where it would sit.