A nightly analytics export was scoped to anonymized engagement metrics. Someone upstream adds a field to the event schema. Now student names and email addresses ride inside the same approved export, to the same approved warehouse, on the same schedule. No rule fired. The destination was always allowed. Children's records left the building as a side effect of a job working exactly as designed.
That is the failure mode edtech keeps walking into. Personalization is the product, and personalization means moving student records all day: out of the SIS, into the analytics warehouse, over to a single sign-on provider, into a district dashboard, and now into the AI tutoring features every roadmap bolted on over the last two years. You built each of those paths on purpose. You scoped them, reviewed them, approved them. The access is correct.
Most student-data security stops there. It asks who can log in, what they can see, whether the bytes are encrypted at rest. Those are access questions, and they answer whether a move is allowed. They say nothing about the pattern across moves, which is where the real exposure on student data sits.
Why your stack stays quiet
A data loss prevention tool checks two things: is the destination allowed, and does the file match a content rule. Your integration partner is allowed. Your analytics warehouse is allowed. Your model endpoint is allowed. DLP made its call in advance, and in advance every one of these moves looks like the thing you designed. The tool is not broken. It was built to catch the forbidden move, and none of these are forbidden.
Walk through how the danger actually arrives, and the forbidden move never appears.
A tutoring assistant is supposed to send a sanitized prompt to a model endpoint. A regression starts stuffing the full student record into the context window. The endpoint is approved. The traffic looks like an AI feature talking to a model, because it is one. Minor children's records now flow to a third party on every request, and nobody knows until someone reads that code path months later. Or a regulator asks first.
A partner integration scoped to one district's roster starts pulling several, because a query filter broke. Same connection. Same credentials. Same allowlisted partner. Only the pattern changed.
The destination was right. The permission was right. The shape of the movement is the breach.
The audit you owe and cannot answer
Student data drags obligations most data does not. FERPA governs education records. COPPA governs data from children under thirteen. State statutes like New York Ed Law 2-d pile on more, and they turn on one question: where did the data go, and was that disclosure authorized for that purpose.
That is a movement question, not an access question. A platform with flawless permissions can still owe a disclosure because data went somewhere its purpose did not cover. When a parent complains or a district inquires, the demand is not "could someone access this record." It is "show us everywhere this child's record actually went, and why." Most edtech platforms can produce an architecture diagram. They cannot produce what the data did last Tuesday, move by move, resolved to the job behind each one.
Watch the move while it moves
The dangerous pattern is only visible at runtime, while the data is in motion. Predictive tools guess before the fact and mostly guess wrong. Forensics reconstruct it after the fact, once the disclosure letter is already written. The move itself is the only place left.
Hilt watches data movement at the kernel, metadata only by default, off the path. One lightweight collector runs single-tenant inside your own cloud, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It does not sit inline. It does not block, drop, or alter traffic. It does not read student work to do its job. It watches each move and resolves it to a probabilistic, source-dependent identity: which service, which job, which destination, and whether this fits what that flow normally does.
When the analytics export starts carrying names, the deviation stands out against how that export has always moved: same destination, new field class, a volume profile that no longer matches anonymized metrics. When the tutoring feature starts shipping whole records, the call to the model endpoint stops looking like what that feature has always sent. One signal alone is noise. Together they are a case, not an alert. Hilt writes the case, and when a move warrants it, isolates the host at the network from the control plane. It never steps into the path of your live traffic.
Content-aware inspection is there when an investigation calls for it. It is not the toll you pay at the door. The default vantage is metadata, which is what lets a platform handling minor children's data see that a pattern is wrong without reading the children's data to find out.
What it does not replace
This is additive. Access controls, encryption, and single sign-on keep doing their jobs. Your DLP still catches the clumsy upload to a personal account. Your cloud posture tool still finds the open bucket before anyone touches it. None of that goes away.
What none of it was built to do is judge the pattern of movement across permitted actions, on student data, while it moves. The gap is structural, not a vendor failing. Runtime data movement governance closes it by watching the move itself.
So when a district asks where a student's record went, or a regulator asks whether an AI feature handed minor data to a third party, the difference between a clean answer and a scramble is whether anyone was watching the movement, resolved to the job behind it, the whole time.
If your platform cannot say what a given student's data did last week, which service moved it, where it went, and whether that fit how the flow normally behaves, that is the gap. If you want to see how this reads against your own data flows, set up a 30-minute technical call, engineer to engineer.