Network-Layer Proctoring: What It Sees That a Lockdown Browser Cannot

A candidate sits a locked-down remote exam. The browser is sealed, the tab list is empty, and the proctoring software reports a clean session. Meanwhile an overlay renders answers directly to their screen, or a local model answers from the same machine, and neither event ever touches the browser. That gap is architectural, not a configuration mistake. A lockdown browser can only enforce policy inside its own process, and the tools that matter in 2026 do not run inside it.

Network-layer enforcement moves the boundary. Instead of asking the browser to police itself, the session runs inside an ephemeral enclave that controls what the device can reach and inspects the device for the specific techniques cheating tools depend on. This article covers where browser-level enforcement structurally fails, what network- and OS-level enforcement can and cannot see, and how the integration works.

Where the Browser Boundary Ends

A lockdown browser is an application. It can refuse to open a second tab, disable copy and paste, and detect when it loses focus. Every one of those controls operates inside its own process, and the application layer is where its authority stops.

The tools candidates actually use in 2026 sit outside that boundary. An overlay is a separate operating-system process drawing to the screen. A remote-access session is a separate process holding a network connection. A local model is a separate process consuming GPU memory. None of them need the exam browser's cooperation, and none of them appear in its view. Asking a lockdown browser to stop them is asking a program to observe something it was never given access to.

This is also why the failure is silent. A tool that operates outside the browser does not trigger a browser-level alert; it produces a clean session report. The absence of a flag is not evidence of an uncompromised exam, which is the part that matters to anyone certifying a result.

Moving the Enforcement Point

Aiseptor runs the session inside an ephemeral enclave: a per-session environment that applies a default-deny network policy, so only the assessment platform and explicitly allowed resources resolve. It activates when the exam starts and removes itself completely when the session ends. There is no kernel driver, no persistent agent, and no background process left behind. You can read the mechanics on network-layer exam security.

Context for why this matters now: Talview's 2026 AI Threat Index puts 88% of online assessments at active risk from AI-assisted cheating, and CodeSignal reports that fraud on proctored coding assessments rose from 16% to 35% in a year.

Three Techniques, and How Each Is Caught

Detection here targets techniques, not process names. A named-binary blocklist is obsolete the moment someone recompiles a fork under a different name, which happens within the hour. Each of the following is a property the technique cannot discard without ceasing to work.

Invisible Overlays

An overlay that stays hidden during screen sharing has to ask the operating system to exclude it from capture. On Windows that means setting the screen-capture-exclusion flag (WDA_EXCLUDEFROMCAPTURE). The flag is the whole point of the tool: an overlay that drops it becomes visible in the recording and stops being useful. Checking for it catches the technique regardless of what the binary is called. Background on the category is in the invisible AI overlay entry, and Cluely detection covers the best-known example and its forks.

Hosted AI Services

Any call to a hosted model has to resolve a name and open a connection. Under a default-deny policy that resolution simply fails, so the connection never opens and no prompt leaves the device. This is the cheapest technique to stop and covers the largest share of attempts, because most cheating tools are thin clients over somebody else's API.

On-Device Models

A model running locally is the honest edge case for any network-based approach. Once it is loaded it needs no outbound traffic at all, so network policy alone will not see it. What it cannot hide is the GPU memory it occupies: loading a model produces a VRAM delta consistent with a model being resident. That signal is what identifies it, not its traffic. Anyone claiming network enforcement alone defeats local inference is describing something that does not follow from how local inference works.

Remote-Access Sessions

Proxy services that sit an exam on a candidate's behalf need a live connection between the candidate's machine and the operator's. That connection is subject to the same default-deny policy as any other outbound path. The commercial scale here is not hypothetical, and the figures below are our own: reviewing publicly indexed proxy-testing marketplaces, we found pay-after-pass services advertising openly, priced from roughly $200 for entry-tier certifications up to around $10,000 for multi-part accounting and finance licensure exams. The full breakdown and method are on our certification fraud page.

What This Approach Does Not Do

Being specific about the limits is part of the argument, and any vendor unwilling to state them is asking for trust they have not earned.

• No webcam, microphone, keystroke logging, or screen recording. The enclave collects network-access signals and device-activity metadata, nothing else.
• No kernel driver. That avoids the system-instability and privilege problems that come with deep OS access, at the cost of not seeing everything a driver would.
• No behavioural or anomaly scoring. Enforcement is technical: a path is either allowed or it is not. There is no model guessing at intent from mouse movement.
• Not a replacement for identity verification. Confirming the right person is sitting the exam is a separate problem from confirming their environment is clean.

Retention is 24 hours by default, and the design is GDPR- and CCPA-compliant. A SOC 2 Type II audit is in progress, targeted for Q3 2026.

Integrating It

Integration is a REST call. The assessment platform issues POST /api/v1/sessions with the candidate and exam details, and receives a session_id, a status, an onboarding_url to send the candidate to, and an expires_at. Session lifecycle events arrive as HMAC-SHA256-signed webhooks, so there is nothing to poll. Full endpoint and field detail lives on the developer docs.

Most integrations are running in production in under a business day. Pricing is usage-based and billed per session, with no seat minimums and no long-term licensing, so cost tracks assessment volume rather than a forecast made a year in advance. Aiseptor for assessment platforms covers the embedding model in more detail.

The Short Version

Browser-level proctoring is not failing because it is badly built. It is failing because the threats moved outside the process it can observe, and no amount of refinement inside that process changes what it can see. Moving enforcement to the network and OS layer restores visibility over the techniques that matter, provided you are honest that a locally running model is caught by GPU evidence rather than by network policy, and that identity verification remains a separate job.

Frequently Asked Questions

What is the difference between a lockdown browser and network-layer proctoring?

A lockdown browser enforces policy inside its own process: it can block a second tab, disable copy and paste, and notice lost focus. Network-layer proctoring enforces policy on what the device can reach, and inspects the device for specific cheating techniques. The practical difference is what happens with a tool that never runs in the browser, such as an overlay or a remote-access session. The browser cannot see it; network- and OS-level enforcement can.

Does network-layer proctoring require a kernel driver?

No. Aiseptor runs as an ephemeral enclave with no kernel driver and no persistent agent, and it removes itself at session end. That avoids the system-instability and privilege concerns that come with driver-based tools. The trade-off is explicit: without driver-level access it does not see everything a driver would, which is why detection targets specific, hard-to-discard techniques rather than attempting total visibility.

Can network-layer security detect AI overlays like Cluely?

Yes, by the technique rather than the name. An overlay that stays hidden during screen sharing must set the operating system's screen-capture-exclusion flag, because an overlay visible in the recording is useless to the candidate. Detection checks for that flag, so recompiled forks under new names are caught the same way as the original. Blocklists of process names do not survive contact with a fork; this does.

How does it handle on-device models that never touch the network?

Network policy alone does not catch them, and it is worth being direct about that. A model already loaded on the candidate's machine needs no outbound traffic. What it cannot avoid is occupying GPU memory, so a VRAM delta consistent with a resident model is the signal that identifies it. Any claim that network enforcement by itself defeats local inference does not hold up.

What does it collect, and is it privacy-compliant?

It collects network-access signals and device-activity metadata. There is no webcam, no microphone, no keystroke logging, and no screen recording. Default retention is 24 hours, the design is GDPR- and CCPA-compliant, and a SOC 2 Type II audit is in progress targeted for Q3 2026. Because the enclave is ephemeral, nothing persists on the candidate's device after the session ends.