How CoderPad Enterprise's Anti-Cheat Detects AI Tools

CoderPad Enterprise is the round most candidates worry about. It is also, in our reading, the single best-engineered anti-cheat surface in the live-coding-interview category. This post is a forensic walkthrough of how that detection stack actually works — pieced together from CoderPad's own public docs, anything an engineer can see in the browser DevTools, and public forum reports of which tools fail where. No proprietary internals. No speculation we can't ground.

The reason this post exists: "Hasn't been caught on CoderPad Enterprise" is a load-bearing claim on our site. Readers deserve to see the receipts.

Key takeaways

• CoderPad Enterprise runs at least five distinct detection vectors: an in-page content script tracking key/focus/visibility events, window-focus deltas, hotkey collision checks, screen-share fingerprinting (including hooks into the Desktop Duplication API on the proctor side), and process/window enumeration via standard Win32 APIs and WMI's Win32_Process query surface.
• Every screenshot-based AI tool fails on the same chain of vectors: the hotkey leaks into the page, the overlay drops the IDE focus, the proctor sees the overlay paint into the captured frame, and a WMI process probe from a signed proctor companion sees the helper executable.
• A user-mode visibility flag like WDA_EXCLUDEFROMCAPTURE does not save you here. Enterprise proctors can verify the flag's status with their own probe, and the flag does nothing about hotkey leakage or focus drops in the first place.
• Structurally evading these vectors requires moving below the browser and below user-mode — a kernel-mode hotkey hook, a kernel-mode display-pipeline strip below the desktop window manager, and kernel-level filtering of the enumeration tables that user-mode queries (including WMI) ultimately read from.
• You can verify any of this against any AI tool — including ours — at /proctor, which runs the same vector probes the proctor's content script does.

Why CoderPad Enterprise specifically

There are three CoderPad surfaces a candidate might encounter. Sandbox is unproctored. Consumer Interview is the live recruiter session covered in our does CoderPad detect AI usage post. Enterprise is its own product. It ships with a server-side proctor companion, content-script tracking that the consumer product doesn't run by default, deeper integrations with the calling stack (Amazon Chime, Zoom, Teams), and a recruiter dashboard tuned for fairness review on six-figure offers.

Public job postings for the CoderPad team historically list the standard modern web stack — TypeScript, React, Rails, Postgres — for the editor; the proctoring/fairness surface is built on top of that. None of the detection mechanics below are secret. They're inferable from the network tab, the page source, and CoderPad's own public marketing pages on the fairness toolkit (coderpad.io/blog, coderpad.io/resources).

Enterprise is also where every "I got caught" thread in r/cscareerquestions and TeamBlind eventually points. If a screenshot-based tool is going to fail, it fails here first. Which means this is the round candidates pre-flight against.

The CoderPad Enterprise detection stack — in detail

Five vectors. Each one is independently shippable. The proctor doesn't need all five to fire — any one of them is enough to write into the fairness report.

Vector 1: in-page content script

The single most important thing to understand about Enterprise: there is JavaScript running in the candidate's tab that has the same access to the page as any other script. It can read keydown, keyup, paste, focus, blur, visibilitychange, and DOM-mutation events. You can see its event listeners attached in DevTools' Event Listeners panel. None of this is hidden.

What it watches for:

• keydown events with modifier keys. A content script can register a global document.addEventListener('keydown', …, {capture: true}) and see every key combination the candidate presses inside the tab. AI interview tools tend to use chord hotkeys — Alt+Enter, Ctrl+Shift+L, Cmd+K, Alt+1, Alt+2 — because chord hotkeys feel ergonomic and avoid clashing with the IDE's own keymap. Common AI hotkey shapes are well-known. Matching them is one if statement.
• DOM mutations that don't follow the typing pattern. When a candidate types a letter, the editor inserts one character. When a candidate pastes from the clipboard, the editor inserts a multi-line block. The MutationObserver API (MDN) lets the content script see every childList change in the editor in real time, attribute it to a keydown or a paste event, and surface "this insertion has no matching keydown" to the proctor.
• visibilitychange and blur/focus events. When a candidate opens a separate AI tool window — even a Discord bot, even a phone tethered through scrcpy — the tab's document.visibilityState flips to hidden or the window receives a blur. The visibilitychange event (MDN) is plain DOM API; nothing is being hacked together.
• paste events with content fingerprinting. Every paste into a content-editable element fires a paste event whose payload is readable. Content can be hashed against a corpus of common LLM outputs server-side after the round.

