Student Data Privacy, FERPA and Web Filtering

The new leak path

“Shadow AI”: where student data actually walks out the door

Districts spend real money securing their student information system, then discover the data leaving through a browser tab. These are the patterns technology directors report most — none of them malicious, all of them leaks.

The pasted IEP

A staff member pastes a paragraph of an IEP or behavior plan into a free chatbot to “make it sound better.” Disability status, accommodations and a child's name are now on a third-party server under unknown retention terms.

The drafted parent email

A teacher asks an AI assistant to draft a note home about a student's grades and attendance — including the grades and attendance. Education-record details leave district control in the prompt itself.

The uploaded roster

A spreadsheet of names, IDs and scores goes into a free “analyze my data” tool before report cards. Convenient, fast, and a bulk disclosure of records to a service with no agreement with the district.

The oversharing student

Companion and character chatbots — we track 470+ of them — are designed to draw users into personal conversation. Students volunteer their school, schedule, home life and mental-health details to systems built to keep them talking.

The free extension

Browser add-ons that “summarize any page” can read every page — including the gradebook and email a staff member has open. Data flows out continuously, without anyone pasting anything.

The photo and the voice

Face-swap and voice-cloning tools (200+ and 250+ tracked, respectively) turn a yearbook photo or a few seconds of audio into biometric-grade data — and into harassment material aimed back at classmates and staff.

Privacy at the DNS layer

Stop student data reaching tools nobody approved

Every request starts with a DNS lookup, so a category rule can stop a school device from reaching an unapproved site at all. The hosted CIPA filter does this by domain and does not read what students type.

Block whole categories, including AI / LLM Tools, then allow the ones your district has vetted.
Per-site always-allow lists keep approved vendors reachable.
The filter is not a monitoring tool and never looks inside a page.

Reports and readiness checklist in the hosted filter, used as a record of privacy controls

99.99%

of the active internet already has a category

categories to allow or block, AI tools among them

1 setting

on the router or firewall points the school at the filter

Look at our hosted filter for student data privacy Talk to us about student data privacy Look up a category for student data privacy

Key insight

Why web filtering is now a privacy control

The Pattern

No breach, no intruder, no ransom note

None of these scenarios involves a breach in the traditional sense. There is no intruder, no ransom note, and usually no log entry anyone reviews. The data is disclosed outward, voluntarily, by the very people responsible for protecting it — which is why security tooling aimed at attackers does little here.

The Control

Clear policy plus a filter that enforces it

The controls that work are the boring ones: clear policy about which tools are approved, and a filter that quietly keeps the unapproved ones out of reach on school networks and devices. That is the honest case for web filtering as a privacy control.

The Connection

Same mechanism, dual purpose

Filtering is usually discussed as a child-safety and CIPA measure — blocking obscene and harmful-to-minors content. But the same mechanism that keeps a student off a gambling site can keep an education record from being pasted into an unvetted chatbot, because both come down to controlling which destinations school traffic can reach.

What’s ahead

This guide covers

The rest of this guide covers the legal backdrop in plain English, the specific tool categories most prone to data exfiltration, how our AI-tools blocklist works as a privacy control, and the line between protective monitoring and over-collection.

FERPA in plain English — and where filtering helps

The Family Educational Rights and Privacy Act is the federal law that protects the privacy of student education records. In broad terms, it gives parents (and later, eligible students) rights over those records and restricts schools from disclosing personally identifiable information from them without consent, outside of defined exceptions such as properly governed school officials and service providers.

Here is the connection to filtering: when personally identifiable information from an education record is fed into a consumer AI tool that has no agreement with the district and no defined role, that information has left the school's control. Whether any individual paste amounts to a violation is a question for your counsel — but no district wants to be researching that question after the fact. Preventing school networks and managed devices from reaching ungoverned tools keeps the question from arising.

Education records stay within tools the district has actually vetted
Approved platforms with proper agreements remain fully available
Staff get a clear technical signal of what is and isn't sanctioned
Category logs document diligence if a disclosure is ever questioned

The two-question test for any web tool

Q1: Could student personally identifiable information plausibly end up in this tool — typed, pasted or uploaded?

Q2: Does the district have an agreement governing how this vendor handles that data?

“Yes” then “no” is the shadow-AI zone. Policy says don't use it; filtering makes that the default instead of a hope. Tools that pass both questions belong on the allow list, not the blocklist.

Why age matters to your filter policy

Elementary: default-deny AI Middle: narrow allow list High: approved tools, taught well

Policy by grade band: because our database supports different rules per grade band, building or user group, “governed AI access” can mean something different for a 7-year-old than for a 17-year-old — one policy engine, age-appropriate outcomes.

COPPA, consumer tools and the under-13 problem

