Enforcing a School AI Ban at the Filter Layer

On September 2, Los Angeles Unified told K-12 Dive it was restricting all student access to generative AI for the 2026-27 school year. The day before, New York City Public Schools announced what it called the nation's "most expansive" AI moratorium: no student-facing AI tools from 2-K through 8th grade, covering 600,000 students — two-thirds of the system's enrollment.

Two board votes. Roughly 700,000 students. One year.

Then the work lands on somebody's desk, and that somebody is you. A policy that says "no student-facing AI" is a sentence. Enforcing it is a configuration problem, and it is harder than any blocklist your filter ships with.

Here is the part nobody said in the press release: the AI is not on a website anymore. It is inside the websites the school already requires.

Why a domain blocklist cannot enforce an AI ban

The instinct is to add chatgpt.com, gemini.google.com, claude.ai, perplexity.ai to a block list and call the policy implemented. That catches the 2023 version of this problem. It does not catch 2026.

Where students actually reach AI	What a domain blocklist sees
AI Overviews inside a normal Google search	`google.com` — required for research
Gemini side panel in Google Docs	`docs.google.com` — the district's word processor
Copilot inside Word and Edge	`office.com`, `bing.com` — the district's productivity suite
An AI chat widget embedded in a curriculum vendor's site	The vendor's domain — purchased and approved
A character-companion app mirrored on a `.pages.dev` subdomain	An unclassified domain nobody has ever heard of

Four of those five are domains you cannot block. Blocking google.com to stop AI Overviews ends the school day. Blocking docs.google.com ends the curriculum.

This is the structural problem: AI moved from being a destination to being a feature. Destination filtering is a domain question. Feature filtering is a question about the path, the subdomain, the API endpoint, and sometimes the request body — and you cannot see any of those inside an HTTPS connection unless your filter actually inspects the traffic.

If your filter works from DNS or SNI alone, it can see docs.google.com and nothing else. Every AI feature inside that hostname is invisible to it, by design. The policy is unenforceable at that layer. Not difficult — unenforceable.

The four rules an AI moratorium actually decomposes into

Read either district's policy closely and it is not one rule. It is four, and they interact.

1. Grade-band scope. NYC's ban runs 2-K through 8th grade. High school is untouched. If your policy engine can only express rules per-organization or per-device-group, and your device groups are by school building rather than by grade, you cannot write this rule at all without re-grouping thousands of devices first. LAUSD's is district-wide across all grades, which is simpler — and is the exception, not the pattern to build for.

2. Staff exemption. NYC explicitly allows teachers to keep using AI for instructional planning and operational tasks. So the same tool, on the same network, sometimes through the same shared classroom device, is blocked for one human and allowed for another. That is an identity-scoped rule, not a network rule. A filter that enforces by IP range or by device serial cannot express it.

3. Accommodation exemptions — the one with legal teeth. NYC carves out students with disabilities using assistive technology, multilingual learners, and students in career-readiness programs like computer science. This is not a nice-to-have. An AI-powered text-to-speech or translation tool named in an IEP or a 504 plan is a legally required accommodation. Block it and the district is out of compliance with the student's plan — which is a bigger problem than the one the AI ban was written to solve.

4. Purpose review. NYC said all its technology tools "will undergo an exhaustive review and will be barred if their functionality is ultimately determined not to be mission-critical to learning." Translation: the allow list is going to change repeatedly all year, and every change has to reach devices before the next class period.

Four rules, and they conflict on purpose. A grade-band block says no. An IEP accommodation says yes. Something has to decide which one wins, deterministically, every request, and be able to explain it afterward to a parent.

Precedence is the whole ballgame

Here is the scenario that will happen in the first week, in every district that implements this:

A 6th grader with a documented reading accommodation opens an AI-assisted reading tool on a district iPad. Three rules match that one request:

Grade-band rule: block all student-facing AI, grades 2-K–8
Accommodation rule: allow this specific tool for students on this plan
Safety rule: block AI companion and character-chat apps, all grades, no exceptions

Which one wins?

If your filter resolves this by unioning every matching rule and letting any allow delete any block, the safety rule loses the moment anyone writes a broad allow — and nobody notices, because nothing errors. If it resolves by "most specific rule wins," the accommodation wins here, which is correct, but the same logic later lets a narrowly-scoped allow punch a hole in a CIPA-mandated block.

The design that survives contact with a real district:

Priority decides deliberate conflicts. A higher-priority policy beats a lower-priority one. The accommodation policy is authored above the grade-band policy, so the student gets the tool.
A block is never silently overridden by a lower-priority allow. The safety rule sits at the top and stays there. An allow written three levels down cannot delete it.
Some categories are not exceptable by anyone. Self-harm content, adult content, violence — these are a floor, not a setting. There should be no UI path, no API path, and no priority value that lets an administrator allow-list them. CIPA is not a preference.
Ties resolve deterministically. Same priority, oldest policy wins, and a block wins the tie. Deterministic beats clever, because you will have to explain the outcome to a parent nine months from now.