Each of these is one line of standard DOM API — nothing secret, nothing exotic.

Vector 2: window focus tracking

The blur/focus events at the window level, plus document.hasFocus(), give the content script a millisecond-resolution timeline of when the IDE tab was the foreground window. This is more than the basic tab-switch counter the consumer CoderPad ships.

Here is the failure mode this vector catches: when an AI overlay paints over the IDE — even briefly, even transparently — Windows can decide to send the IDE a WM_KILLFOCUS. The content script sees the blur. A 200ms blur right before a 50-line correct solution drops in is the most damning timing pattern in the fairness report.

This is the failure mode that makes browser-extension AI tools and BrowserWindow-style Electron overlays unfit for purpose on Enterprise. They don't know they're costing the candidate the IDE focus, and the proctor's content script sees every transition.

Vector 3: hotkey collision checks

This is the most underrated of the five. The content script registers a keydown listener at the capture phase. The candidate hits Alt+Enter to invoke their AI tool. The browser sends the keydown to the page. The page sees Alt+Enter. But no character was inserted into the editor. That asymmetry — chord modifier pressed, no editor mutation, no scroll, no caret move — is a signature.

The content script doesn't have to know which AI tool you're using. It just has to know that an Alt+Enter happened and the editor stayed completely still. That's a flag.

This is the vector the consumer CoderPad mostly doesn't bother with. Enterprise does.

Vector 4: screen-share fingerprinting

Enterprise rounds are usually paired with a video-call screen share — Amazon Chime is most common, Zoom and Teams are routine. The proctor sees the candidate's screen. The proctor is also a human evaluator, but they're backed by the platform's recording and, for some Enterprise customers, server-side computer vision against the recording.

What this vector sees: anything the candidate's screen-capture pipeline forwards to the call. This is where a user-mode WDA_EXCLUDEFROMCAPTURE flag historically saved AI overlays — it tells the desktop window manager to drop the window from the captured frame (Microsoft Learn). And for years it was enough.

It is not enough on Enterprise in 2026 for three reasons. First, server-side review can spot UI shapes that look like common AI tools' overlays — a known overlay chrome with a known font, even partially obscured, is recognizable. Second, the flag is a flag. If the proctor's companion tooling can probe for GetWindowDisplayAffinity on suspect processes, the flag itself becomes the fingerprint. Third, the proctor companion can hook or instrument the Desktop Duplication API path (IDXGIOutputDuplication::AcquireNextFrame / DuplicateOutput, Microsoft Learn) — the same path screen-capture tools use — and compare what the GPU produced for the desktop against what the candidate's screen-share is broadcasting. A window that exists in the GPU surface but is missing from the captured frame is itself a signal.

For the technical depth on each layer, including the WS_EX_NOREDIRECTIONBITMAP and DWM cloaking surface a real overlay needs to navigate, see our tour of the four stealth layers.

Vector 5: process and window enumeration

This is the most invasive vector and the one Enterprise customers invoke selectively — typically tied to a separate proctor companion app or browser extension that the candidate consents to running for the round. When it runs, it walks the OS window list and process list and matches against a denylist of known AI-tool process names. InterviewCoder.exe. UltraCode.exe. Cluely.app. The denylist is updated when new tools surface.

The standard enumeration channels: EnumWindows / EnumProcesses from user32 and psapi for the obvious case (Microsoft Learn); CreateToolhelp32Snapshot for richer process metadata; and on Enterprise deployments where richer queries are useful, WMI via Win32_Process and Win32_Service for parent-PID, command-line, and signing chain. WMI is the channel that lets a proctor companion ask "show me every process whose loaded modules include a recently-installed unsigned driver" in one query. The candidate's machine answers truthfully because the query is just reading the OS's own bookkeeping.

