← Back to blog

A candidate sits down for a 90-minute proctored exam. The browser is locked. Screen recording is active. A camera watches their face. By every signal the proctoring software can measure, the session looks clean.

Underneath that clean session, the candidate has an API call running. It goes out through a mobile hotspot—a second network interface the proctoring software can't see. The session ends. No violations. The certificate is issued.

This gap isn't a bug in any particular product. It's a structural limitation of where browser-based proctoring operates—and why it fails specifically against AI assistance, even when everything else works.

What Browser-Based Proctoring Actually Monitors

Most proctoring tools—Honorlock, ProctorU, Respondus Monitor—operate entirely within the browser environment. Their detection surface covers:

• Tab and window focus: flags when a candidate leaves the exam tab
• Clipboard monitoring: catches paste events from external text
• Webcam and gaze tracking: alerts on unusual eye movement or absence from frame
• Screen recording: captures what's visible on the candidate's display
• Extension blocking: prevents known cheat tools from loading in the browser

Against their original threat model—looking up answers in another tab, Googling during the exam, copy-pasting from notes—these controls are reasonably effective. That's not the threat model anymore.

The Network Layer Is Outside the Browser's Reach

When a candidate uses a large language model during an exam, the critical action happens at the network layer. Not the application layer where browser proctoring lives.

An API call to OpenAI, Anthropic, or Google looks identical to any other HTTPS request. Encrypted payload. Legitimate destination domain. From the browser's perspective, nothing happened—because nothing in the browser did happen.

The candidate might route this through:

• A phone on a separate cellular connection, entirely outside the monitored machine
• A second laptop running silently behind the primary one
• A local model like Ollama running on their own hardware, requiring zero internet traffic at all
• A friend in another room, feeding answers via WhatsApp

None of these generate browser events. None trip the detection rules browser-based proctoring is built to catch.

Eye Tracking Doesn't Close the Gap

Eye gaze tracking is designed to catch candidates reading from a second screen. Look away from the camera long enough, and the system flags it.

But submitting a question to a language model doesn't require looking away. A candidate reads the exam question, formulates a mental prompt, glances down at their phone for two seconds—the same motion as checking the time—and returns to the screen. Gaze tracking generates no alert.

The behavior is indistinguishable from a candidate thinking. Because externally, it is.

Why Clipboard Monitoring Misses the Most Common Attack

Clipboard monitoring catches a specific version of AI cheating: copy the question, paste into ChatGPT, copy the answer back. That's a detectable, high-friction pattern.

The more common version doesn't touch the clipboard. The candidate reads the question, mentally rephrases it, types it into a second device, reads the response, and types their own answer by hand. Zero clipboard events. Zero paste triggers.

This doesn't require technical sophistication. It requires a phone and two minutes.

What Network-Layer Detection Catches Instead

A detection approach built at the network layer has access to fundamentally different signals:

DNS queries. Every AI API call begins with a DNS resolution for api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, and similar domains. DNS queries are visible before encryption is applied. A network-layer guard can block or flag these lookups at the moment a session starts.

Traffic to AI provider IP ranges. Even with DNS blocked, some attackers hardcode IP addresses. Network-layer filtering can apply rules against the ASN blocks owned by major AI providers.

Local model activity. A candidate running a local AI model generates no external API traffic—but the device still shows observable activity: AI inference processes running, local inference services active, and model weight files present. OS-level monitoring can detect all of these signals. Network-layer controls see none of them.

VPN and proxy activation. If a candidate activates a VPN mid-session to tunnel their AI traffic, network-layer detection can identify the tunneling behavior and flag the session. Browser-based tools can't see this at all.

Hardware resource anomalies. Running a local AI model causes a measurable, sustained increase in GPU memory usage that normal exam activity doesn't produce. Hardware resource monitoring can catch this pattern even when other signals are obscured.

None of this is visible to software running inside a browser tab. Each layer requires an agent that operates at or below the OS.

The Cost of a Clean Audit Log

The practical problem with this gap isn't abstract. It shows up in credential inflation.

When AI cheating goes undetected, the credential still gets issued. The candidate's resume carries a certification they used AI assistance to obtain. The hiring team that makes a decision based on that credential gets a false signal.

The proctoring software reports a clean session. The platform reports zero violations. Neither number reflects whether the exam result is valid.

Browser-based proctoring provides real assurance against a specific, older class of cheating. Against AI assistance—which requires no browser action whatsoever—it mostly provides a clean audit log for a session that wasn't clean.

What to Look For in a Proctoring Stack

If you're evaluating proctoring infrastructure for AI cheating specifically, the relevant questions are:

1. Where does the detection agent run? Inside the browser, or at the OS and network level?
2. Does it monitor DNS traffic? This is the first signal of external AI API usage.
3. Can it detect local LLM activity? Running a model locally leaves no external traffic—detection requires process, port, filesystem, and GPU monitoring.
4. Does it cover all network interfaces? A second network connection (hotspot, VPN) bypasses any detection that only monitors the primary interface.
5. Are session artifacts cryptographically verifiable? Clean session logs are easy to generate. A tamper-evident audit trail is not.

These questions separate detection architectures built around AI cheating from those that were retrofit to mention it.

Aiseptor operates at the WireGuard VPN and DNS layer, giving exam platforms network-level visibility into AI API usage before any browser event fires. The agent also runs OS-level scans for local LLM processes, open inference ports, model files, and GPU memory anomalies. Learn how the integration works →