← Back to blog

Exam security has a deployment problem. The controls that actually work, network-layer enforcement and OS-level monitoring, traditionally require persistent agents, kernel drivers, and elevated privileges. That friction rules them out for most testing contexts. Candidates cannot be expected to install kernel modules on personal devices. Universities cannot push driver packages to every student machine.

The alternative, lightweight session-scoped enforcement that deploys fast and disappears completely when the exam ends, is a better architectural fit. This post explains why, and what assessment platforms should look for in a session isolation model.

The Problem with Always-On Agents

Most legacy proctoring tools use a persistent endpoint agent model. The agent installs once, establishes a persistent cryptographic identity for the device, and runs in the background across sessions.

This creates several problems.

A persistent agent is a persistent target. When the exam is not running, the agent is still present. A motivated candidate has time between sessions to probe it, tamper with it, or find ways to disable it before the next session starts. There is no "exam is not running" state where the security surface disappears.

A persistent identity can be compromised once and reused. If an attacker obtains or forges the agent's device identity, every future session on that device is affected. Session-scoped enforcement does not have this property. Each session is cryptographically independent of every other session. Compromising one tells an attacker nothing useful about the next.

A persistent agent collects data continuously. This creates legitimate privacy concerns for candidates and liability concerns for platforms. Candidates on personal devices are often uncomfortable with software that runs and reports indefinitely. Enterprises asking employees to install persistent monitoring on personal machines face policy and legal objections.

What Ephemeral Means in Practice

This pattern is what we call an ephemeral exam enclave: a zero-trust session that exists only for the duration of the assessment.

Session-scoped enforcement deploys when the exam session begins and removes itself completely when the session ends. No residual files. No persistent services. No background processes. When the exam is not running, the enforcement layer does not exist.

The implications for security are direct. There is nothing to tamper with outside the session window because there is nothing present. An attacker who wants to disable the enforcement layer has to do it during the active session, under observation, with the enforcement already running.

This is a meaningfully different threat model than always-on agents that can be probed and manipulated at leisure between sessions.

For candidates, the experience is also different. An enforcement agent that runs only during the exam, installs without a kernel driver, and removes itself on completion is less invasive than a persistent monitor. Candidates who would refuse to install a permanent endpoint agent will accept a session-scoped one. That difference shows up directly in exam completion rates.

Gateway-Side Enforcement vs. Device-Side Controls

The other architectural distinction worth being precise about is where enforcement decisions are made.

Device-side enforcement, including browser extensions, application blocklists, and local DNS configuration, makes policy decisions on the candidate's machine. That means the candidate's machine is the point of trust.

A motivated candidate can probe device-side controls. Rename a binary. Modify a configuration file. Use a secondary network interface. The control is on the device. The device is in the candidate's hands.

Gateway-side enforcement moves the policy decision off the device entirely. All outbound traffic from the candidate's device routes through an enforcement gateway. The gateway applies the session's approved-domain policy. Whatever process on the candidate's device makes a request, regardless of its name, its origin, or which binary runs it, the request goes to the gateway. If the destination is not permitted, the connection is dropped.

There is no device-side configuration the candidate can modify to change this outcome. The policy runs at the gateway, not on the device.

This is why network-layer session isolation closes the gap that browser-based proctoring leaves open. Browser proctoring enforces at the application layer on the device. Session isolation enforces at the network layer, away from the device, on infrastructure the candidate does not control.

Session Integrity and Audit

A well-designed session isolation layer produces tamper-evident session records. Because enforcement happens at the gateway, every connection attempt, permitted or blocked, is logged at the infrastructure level rather than on the candidate's machine.

This matters for audit purposes. A session audit log generated on the candidate's device can, in principle, be manipulated by the candidate. A session audit log generated at the enforcement gateway is outside the candidate's reach. The two logs are fundamentally different in their trustworthiness.

Blocked connection attempts are particularly informative. A session with repeated blocked attempts to AI API domains tells a different story than a session with none. This signal is only available if the enforcement layer captures it, and only meaningful if the log is generated at the gateway rather than on the device.

What Assessment Platforms Should Ask

When evaluating session isolation architecture, the questions that surface real differences:

Is the enforcement agent persistent or session-scoped? An agent that runs continuously between exams creates a larger attack surface and raises privacy objections that a session-scoped agent does not.

Where is the policy decision made? Device-side policy can be manipulated by the device. Gateway-side policy cannot be manipulated from the device.

Does it require a kernel driver? Kernel driver installation requires elevated privileges, triggers IT security reviews, and creates compatibility risks. Modern network-layer enforcement can operate without a kernel driver. If a vendor requires one, ask why.

Does it remove itself completely? "Uninstallation" and "removal" are not the same thing. Ask specifically whether all services, processes, configuration changes, and cryptographic material are removed at session end, not just the main application.

Is the audit log generated at the enforcement layer or on the device? A device-generated audit log is the candidate's log. A gateway-generated audit log is yours.

The Core Distinction

The design question for exam security infrastructure is not "how sophisticated is the detection?" It is "who controls the enforcement layer?"

Device-side controls place the enforcement layer in the candidate's hands. Session-scoped, gateway-side enforcement places it in the platform's hands. That distinction determines whether a motivated candidate can disable or circumvent the controls before or during the exam.

Ephemeral session isolation removes the attack surface entirely between sessions. Gateway enforcement removes the ability to manipulate it during one.

Aiseptor deploys session-scoped enforcement that operates at the network layer, self-destructs at session end, and logs enforcement decisions at the gateway rather than on the candidate's device. See how the architecture works