There is also a subtler integrity layer: the companion app itself is Authenticode-signed and validated at launch (WinVerifyTrust, Microsoft Learn) and its in-page content script is delivered over HTTPS from a CoderPad-controlled origin. The candidate cannot trivially monkey-patch it. The companion can also self-attest — hash its own modules, hash the content script that paired with it, and refuse to run the round if either is tampered with. This is standard anti-cheat hygiene; it's why the round can't be defeated by simply hex-editing the companion binary.

Even without a companion app, browser extensions sanctioned by some Enterprise deployments can call chrome.runtime.id-style enumeration on installed extensions. Browser-extension AI tools light up immediately on that probe.

The publicly-shipping evolution of this same vector is Fair Screen — a free, HN-launched OS-level scanner that runs the same window/process enumeration outside any vendor's companion app. Per its creator's comment, Fair Screen reads OS-level window metadata to flag "windows that are non-shareable, click-through, or overlaying the main screen." Anything CoderPad's companion can do here, Fair Screen now does standalone, and any proctor who wants Vector-5 signal without writing their own companion can lift it. The architectural defense is the same: filter the enumeration result before it crosses back to user mode (see our four stealth layers tour, Layer 3).

For a more general read on this enumeration vector, see our overview of the five proctoring detection vectors in 2026.

How each AI tool fails on each vector

We grade tools below using public forum reports as the primary source. Where we say a tool was "reportedly flagged on Enterprise," we mean exactly that — public TeamBlind and r/cscareerquestions threads describe the failure mode. We are not making up specific incidents.

InterviewCoder ships a single user-mode visibility flag and a global hotkey. Failure modes on Enterprise: hotkey leaks into the content script (Vector 3), the helper window can drop IDE focus when invoked (Vector 2), the process name is on the standard denylist (Vector 5), and an Enterprise proctor with a custom probe can see the visibility flag itself as a fingerprint (Vector 4). Public forum reports of flagging on CoderPad Enterprise are consistent with this profile.

UltraCode uses the same single-flag approach with similar hotkey ergonomics. On Mac, full screen-share captures sometimes catch the overlay where the flag misbehaves. On Windows the failure modes mirror InterviewCoder: hotkey leak, focus drop, process visible. Public reports of flagging on Enterprise are similarly consistent.

LockedIn AI ships minimal stealth — primarily the OS visibility flag — with a browser-extension companion in some configurations. Failure modes: every vector above plus the browser-extension enumeration sub-case under Vector 5.

AIApply sits in the same minimal-stealth class. Same failure modes amplified by the lack of any meaningful display-pipeline work.

For the per-tool breakdown with the live spec table, see InterviewCoder vs FaangCoder and LockedIn AI vs FaangCoder. The pattern is structural, not a matter of which tool tries harder.

How FaangCoder structurally evades each vector

We don't claim to be smarter than CoderPad's anti-cheat team — they ship excellent engineering. We claim to have moved one layer below where their detection lives.

Vector 1 — content script. The hotkey is intercepted by a kernel-mode keyboard hook before the keystroke reaches the user-mode browser. The browser's keydown listener never fires for our chord. There is no event for the content script to read. This is the load-bearing primitive. If you understand only one thing about ring-0 stealth, understand this one. Detail in our companion post on ring-0 memory read versus screenshot OCR.

Vector 2 — window focus. Our overlay is stripped from the display pipeline before any capture path can reach it, and from the windowing surface before it can request focus. The IDE never receives WM_KILLFOCUS. There is no focus delta in the proctor's timeline. Detail in our tour of the four stealth layers.

Vector 3 — hotkey collision. Same primitive as Vector 1. Because the keydown is consumed in the kernel, the page never sees the chord. There is nothing to collide with the editor's typing pattern.

Vector 4 — screen-share fingerprinting. Our display-pipeline strip happens before the desktop window manager assembles the frame that goes to the screen-capture API. The overlay is not in the captured pixels at any layer of the stack — including the Desktop Duplication API path the proctor companion can hook. There is no UI shape for server-side review to fingerprint. The WDA_EXCLUDEFROMCAPTURE flag is a single user-mode bit; we layer past it.

Vector 5 — process enumeration. Our process is hidden from the user-mode window-enumeration and process-listing APIs at the kernel level. EnumWindows, EnumProcesses, CreateToolhelp32Snapshot, and WMI's Win32_Process all read from kernel structures we have already filtered. A denylist of AI-tool process names cannot match a process that does not appear in the list. A signed proctor companion querying through any of those channels gets a clean machine back.

