Blocking Second Device Pivots: Neutralizing the Network-Layer Blind Spot in Exam Security

A candidate reads the exam question, glances at a phone below the webcam's field of view for two seconds, the same motion as checking the time, and types the answer a language model just gave them. Nothing about that glance trips a gaze-tracking alert. Nothing about it touches the browser. The proctoring software reports a clean session, because a second device sitting just outside the camera's frame was never something it was built to see.

This is a second-device pivot: routing exam content, or an AI-generated answer, through hardware the primary proctored device never controls. Here's why browser-based and webcam-based tools miss it, and what actually closes the gap.

How the Pivot Works

The mechanics are simple, which is exactly why they're hard to catch behaviorally. The candidate reads the question on the proctored device, moves it (mentally or by typing) to a second device, an AI assistant or a person on the other end generates a response, and the candidate reads or copies it back. None of that requires the proctored device to do anything unusual. The proctored device's screen, camera feed, and browser tab all look exactly like a normal exam session, because from the proctored device's perspective, nothing happened.

Why Gaze Tracking Doesn't Catch It

Gaze and behavioral proctoring is tuned to flag sustained or repeated looking-away, the pattern of someone reading answers off a second screen for an extended stretch. A brief downward glance to check a phone doesn't fit that pattern. It looks like a candidate pausing to think, because externally, that's exactly what it looks like.

Why Lockdown Browsers Don't See It

A lockdown browser enforces rules inside its own window: no new tabs, no copy-paste, no navigating away. It has no visibility into a second physical device connected to the same Wi-Fi network, because that device never touches the browser process at all. This is a scope limitation of the category, not a bug in any specific product.

What Network-Layer Enforcement Catches Instead

A pivot to a second device for AI assistance still depends on that AI assistance reaching a model somewhere, whether the model runs in the cloud or on the second device itself. Network-layer enforcement doesn't watch the candidate's eyes; it controls what the primary device's network path is allowed to reach for the duration of the session, across every interface:

• All network interfaces, not just the primary one. A control that only monitors the main Ethernet or Wi-Fi connection is bypassed the moment a candidate tethers a phone as a hotspot. Aiseptor applies its session policy across every interface on the device.
• Default-deny by destination, not by device. Only the exam platform and any resources it explicitly allows are reachable during the session. AI inference endpoints and remote-access relays fail to resolve, regardless of which device or interface a request originates from.
• An ephemeral enclave, not a permanent agent. The policy applies only for the session's duration and leaves no residual software behind.

This doesn't eliminate every second-device scenario; a candidate reading a question aloud to a person in another room over a phone call, with no data ever touching the proctored machine's network path, is a different problem that sits outside what any device- or network-layer control can reach. What network-layer enforcement does close is the far more common pattern: an AI assistant reached from, or reachable by, the proctored device itself.

Where This Fits in a Broader Defense

Second-device pivots are one entry in a wider set of techniques (invisible overlays, on-device LLMs, remote-access tools) that all share the same underlying requirement: reaching an AI model or a remote party the exam didn't authorize. Aiseptor enforces a single default-deny policy that closes all of them at once, rather than building a separate detector for each new device pattern. See the full architecture, or request free access to test it against your own assessment.

Frequently Asked Questions

What is a second-device pivot in online exams?

It's the use of a phone, tablet, or second computer outside the monitored device to receive AI-generated answers or relay exam content, bypassing browser- and webcam-based controls that only observe the primary device.

Can a lockdown browser detect a phone being used to cheat?

No. A lockdown browser only controls its own application window and has no visibility into a separate physical device on the same network.

Does webcam proctoring catch this?

It can catch sustained or repeated looking-away, but a brief glance at a phone is hard to distinguish from normal thinking behavior, so it's an unreliable signal against this specific technique.

How does network-layer enforcement stop a second-device pivot?

It applies a default-deny network policy across every interface on the primary device, so AI inference endpoints and remote-access relays aren't reachable during the session, regardless of which device or connection a request comes from.

Does this require a kernel driver or persistent software?

No. Aiseptor's enclave is session-scoped and removes itself completely when the exam ends.

Is this compatible with our existing proctoring vendor?

Yes. It's designed to run alongside webcam and behavioral proctoring, covering the device and network layer those tools don't reach.