The Children's Online Privacy Protection Act governs how online services collect personal information from children under 13, generally requiring verifiable parental consent. Many consumer AI tools respond to this by simply setting a minimum age in their terms and doing little else — which means a large share of the tools students find were never designed, or lawfully offered, for younger children at all.

A school cannot outsource that judgment to a sign-up checkbox a fourth grader clicks through. Practically, districts handle it by keeping general-audience AI tools unreachable for younger grades and steering usage to education platforms operating under proper consent structures and agreements. Filtering by grade band is the enforcement half of that decision; the legal analysis of any specific tool belongs with your counsel and privacy officer.

General-audience AI kept away from under-13 users by default
Grade-band policies that widen as students get older
Consistent enforcement on take-home devices, not just at school

Website	Categories in our data
chatgpt.com	AI / LLM Tools
character.ai	AI / LLM Tools, Web-based Applications
grammarly.com	AI / LLM Tools
quillbot.com	AI / LLM Tools
photomath.com	AI / LLM Tools, Education/Reference
canva.com	Web-based Applications, AI / LLM Tools

The control layer

An AI-tools blocklist as a student-data-privacy control

You cannot govern what you cannot enumerate. Our AI Tools database classifies the AI tool landscape daily — delivered alongside the main domain database in every supported format — so your policy has something concrete to act on.

16,328+AI-tool domains

165+Subcategories for precise policy

470+Companion / character chatbots

450+Deepfake & voice-clone tools

Finds tools before students do

Roughly 300,000 newly registered domains are screened every day, so the essay writer that launched this week is categorized before it circulates through a group chat.

Category-level nuance

Eighteen categories and 165+ subcategories mean you block companion chat and deepfake tools everywhere while allowing a vetted writing assistant for high schoolers — governance, not prohibition.

Fits the filter you run

The list deploys through our own filtering or plugs into existing infrastructure as CSV, DNS blocklist/RPZ, PAC or hosts files, firewall EDL, or API — so the privacy control doesn't wait on a platform migration.

Draw the line

Governed tools vs. shadow tools: what actually differs

The point of filtering is not that AI is bad — it's that the same capability carries entirely different privacy risk depending on who governs it.

Privacy question	District-approved tool	Shadow AI tool
Agreement governing student data	Contract or established terms with the district	Consumer terms nobody read
Where prompts and uploads go	Known, documented handling	Unknown servers, unknown retention
Use of data for model training	Addressed in the agreement	Often permitted by default
Age-appropriateness for minors	Assessed before rollout	A checkbox at sign-up
Deletion when a family asks	A defined process exists	No one to even ask
Who knows it's being used	IT, teachers, parents	Whoever found the link

Summary

What a privacy-aware filter contributes, concretely

Prevention at the point of paste

The block page appears before the prompt is sent, not in an audit six months later. For voluntary disclosure — the dominant leak path — prevention is the only control that operates in time.

An enforceable approved list

Acceptable-use policies fail quietly when every tool is one search away. Filtering turns the approved-tool list from a PDF into the actual shape of the network.

Evidence of diligence

Category-level reports document that the district actively governed where student data could travel — useful for board questions, parent conversations and E-Rate or privacy reviews alike.

Room to say yes

Because policy is granular by category and grade band, blocking the risky 90% of tools is what makes it safe to approve the useful 10% — governed AI in classrooms instead of a blanket ban that students route around.

Playbook

Building a privacy-first filtering program in five moves

The districts that handle this well treat filtering as one instrument in a privacy program, sequenced roughly like this.

Inventory the approved-tool list

Write down which platforms are actually sanctioned for student data, and under what agreements. This list is short in most districts — which is the point. Everything else is, by definition, ungoverned.

Block the exfiltration-prone categories

Turn on the AI-tool categories with the worst privacy profiles — companion chat, deepfake and face-swap, voice cloning, free “upload your file” analyzers — district-wide, then set grade-band rules for the rest.

Extend policy to take-home devices

Shadow AI use peaks after the last bell. Policy that follows managed devices home closes the largest gap, and keeps the message consistent: the rules protect the student, not the building.

Teach the “why” alongside the block

CIPA already expects education on appropriate online behavior; fold data privacy in. A student who understands that a chatbot log is forever is safer on every network, including the ones you don't control.

Review categories and exceptions each term

New tools appear daily; so do legitimate requests from teachers. A standing review of category reports, block statistics and exception requests keeps the policy current without ad-hoc firefighting.

The balance

Monitoring without over-collecting

The irony to avoid

There is an irony to avoid here: a filtering program justified by student privacy can itself become a privacy problem if it hoards data. CIPA requires schools to monitor minors' online activity — it does not require warehousing every keystroke of a child's browsing history indefinitely, and a program that does so has simply moved the over-collection in-house.

Data minimization is the principle

