How it works
Network-layer enforcement, without a kernel driver on the candidate's machine.
Almost every threat path is closed by blocking the network connection it depends on. A small number of device-only signals (already-resident local models, VM boundary questions) are handled by flagging for review instead. See the threat table below.
Aiseptor is an ephemeral user-space security enclave. When a candidate joins a session, a short-lived encrypted tunnel is established from their device and a default-deny access policy is enforced at the operating-system level, so the network path to unauthorized AI services, remote-access helpers, and second-device pivots is closed before any tool can use it. When the session ends, the enclave destructs and the device is restored.
The core insight
Detection loses every generation. Prevention doesn't care what the tool is called.
Every detection-based proctoring system is a signature database in a race against a global open-source community. When a new cheating tool appears, vendors add a process name, a window title, a screenshot hash. Within days, that tool is recompiled with a different binary name, a different window class, or a different rendering trick, and the signature is worthless. This is not a bug in any single product. It is the architectural ceiling of detection itself.
The numbers bear this out. On CodeSignal-proctored technical assessments, the category with the most detection investment, candidates attempting fraud rose from 16% to 35% year-over-year, more than doubling despite that investment. Detection is visibly failing on the exact assessments it is paid to defend.
Aiseptor inverts the problem. Instead of trying to identify the tool, we close the network path the tool depends on. An invisible overlay that cannot reach an AI inference endpoint is a useless overlay. A remote-access helper that cannot reach a control server is a useless helper. A local LLM that cannot reach a model-loading service is idle. We don't need to know the tool's name; we only need to know the destination it's trying to reach, and the default answer is no.
Three layers. Aiseptor owns the middle one.
Every assessment security stack has three layers. The top and bottom layers have established vendors. The middle layer (device and network) is where 2026-era cheating actually happens, and is the layer no incumbent was built to defend.
Physical / behavioural
Who owns it today
Proctorio, ProctorU, Honorlock, Talview
What it can stop
Room anomalies, a second person in frame, obvious phone use, gaze drift, physical impersonation
What it cannot stop
Anything off-camera, anything invisible to the lens, anything running on the device itself
Device + network
Who owns it today
Previously unowned. This is where Aiseptor sits.
What it can stop
Invisible AI overlays, on-device LLMs, remote-access helpers, second-device AI pivots, process rename / recompile, access policy bypass attempts
What it cannot stop
Physical impersonation (pair with proctoring), pen-and-paper notes (pair with physical proctoring)
Application / browser
Who owns it today
Respondus LockDown Browser, Safe Exam Browser
What it can stop
Other tabs in the same browser, clipboard paste into the assessment window, basic screen keys
What it cannot stop
Anything running outside the browser; every invisible overlay and helper lives here
The architecture.
Three participants: the candidate device, the Aiseptor Gateway, and the platform backend. The device talks only to the gateway. The gateway decides what reaches the open internet. The platform receives a signed verdict at session end.
Candidate device
The Aiseptor agent creates the ephemeral enclave in user-space. An encrypted tunnel carries all device traffic; a default-deny access list blocks everything not explicitly permitted by the exam policy. No kernel driver. No persistent install. The agent removes itself when the session ends.
Aiseptor Gateway
The gateway is where enforcement happens. Allowed domains go through; everything else is dropped. The IntegrityEngine observes every access attempt, classifies threat signals in real time, and assembles a cryptographically signed audit trail. Aegis composes the final integrity verdict.
Platform backend
When the session ends, your platform receives a signed webhook: Aegis status, fired signals, and a link to the full audit report. Your scoring engine and UI remain untouched. The candidate experience is your branding; Aiseptor handles the device and network beneath it.
Threat coverage
What Aiseptor prevents.
Eight categories covering the attack surface lockdown browsers and camera proctoring cannot reach. Prevention described by outcome, not mechanism; your engineers can request the mechanism detail under NDA on a deep-dive call.
| Threat category | Example tools / tactics | How Aiseptor prevents it |
|---|---|---|
| Invisible AI overlays | Cluely, OpenCluely, Parakeet, custom Electron overlays | The network path to the overlay's AI inference endpoint is blocked by default. An overlay with nothing to query is inert, regardless of how it renders on screen. |
| Remote access tools | AnyDesk, TeamViewer, Chrome Remote Desktop, commodity RATs | Remote control relays are blocked at the enclave boundary. A remote operator cannot reach the candidate device and a local RAT cannot phone home. |
| On-device LLMs | Ollama, LM Studio, local GGUF / safetensors models | Model-hosting and update endpoints are blocked at the network layer, so a local model already on disk cannot fetch new weights or call out. ThreatSense additionally detects active local inference at the device layer and raises an integrity signal: the one category in this table where the fallback for an already-resident model is signal-based, not a network block. |
| Second-screen display | HDMI output, virtual display adapters, iPad/iPhone mirroring, Miracast, AirPlay | Aiseptor blocks virtual and extended display outputs (HDMI, display adapters, and wireless mirroring protocols) so no secondary screen can receive exam content. Out-of-frame physical activity is outside this scope and is left to physical-layer proctoring partners. |
| VM stacking | Hardened anti-detection VMs, nested virtualization, sandboxes | The enclave's network policy applies inside the VM as well, so a stacked VM still cannot reach unauthorized endpoints. DeviceGuard also surfaces VM and virtualization signals (hypervisor artifacts, synthetic display devices) as an integrity signal that forces manual review: a device-level fallback for the rare case a VM boundary itself is in question. |
| Screen-share pivots | Discord screen share, Zoom helper sessions, Teams casting | Conferencing endpoints outside the allowed-domain policy are blocked at the network layer before a screen-share session can connect. Any capture path that still activates through an already-allowed endpoint is flagged as an integrity signal in the session audit. |
| Encrypted resolver bypass | Encrypted resolver bypass tools and custom resolver configurations | The session access policy is enforced at the enclave boundary. Encrypted resolver bypass attempts and SNI evasion cannot bypass the enclave's approved-resource list. |
| Process rename / recompile | Renaming Cluely.exe to Terminal.exe, custom-compiled overlays | Aiseptor does not rely on process names. The outbound destination is what's controlled, so a tool with any binary name still fails to reach its backend. |
Questions engineers ask first
What is network-layer proctoring?
Network-layer proctoring enforces what a candidate device can reach during an assessment at the operating-system network stack, not inside a browser or through a screen recording. Application-layer tools (lockdown browsers) only control a single window; screen-layer tools (camera proctoring) only observe what the lens can see. Network-layer enforcement blocks the actual path between the candidate's device and any unauthorized AI service, remote-access helper, or second device, regardless of what process is making the request or what it is named.
How does Aiseptor work?
When a candidate joins a session, the Aiseptor agent establishes a short-lived encrypted tunnel from their device to the Aiseptor Gateway. A default-deny access list is enforced at the OS level: only resources explicitly permitted by the exam policy can be reached. Every access attempt is logged and scored by the IntegrityEngine. When the session ends, the enclave destructs and the device is restored to its original state, with no persistent install and no kernel driver.
Can proctoring software detect renamed processes?
Detection-based proctoring cannot reliably detect renamed or recompiled processes. Any attacker can rename Cluely.exe to Terminal.exe, or recompile an open-source overlay with a new binary name, and defeat process-name signatures in minutes. Aiseptor does not rely on process names. It blocks the outbound network path to the AI service the tool depends on, so whether the binary is called Cluely, Terminal, or anything else, the request fails.
What is an ephemeral security enclave?
An ephemeral security enclave is a temporary, session-scoped boundary around a candidate's device that exists only for the duration of an assessment. Aiseptor deploys the enclave in roughly 30 seconds at session start and destructs it in about 10 seconds at session end. There is no persistent service, no kernel driver, and no residual configuration on the device afterwards. This is the key architectural difference from lockdown browsers and always-on endpoint agents.
How does Aiseptor prevent AI cheating in coding interviews?
Aiseptor prevents AI cheating in technical and coding interviews by blocking the network path to AI services rather than trying to detect specific tools. Invisible overlays (Cluely, OpenCluely, Parakeet), on-device LLMs (Ollama, LM Studio, local GGUF models), remote-access helpers (AnyDesk, TeamViewer), and second-device AI pivots all depend on a network path that Aiseptor closes by default. Only domains explicitly whitelisted for the interview are reachable: documentation, the coding platform itself.
What we never touch.
Aiseptor is built around network-layer signals, not content surveillance. The enclave only needs to know where the device is trying to go, not what the candidate is typing, saying, or looking at. Candidates and their legal teams can verify this on their own machines.
Never touched
- No webcam. No microphone.
- No keystrokes. No clipboard contents.
- No personal files. No screen recordings.
- No data retained beyond 24 hours (default).
What we do collect
- Network access requests made during the session (to enforce the approved-domain policy).
- Device activity signals observed during the session window.
- HMAC-signed session telemetry events for the audit trail.
- Session metadata: join time, duration, integrity signals fired.
None of these are hypothetical.
Each row below is a bypass technique in active public use today, not a theoretical gap. It is the reason the industry needs a layer beneath the browser window and outside the camera's field of view, which is the layer Aiseptor occupies, as described throughout this page. Physical and behavioural proctoring stay valuable for what they were built to catch; they simply cannot see what happens off-camera or outside a single browser process.
| Incumbent tool | Documented bypass | Source |
|---|---|---|
| Respondus LockDown Browser | Second-device pivot: run the assessment in the locked browser while querying an AI overlay or a phone from a device the browser has no visibility into. | Public write-ups and student forums document this as the most common LockDown Browser bypass. The browser can only govern its own window, never a second device. |
| Safe Exam Browser | Kernel-mode and user-mode bypass toolkits that suspend or hook the browser's own lockdown process from outside its window. | Several of these toolkits are maintained as public open-source repositories, updated within days of each SEB release. |
| Camera-based proctoring (Proctorio, Honorlock, ProctorU) | Invisible on-screen overlays that render inside the assessment window itself, nothing for the webcam lens to see, because the overlay never appears in the camera's field of view. | Covered in our analysis of why browser and camera proctoring miss on-screen overlays. The camera lens and the screen are two different surfaces, and behavioural proctoring only watches one of them. |
Want to inspect the agent on your own machine?
Technical due diligence is welcomed. Platform CTOs and security leads can request sandbox credentials, read the architecture whitepaper, or schedule a 60-minute engineering deep-dive with our founding engineers. Bring Wireshark. Bring Activity Monitor. Bring the hardest attacker you know.