Every one of these is a decision your filter has already made, whether or not it told you. Find out which one it made before the policy goes live, not after.

The audit question nobody asks until it is needed

The APA report published September 14 makes a point worth carrying into this. Its recommendation is that ed tech policy should not be judged on screen minutes at all, but on what students are doing on screens — what the technology replaces and whether it helps learning. APA CEO Arthur Evans Jr. framed the standard as tools that are "safe, supported by evidence, and can genuinely help students learn."

That standard is unmeetable without logs. If you cannot answer "what did students actually reach, and what did the filter do about it," you are enforcing a policy you cannot evaluate — and when the one-year moratorium ends, the district will have no evidence to decide anything with.

Three questions your filter should be able to answer on demand:

Which rule blocked this request, and why? Not "blocked." The specific policy, its priority, and what it beat.
What did students attempt that we did not have a category for? Unclassified AI tools are the growth area. Weekly, a new mirror or wrapper appears on a domain nobody has classified. If it is silently allowed and never surfaced, it is a gap that grows all year.
How many of these blocks were wrong? A block on a legitimate research tool is a teacher's lesson plan destroyed at 9:05 AM. Somebody has to see the unblock requests and act on them the same day, or staff route around the filter entirely and your data becomes fiction.

Your filter is now the enforcement layer for an academic policy

That is the shift worth naming. For twenty years school web filtering was a compliance obligation: CIPA says block obscenity, you block obscenity, you file the certification. Categories were coarse and nobody outside IT cared about the details.

An AI moratorium is different in kind. It is an academic policy, written by a board, that reaches students only through filter configuration. If the config is wrong, the policy is fiction — the board believes elementary students cannot reach AI, and they can. If the config is too blunt, the policy is a lawsuit — a student's IEP accommodation is blocked and nobody in the building knows why.

Neither of those failures announces itself. They both look exactly like a filter working normally.

A checklist you can run this week

Whether or not your board is considering a moratorium, these are answerable now, and the answers tell you what your filter can actually enforce.

1. Can you block an AI feature without blocking its host? Test it: block Google's AI Overviews while leaving Google search working. If your filter can only act on the hostname, the answer is no, and every AI-inside-a-suite case is unenforceable. This is the SSL inspection question in practical clothing — a filter that cannot see the path cannot act on the path.

2. Can a rule target a grade band? Not a building. Not a device cart. A grade. If your groups are physical, find out today how long re-grouping takes, because the policy will be written in grades.

3. Can the same tool be blocked for students and allowed for staff on the same device? Shared classroom iPads make this concrete. If enforcement is device-scoped rather than identity-scoped, the staff exemption cannot exist.

4. Write down your accommodation exemptions before the ban goes live. Pull the assistive-tech tools named in current IEPs and 504 plans. Every one of them needs an explicit allow at a priority above the ban, authored and tested before day one. This is the failure with actual legal exposure, and it is entirely preventable with an afternoon of work.

5. Ask your vendor, in writing, how precedence resolves. The exact question: "When a block policy and an allow policy both match a request, which wins, and does priority or specificity decide?" If the answer is vague, assume allow wins — that is the common implementation — and design around it.

6. Time a policy change to a sleeping iPad. Not to a dashboard confirmation. To a device that was asleep when you clicked save. The honest number is "however long until it wakes," and if your vendor quotes you a flat number with no exceptions, they are quoting the server, not the device. A dashboard that shows you which devices have not yet received a change is worth more than an optimistic average.

Where we land on this

We are not going to tell you whether an AI moratorium is good policy. Digital Promise's Jean-Claude Brizard called the bans "asking the wrong questions." The AFT's Randi Weingarten supports them. The APA says judge the tool by what students can do after they stop using it. That argument belongs to educators, and it will run for years.

The part we will take a position on: if a district decides something, the filter should be able to enforce exactly that — no more, no less. A ban that silently lets AI through a Google Docs side panel is not a policy, it is a press release. A ban that blocks a dyslexic student's reading tool is not enforcement, it is a compliance incident.

The distinction between those outcomes is not in the policy document. It is in whether your filter can see inside encrypted traffic, scope a rule to a grade and an identity, resolve a conflict deterministically, and prove afterward what it did.

Most K-12 filters were built when the answer to "block AI" was one domain. That era ended. Check which era your configuration is still living in.

KyberGate does full SSL inspection through a cloud proxy network, which is what makes path-level and feature-level policy possible on iPads without a battery-draining on-device VPN. If you are implementing an AI policy this year and want to know what your current filter can actually enforce, get in touch — we will walk your rules with you.

NYC and LA Banned Student AI. Your Filter Is What Decides If That's Real.