A benefits application touches five systems before a citizen sees a yes or no: the eligibility engine, the tax record, the identity verifier, the case management platform, a few contractor integrations. Govtech exists to make those handoffs work. Every one of them runs on access someone granted on purpose.
That is also the problem. The records that matter most never sit still. Social Security numbers, health and benefits files, criminal justice history, immigration status: all of it crosses agency boundaries, vendor APIs, and shared exchanges all day, on integrations a contracting officer signed off on. Every move is permitted. The danger is the pattern across moves, and a permission check cannot see a pattern.
A router, not a vault
Picture the perimeter you are defending. It is not a fortified database. A modern public-sector platform is a router for sensitive records, and the records live in motion: between a state agency and a federal verifier, between a benefits system and an eligibility contractor, between one identity provider and the dozen programs that lean on it as the authoritative source.
Interoperability is the point of all of it. NIEM-aligned exchanges and state data-sharing agreements exist so citizen data flows without a clerk re-keying it at every step. The cost of that design is a threat surface that has no edge. It is a mesh of sanctioned paths, each one legitimately open, each one carrying records worth real money to fraud rings, identity thieves, and nation-state collectors.
Why permission checks miss the breach
Your stack answers one question well: was this access allowed. Identity and access management decides who may touch a record. Data-sharing agreements define which agency receives which fields. Audit logs record that the access happened. CJIS, IRS Publication 1075, and state privacy statutes enforce all of it, and they catch the obvious failure cold, the account that never should have had the key.
They miss the move that was permitted on purpose and wrong only in shape.
Take a contractor account inside an eligibility integration. It is authorized to read citizen records, because reading citizen records is the job. Over three weeks it pulls them in small batches, off-hours, through the same approved API it hits every day. Every call sits inside policy. Every call passes the access check. No agreement is violated. The audit log fills with entries that look exactly like the work the account is supposed to do.
Add it up and the account has exported a population-scale slice of citizen identity. No single action tripped a rule, because no single action was the breach. The pattern was.
That is the structural limit of a permission-based control. It evaluates whether each access was allowed. It was never built to ask whether the shape of movement across a thousand allowed accesses is normal for the identity behind them.
The third place to look
Two familiar ways to chase this both arrive at the wrong time. Predictive tools guess the bad actor in advance, classify the sensitive data ahead of time, and fence it with policy. They guess wrong often, they bury understaffed agency teams in false alarms, and they still wave through the move that matched the policy. Forensics runs the other direction. After the breach notice, after the records sit in someone else's hands, an investigator reconstructs what left. By then the citizen is the one reading the letter.
Runtime is the third place, and the only one where the pattern is visible while there is still time to act. Hilt watches data movement at the kernel, metadata only by default, off the path. It does not read the contents of a citizen record to see that the movement is wrong. Each move resolves to a probabilistic, source-dependent identity: which account, which job, which destination, and whether this fits how that identity normally moves data.
When the contractor account starts draining records, the deviation surfaces across layers at once. The job is unusual for that identity. The access is a sustained bulk read of high-value record paths over a long window. The destination volume is unusual even though the channel is approved. One signal alone is noise. Together they are a pattern, and a pattern is a case, not an alert.
Residency and overhead, the two hard constraints
Two facts shape every public-sector deployment, and both favor watching from off the path.
Start with residency. Citizen data cannot route through a vendor's multi-tenant SaaS to be scored somewhere else. Hilt runs single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, and govcloud regions follow the same model. Kernel events become a written case without ever leaving your account. No telemetry pipeline carries citizen records to a third party, which is the first thing most data-sharing agreements and FedRAMP boundaries demand.
Then overhead. Agencies run lean, and the systems carrying this data are often the ones least able to absorb a heavy agent or a control that could stall a benefits determination. Hilt observes the move instead of standing in it: on the order of 0.1% of one core and 4 to 8 MB of memory per host. It is never inline. It does not block, drop, or alter traffic. When movement is dangerous, the response is host-level network isolation (quarantine) from the control plane, not packet filtering in the path of a citizen transaction. The isolation contains the host that is misbehaving without ever putting a gate between citizens and the services they depend on.
What this adds, and what it does not replace
Hilt is additive. Your identity and access management still decides who may touch a record, and it should. Your data-sharing agreements still govern which agency receives which fields. Your audit logging still satisfies the recordkeeping CJIS and IRS 1075 demand. Those controls answer "was this access allowed," and they answer it well. Hilt replaces none of them.
What Hilt adds is the layer none of them was built for: scoring the pattern of citizen-data movement across permitted accesses, at runtime, resolved to the identity and the job behind each move. The breach that hides inside sanctioned interoperability lives in exactly that blind spot.
So put your stack to one question. What did this contractor account's data access do over the last three weeks, resolved to the job behind it and scored against how it normally moves across these agency integrations? If you cannot answer that, the pattern can form to completion before anyone sees it, and the first time anyone does is when the notification goes out.
If you run a govtech platform and want to see how runtime data movement governance maps to your agency integrations, we are happy to set up a 30-minute engineer-to-engineer call and walk through it.