Server-side vs device filtering: why extensions do not hold

Almost every filtering product a school has been sold works the same way: it sits on the device. A browser extension, a managed Chrome profile, a DNS filter on the school network, a kiosk-mode tablet. They differ in detail and share one property — they protect the machine they are installed on.

That was a reasonable design when the machine was the point of access. It is a poor fit for AI, for a specific reason worth spelling out.

The account is the thing being used, not the computer

A student signs in to an AI tool. The conversation, the history, the generated images — all of it belongs to the account and follows it everywhere. A filter attached to the school laptop knows nothing about what that same account did on a phone at home.

So a school that has filtered its devices has filtered roughly a third of a student's AI use: the third that happens in the building, on equipment the school owns, during the hours it is open.

Three ways device filtering comes apart

The second device

The most common and least sophisticated bypass. Nothing was hacked; the student simply used a phone. Any protection that depends on which hardware is in front of the child is defeated by the child owning more than one piece of hardware.

Removing the extension

Managed profiles make this harder, not impossible, and the skill required is a web search. More importantly, a student who removes an extension usually leaves no trace that the protection stopped applying — the school's dashboard shows a device that has simply gone quiet.

Filtering the wrong layer

Network and DNS filters decide whether a site can be reached. They cannot see inside an encrypted conversation with a site they have allowed. Once a school permits an AI tool at all, a DNS filter has no further opinion about what is asked of it. The choice becomes all or nothing, which is why so many schools ended up blocking AI entirely.

What server-side filtering changes

If the check runs on the server, between the student's request and the model, then it is a property of the account. There is nothing installed to remove and no device to swap.

Concretely, the request arrives, the platform loads the rules that apply to that student — the school's policy, plus anything their parents added — and evaluates the request against them before any model is asked to answer. A request that fails is refused and recorded. The same sequence happens whether the student is on a school Chromebook or a phone on their own wifi.

This also makes the rules legible. Because the decision happens in one place, a school can see what was blocked without installing monitoring software on anybody's personal phone — which is both more effective and considerably less invasive than the alternative.

What server-side filtering does not solve

It is worth being precise, because overstating this is how trust gets lost. Server-side filtering governs one platform. It does not stop a student opening a different AI tool in another tab. Nothing that runs inside one product can.

What it does is make one tool trustworthy enough to allow — so the school has something to point students toward, rather than only a list of things to forbid. Schools that give students a permitted option see less traffic to the unpermitted ones. A prohibition with no alternative mostly teaches students to be discreet.