Five vectors. Five independent answers, all rooted in the same architectural decision: live below the browser, below the desktop window manager, below user-mode enumeration. None of these are tweaks. They're the consequence of where the code runs.

Why this is structurally a year-of-engineering moat

The temptation, looking at the list above, is to read it as a feature checklist. It isn't. Each item on our side is a consequence of having shipped a Windows kernel driver and the surrounding signing, install, telemetry, and update infrastructure to make a kernel driver safe to ship to consumer machines.

A competitor reading this post and deciding to match cannot ship a kernel driver next quarter. The work is multi-year, hardware-specific, and irreducibly Windows. It involves Microsoft's WHQL signing pipeline, dealing with the kernel's anti-tampering surface, surviving every Patch Tuesday without bricking customer laptops, and surviving the Windows kernel team's periodic crackdowns on driver behavior. The reason no competitor has matched isn't priority — it's depth.

CoderPad's anti-cheat team are not amateurs either. Their content script is well-built. Their fairness report is genuinely useful to recruiters. Their consumer product detects every shallow tool, deservedly. Our claim isn't that they're bad at their job. Our claim is that we moved the game to a board they don't have a piece on.

FAQ

Does CoderPad Enterprise read my AI tool's process directly? Only if there is a separately consented proctor companion app or sanctioned browser extension running. The default browser content script cannot enumerate OS processes. It can, however, see every keystroke and focus event in the candidate tab.

Is WDA_EXCLUDEFROMCAPTURE enough on Enterprise? No. The flag protects the captured frame from showing your overlay. It does nothing about hotkey leakage into the content script (Vector 1, Vector 3), nothing about IDE focus drops (Vector 2), and on Enterprise the flag itself can be probed as a fingerprint (Vector 4). It's a 2018-era primitive.

What if I just disable my AI tool's hotkey and use the mouse? Vectors 2 and 4 still fire — the overlay still drops focus when it appears, and the screen capture still sees it unless you have display-pipeline work below the desktop window manager. Removing the hotkey eliminates one vector, not five.

How can I verify any of this for myself? The five-vector probe is what /proctor is. Visit it with any AI tool active, run the probes, and watch which vectors fire. It's the same logic the proctor's content script runs, exposed in the open. Run it against us, run it against competitors, run it against your own homemade Discord bot. Decide for yourself.

Doesn't the signed proctor companion's integrity check defeat any tool below it? The companion validates itself — its modules, its paired content script, its origin. It does not (and cannot, from user-mode) attest to the rest of the kernel. A driver that loaded before the companion launched and that hides its own presence from the OS's enumeration tables is invisible to the integrity check, because the integrity check is reading the same tables. This is the same architectural reality every commercial anti-cheat (Vanguard, EAC, BattlEye) navigates from the attacker side; we navigate it from the candidate side.

Is CoderPad Enterprise immoral for shipping this? No, and we don't take that posture. They're solving the hiring company's fairness problem honestly. We're solving the candidate's problem on the other side of the same problem. Both pieces of engineering are well-built. The candidate decides which side of that table they sit on; we just build the tool.

Try it yourself

The point of the /proctor test page is that you don't have to take any of this on faith. It runs the visibility-flag, hotkey-leak, focus-delta, screen-geometry, process-enumeration, and content-script probes against whatever AI tool you have active. Five minutes. No login.

If you want the engineering deep-dives behind the architecture decisions referenced above:

• Ring 0 memory read vs screenshot OCR — why screenshot-based AI tools have structural latency, and what reading from process memory at the kernel actually looks like.
• The four stealth layers, in detail — kernel-mode display-pipeline strip, process concealment, window-enumeration hiding, detection-query spoofing.
• The 2026 stealth audit — 14 AI interview tools graded GREEN/YELLOW/RED across 5 detection vectors.
• The Windows-native stealth setup — hardware, screen-share hygiene, dual-monitor configuration.

If you have an Enterprise round on the calendar and you want the round to be a clean fairness report, FaangCoder is $399 lifetime (or $199/mo). The /proctor page is open to anyone before you commit. Use it.