← Back to blog

"AI cheating detection" is an umbrella term that covers very different approaches — from browser tab monitoring to deep device-level inspection. The gap between a shallow implementation and a deep one is the difference between catching naive attempts and catching sophisticated ones.

This post describes what a layered detection architecture actually monitors, and why each layer exists.

Layer 1: Network — Traffic and Domain Filtering

The first place to intercept AI cheating is the network layer, before any application runs.

Domain-level filtering. Every call to a hosted AI API begins with a domain resolution. API endpoints for major AI providers — OpenAI, Anthropic, Google, Cohere, and others — are well-known and resolve to identifiable destinations. A network-layer guard that controls the session's DNS resolver can block these lookups at session start. No resolution means no connection.

This requires the exam session to route through a controlled network path — a per-session VPN tunnel, for example — rather than relying on the candidate's own network infrastructure.

Provider network filtering. Some bypass attempts route directly to AI service infrastructure through other means. The major AI providers operate from identifiable network blocks. Traffic destined for those ranges can be blocked or flagged even without domain-level interception.

Traffic pattern analysis. AI API traffic has a recognizable signature in timing and payload structure — short outbound requests followed by longer streaming responses. A network monitor can identify this behavioral pattern even when the destination is obscured.

VPN and tunnel detection. A candidate who activates a VPN mid-session is attempting to route their traffic outside the controlled path. Common tunneling protocols and commercial VPN infrastructure are detectable at the network layer and can trigger automatic session flags.

Layer 2: Device Activity — Local Runtime Monitoring

Network controls handle API calls to external services. They don't handle local models.

A candidate running a local AI tool generates no external network traffic. The model runs entirely on the candidate's hardware, responding to prompts locally. Network-layer controls see nothing.

OS-level monitoring fills this gap.

Active process detection. Local AI inference tools produce observable activity on the device. An agent running with appropriate OS-level permissions can detect when AI inference tools are active — at session start and periodically throughout the session.

This requires an agent running at OS level with sufficient permissions to observe device state. A browser extension cannot do this.

Local inference service detection. Local AI tools typically expose a service interface for interoperability with other applications. An agent can detect active local inference services through their network presence and behavioral characteristics — regardless of what the parent process is named.

Combined signal. Process activity paired with an active local inference service produces a high-confidence indicator that a local model is running.

Layer 3: Installed Capability Signals

Running a local AI model requires loading model weight files onto the device. These files are substantial — often tens of gigabytes — and must exist on disk before inference can occur.

Static assessment at session join. When a candidate joins an exam session, an OS-level agent can assess whether AI model weight files are present on the device. Finding these files doesn't prove the candidate intends to use them during the exam, but it indicates the capability is present and can inform the risk profile for that session.

Active load detection. During a live session, monitoring can detect when AI model files are being actively mapped into memory for inference. This approach is resilient to surface-level obfuscation: renaming a file doesn't change what it contains or whether it's being actively loaded.

Layer 4: Hardware Resource Signals

Running a large language model requires substantial GPU memory. The specific usage varies with model size, but the pattern is consistent: loading a model causes a significant, sustained increase in GPU memory allocation that normal exam activity does not produce.

During a typical exam session, GPU memory usage is modest — web browser rendering, document display, and video conferencing consume limited GPU resources. A sudden, sustained increase that exceeds normal session baselines is anomalous and can be flagged.

Complementary to other layers. Hardware resource monitoring is most useful as a corroborating signal. An anomalous resource spike alone has alternative explanations. The same spike combined with active inference service detection and model file access produces a high-confidence composite result.

The Composite Signal and Aegis Scoring

In practice, no single layer catches every case. A sophisticated attempt might route API calls through a tunnel to evade network filtering, run a local model with renamed binaries, or operate between monitoring windows.

A layered system catches these by looking for the intersection of signals rather than requiring any single indicator to fire.

Each signal carries a weight. Combinations of signals produce a composite score. The score determines whether a session is flagged for review, blocked immediately, or passed without action.

This is the approach we call Aegis — a signal-first evaluation model that produces a structured result with the specific indicators that contributed to the assessment, not just a binary pass/fail verdict. A proctor reviewing a flagged session sees which signals triggered and why, rather than a black-box outcome.

Why This Requires an OS-Level Agent

All of the monitoring described above — process observation, inference service detection, capability assessment, hardware resource sampling — requires an agent that runs at the OS level with sufficient permissions. A browser extension cannot access the running process state, scan the filesystem, or read hardware resource counters. It runs in a sandboxed context deliberately isolated from these capabilities.

This is the core reason browser-based proctoring can't address AI cheating at the local model layer. The detection surface is below the browser. Reaching it requires an agent that runs below it too.

The tradeoff is installation overhead: candidates need to install an agent before joining an exam. For high-stakes assessments — professional certifications, hiring evaluations, university finals — this is a reasonable requirement. For lower-stakes quizzes, it may not be.

The question for any exam platform is where the assessment sits on that spectrum, and whether the credential it issues warrants the detection depth.

Aiseptor's detection stack operates across network, device, and hardware layers with a per-session VPN, DNS-layer filtering, OS-level monitoring, and AI-powered signal evaluation. Read how the platform integration works →