An analyst pulls three months of account records in one off-hours session, through an approved reporting connection, at a volume that identity has never touched before. Every gate said yes. The login was valid, the query ran against a table the analyst was entitled to read, the connection was on the allow list. Your GLBA program built around access did its job perfectly, and the customer records still left.
This is the move the amended Safeguards Rule is quietly pointed at, and the move most compliance programs cannot see.
Most institutions built their program around the words on the page. Inventory the customer information you hold. Restrict who can reach it. Encrypt it. Name a qualified individual accountable for the whole thing. Good controls, all of them, and all of them about who can reach the data. The customer information itself, names, account numbers, balances, Social Security numbers, transaction histories, leaves on access you granted on purpose. The analyst who pulls a portfolio export, the ops engineer who runs a nightly reconciliation, the vendor integration that syncs records to a CRM each reached the data because you decided they should. The danger is not the access. It is the shape of the movement across those allowed actions, and an access-control program was never built to see a shape.
What the Rule actually asks for
The 2023 amendments went past tightening access. Two requirements point at movement.
The Rule requires you to "monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information." It does not say monitor whether access was authorized. It says monitor the activity of authorized users, the people you already decided should be there, and catch when their use of customer information goes wrong.
The Rule also requires "continuous monitoring or periodic penetration testing and vulnerability assessments." Continuous monitoring of customer information systems is not a quarterly access review. It is a standing claim about what is happening to the data, made while it happens.
Institutions satisfy the first with application logs and the second with infrastructure scanning. Both are real controls. Neither watches the customer data move.
Where the evidence gap opens
Your qualified individual sits down to write the annual report to the board. The access matrix is ready: who is entitled to reach customer information, through what systems. Encryption posture, documented. Authentication enforced, access reviews run on schedule.
Then a board member asks what the matrix cannot answer. Not who could reach the customer data. What the customer data did. Which records moved, resolved to the person and the job behind the move, scored against how that data normally moves on a Tuesday afternoon.
The access logs say the analyst was entitled to query the customer table. They do not say this analyst drained three months of account records off-hours, through an approved channel, at a volume nothing in that identity's history comes near. The export was permitted. The pattern was the breach.
That is the structural gap in a permission-first program. Tools that evaluate authorization confirm the move was allowed. They were never built to read the shape of movement across allowed actions, which is where misuse of customer information hides.
Runtime data movement evidence
The only place to see the pattern is at runtime, while the customer data moves. Not in advance, where predictive controls guess and bury the team in false alarms on moves that were always going to be fine. Not after, in the forensic reconstruction that follows a breach, when the records are already gone and the disclosure clock is running.
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not have to read your customers' data to see a pattern is wrong, which is the right default for an institution GLBA governs in the first place. The point is to protect customer information, not to stand up one more system that ingests it. Each move resolves to a probabilistic, source-dependent identity: which user, which job, which destination, and whether this fits what that identity normally does with customer records.
When the off-hours bulk export forms, the deviation shows up across layers at once. The job is unusual for that identity. The access pattern is a wide read of customer-record paths in a short window. The destination volume is high even through an approved channel. Any single signal is noise. Together they are a case, not an alert. The qualified individual gets a written account of what the customer data did, resolved to the job behind it, in time to act.
That is the gap between logging access and monitoring the activity of authorized users, the words the Rule itself uses.
How this maps to the written program
The Safeguards Rule is satisfied with evidence, not intentions. Runtime data movement evidence answers several of its obligations directly.
Monitoring authorized-user activity. The Rule names this outright. A record of how customer information moved, resolved to identity and scored against normal behavior, is a literal answer to "monitor the activity of authorized users."
Continuous monitoring of customer information systems. Off-path observation of data movement at the kernel runs continuously, not as a point-in-time check, and it watches the data itself, not the perimeter around it.
Incident response. The Rule requires a written response plan. When a misuse case is written, the qualified individual already holds the artifact those plans assume exists: what moved, whose identity drove it, when, and how far outside normal. The reconstruction is done before anyone asks for it.
The annual report to the board. The report describes the status of the program and material matters. "Here is how customer data moved this year, and here is the case we opened when it moved wrong" is a far stronger statement than "here is who was entitled to reach it."
What this does not replace
A runtime data movement layer is additive. It does not stand in for the rest of your Safeguards program. You still need the access controls, the encryption, the multi-factor authentication, the vendor oversight, and the qualified individual accountable for all of it. Those controls shrink who can reach customer information at all, and that surface reduction is foundational.
What they cannot do is tell you what the data did once a permitted identity reached it. That is the layer this adds. The response stays measured. Hilt isolates the host at the network, quarantine, from the control plane. It never sits inline, and it never blocks, drops, or alters traffic, so it adds nothing to the path your customer transactions run on. For a financial institution, a control that cannot slow the business is a precondition, not a luxury.
The question to carry into your next program review
If your qualified individual cannot answer "which customer records moved, resolved to the person and the job behind it, and scored against how that data normally moves," your program proves who could reach the data and stays silent on what the data did. The Rule asks for both.
We keep the explanation engineering-grade: where the collector sits relative to your traffic, what it reads by default, how a case gets written, and where the data stays, single-tenant inside your own cloud, your customers' records never leaving your account. If you want to see how this maps to your Safeguards obligations, the next step is a 30-minute call, engineer to engineer, against your actual environment.