← Back to blog

When a candidate opens ChatGPT, Claude, or any hosted AI assistant during an exam, the first thing that happens is a DNS lookup. Not the TLS handshake. Not the HTTP request. Not the prompt payload. A name resolution request goes out, asking the system resolver to return an IP address for the destination.

This lookup happens before any connection is established, before any data is sent, before the exam violation is complete. It is the earliest observable event in any AI API call.

That makes DNS the most efficient place to enforce exam policy. You can stop the violation at its first network event rather than trying to inspect or intercept it downstream.

Why DNS Is the Right Enforcement Point

In a session-scoped exam security architecture, the candidate's device operates under a controlled DNS policy for the duration of the exam. Queries are resolved through an enforcement layer that applies an approved-domain list. Domains on the list, the exam platform and any resources explicitly permitted for that session, resolve normally. Everything else fails to resolve. The connection never starts.

The efficiency here is significant. When DNS resolution fails, no TCP connection opens. No TLS handshake completes. No data leaves the device. From the AI provider's perspective, the request never existed.

Compare this to a downstream approach that intercepts connections after they establish: the handshake has already completed, metadata has already been exchanged, and you are racing to close a connection that is already open. DNS enforcement wins by not letting the connection open in the first place.

Why This Outperforms Browser-Level Controls

Browser extensions are the common answer to in-exam AI access. Block the domain at the extension level, and the candidate cannot reach it from within the browser.

The problem is scope. Browser extensions only intercept traffic initiated from within the browser context. A desktop overlay application, a native process making a direct connection, or a locally-installed assistant bypasses the browser extension completely. The extension never sees the request.

DNS enforcement operates below any individual application. When any process on the device makes an outbound connection, it needs to resolve a hostname first. That resolution request goes through the system resolver. If the system resolver is operating under the session's approved-domain policy, it applies that policy regardless of which application is making the request.

This matters specifically because the most capable AI cheating tools do not run in a browser. Tools like Cluely and similar invisible overlays render on top of the exam window as separate OS-level processes. They make their own outbound connections. A browser extension is invisible to them. A DNS-layer enforcement model is not.

The Process-Renaming Problem

One evasion pattern candidates attempt is renaming a prohibited tool's binary to something innocuous. The process name in Task Manager or Activity Monitor changes. The binary looks clean at a surface-level scan.

DNS enforcement is unaffected by this. A renamed AI overlay still resolves the same API domains. The DNS query still goes through the session resolver. The resolver still checks those domains against the approved list. The resolution still fails.

This is one of the structural advantages of enforcing at the network layer rather than at the process or application layer: the network behavior of a tool does not change when its filename does.

What Assessment Platforms Should Ask

If you are evaluating exam security infrastructure, the DNS enforcement questions worth asking are:

Does the enforcement apply to every process on the device, or only to traffic within the secure browser? A browser-scoped control and an OS-scoped control look similar in a demo. They produce very different outcomes against modern AI tools that run outside the browser.

Is the enforcement session-scoped? A control that applies continuously, beyond the exam window, creates privacy and liability concerns. Session-scoped enforcement applies only while the exam is active and removes itself when the session ends.

How does the platform handle domains that candidates need access to? Exam platforms sometimes require external resources, reference materials, or proctoring service endpoints. The approved-domain model needs to accommodate legitimate access without weakening the policy.

Is there an audit trail for blocked resolution attempts? A blocked DNS query is a signal. A session with a high volume of blocked queries for AI API domains tells a different story than a session with none. This data belongs in the session audit record.

The Efficiency Argument

The volume argument matters. The majority of AI cheating attempts use hosted AI APIs. Every one of those attempts requires name resolution. DNS enforcement stops all of them at the same point, before a connection opens, with low computational overhead and no risk of false positives on legitimate traffic.

DNS filtering is not glamorous. It is a resolver policy and a domain list applied at the right layer. But it stops the most common attack class at the earliest observable moment, before any connection completes, and does so regardless of which tool the candidate uses or what they rename it.

Early-in-stack enforcement is almost always more efficient than late-in-stack detection. DNS sits at the beginning of the stack.

Aiseptor applies session-scoped DNS enforcement to every outbound connection from the candidate's device, stopping AI API access before any connection completes regardless of which process initiates it. See how the architecture works