The principle that keeps districts on the right side of this is data minimization: collect what the safety and compliance purpose requires, at the least invasive level that works, and keep it no longer than needed. Category-level filtering is naturally aligned with that principle. To demonstrate CIPA compliance and spot risk trends, you rarely need a named student's full URL trail — you need to show that harmful categories are blocked and to see aggregate patterns that flag where policy or education should tighten.

A useful default for any district

Report at the category level, escalate to individual detail only on defined safety triggers, and put retention limits in writing. Transparency with students and families about what is collected — and what deliberately isn't — builds the trust the whole program runs on.

Bonus protection: Filtering also protects privacy in a second, less obvious way: by blocking hostile infrastructure. Phishing pages that harvest student and staff credentials are a data-privacy incident by another name, and credential theft remains a leading path into district systems. The same category engine that governs AI tools classifies and blocks that infrastructure daily — see our overview of malware and phishing protection for schools.

Compliance frames reinforce each other

Keep the compliance frames straight, because they reinforce rather than duplicate each other. CIPA is the funding-linked content-filtering and safety obligation — our plain-English guide to what CIPA requires covers it — while FERPA and COPPA are the privacy frames around student records and young children's data. One well-designed filtering program produces evidence for the first and materially reduces exposure under the second and third.

Managing student data exposure: ad hoc or with a filter

A short comparison for the privacy officer and the IT lead.

Privacy question	Relying on policy and trust	Hosted CIPA filter
Unapproved AI sites	Hope staff remember the list	AI / LLM Tools category can be switched on for blocking
A newly launched tool	Noticed after the fact	Covered through the category data
Devices at home	Outside the rule	Private encrypted link keeps the same rules
Evidence for a review	Recollection	Activity reports and a policy record
Approved vendor access	Informal exceptions	Always-allow list per site
Software on devices	Agents to maintain	Nothing installed on computers

See the hosted CIPA filter for student data privacy Request a pilot for student data privacy

FAQ

Student data privacy and filtering: common questions

Does FERPA require schools to block AI tools?

No law names a technology to block, and this page isn't legal advice. FERPA restricts disclosing personally identifiable information from education records without consent outside defined exceptions — and pasting record content into a consumer tool with no district agreement is exactly the kind of uncontrolled disclosure a privacy program exists to prevent. Filtering is how districts make “don't put student data in unapproved tools” an enforced default rather than a memo, which is why privacy officers increasingly ask for it.

Is a chat prompt really an “education record” problem?

It can be, because what matters is the information, not the container. A prompt that includes a named student's grades, disability status, discipline history or schedule carries personally identifiable information from records the school maintains. Once submitted, the district has no agreement covering retention, reuse or training on that text. Treat prompts and uploads to unvetted services the way you'd treat emailing a record to a stranger — and filter accordingly.

Should we just block all AI tools district-wide?

Usually not, and blanket bans age badly. Districts that block everything push usage onto personal phones and home networks where no protection or teaching follows. The workable pattern is graduated: default-deny for the high-risk categories (companion chat, deepfakes, voice cloning), narrow grade-band allowances for vetted instructional tools, and classroom instruction on safe use. Our 165+ subcategories exist precisely so the policy can say “yes, this one, for these students” instead of only “no.”

How does the blocklist keep up with new AI tools?

By watching domain registrations rather than waiting for reports. Around 300,000 newly registered domains are screened every day, and confirmed AI tools are added to the 16,328+ already tracked, sorted into 18 categories. Updates ship daily, so the paraphraser that appeared on Monday is typically blocked by policy before most students have heard of it. That cadence matters because shadow AI is a moving target — last year's list is not a control.

Does privacy-focused filtering conflict with CIPA's monitoring duty?

No — they meet in the middle. CIPA expects schools to monitor minors' online activity as part of an internet safety program; privacy principles say collect no more than the purpose needs. Category-level monitoring satisfies both: it demonstrates the required oversight and produces audit evidence without warehousing every student's full browsing history. Write the escalation triggers and retention limits down, tell families how it works, and the two obligations reinforce each other.

What about staff — can we filter their AI use too?

Yes, and you probably should, because staff handle far more student data than students do. The same category policies apply to staff device groups, typically with a wider allow list than students get plus an easy exception path for legitimate needs. Many districts pair blocking with guidance: approved tools for lesson planning are fine; student names, grades and IEP content stay out of anything unapproved. The filter enforces the boundary while training explains it.

We already have a filter for CIPA. What does this add?

A CIPA-era category set covers obscenity, pornography and material harmful to minors — it was never built to enumerate AI services. The AI-tools blocklist adds that missing layer: 16,328+ domains across essay writers, homework solvers, image generators, deepfake and voice tools, and companion chat, each blockable by category and grade band. It feeds your existing stack via CSV, RPZ, PAC/hosts, firewall EDL or API. Packaging and costs are on our pricing page.