The Problem: AI Makes Cheating Invisible
Teachers face a new reality: students can now generate high-quality answers using AI tools in seconds. Unlike traditional plagiarism, AI-generated content can't be detected with simple text matching. A student can paste an AI-generated essay that looks original, uses the right terminology, and even follows the required format—making it nearly impossible to distinguish from genuine work.
The danger isn't just that students might cheat. It's that teachers have no reliable way to know when it happens. You grade a paper, award a mark, and release the result—only to wonder later whether the student actually learned anything or just used ChatGPT. This erodes trust in assessment and makes fair grading feel impossible.
Why Simple Solutions Fail
Many schools have tried basic approaches: browser lockdowns, proctoring software, or AI text detectors. Each has serious limitations. Browser lockdowns don't prevent AI use on a separate device. Proctoring cameras raise privacy concerns and can't see screen content. AI text detectors are unreliable—they produce false positives that punish honest students and false negatives that miss actual cheating.
Worse, these solutions often treat detection as proof, punishing students based on algorithmic guesses. That's unacceptable. A detection system should surface suspicious behavior for review, not make automatic accusations that could harm a student's academic record.
We needed a different approach: one that tracks actual behavior, surfaces patterns for teacher review, and keeps the teacher in control of every decision.
Our Solution: A Four-Layer Defense System
We built a multi-layered anti-cheating system that combines behavioral tracking, real-time intervention, AI analysis, and teacher review. The key insight: no single detection method is reliable, but multiple signals together create a trustworthy integrity picture.
- Layer 1: Behavioral tracking on the exam page (tab switches, paste events, typing patterns)
- Layer 2: Real-time risk scoring (0-100) based on detected events
- Layer 3: Immediate intervention (warnings, auto-submit after repeated violations)
- Layer 4: Post-submission AI analysis (style consistency, content patterns)
Layer 1: Behavioral Tracking in Real-Time
The first layer runs entirely in the student's browser during the exam. It monitors specific behaviors that correlate with AI-assisted cheating without invading privacy. We track three key signals: tab switches, paste events, and typing patterns.
Tab switches are detected using the Page Visibility API. When a student leaves the exam tab to look at another resource, we log the event. After the first switch, we show a warning. After two switches, another warning. After three switches, the exam auto-submits. This approach gives students room to make mistakes while catching repeat offenders.
Paste events are intercepted using the browser's paste event listener. We measure the length of pasted content and count total pastes. Small pastes (under 50 characters) might be legitimate—copying a number or a short phrase. Large pastes (over 50 characters) are flagged as potential AI copy-paste.
Typing pattern analysis is the most sophisticated signal. We track keystroke timing to detect unnatural patterns. A human typing naturally has variation in speed, pauses, and rhythm. AI-generated text pasted all at once has zero variation. We identify 'typing bursts'—rapid succession of keystrokes with minimal delay—and flag patterns that suggest copy-paste rather than natural composition.
Layer 2: Risk Scoring That Makes Sense
Every detected event contributes to a risk score from 0 to 100. The scoring is transparent and explained: tab switches add 15 points each, paste events add 10-15 points depending on length, unnatural typing bursts add 10-20 points, and focus loss events add 5 points. This means a student who switches tabs twice (30 points) and pastes a large answer (15 points) would have a risk score of 45—medium risk.
The score updates in real-time every 5 seconds. Teachers can see the final risk score alongside each submission, but more importantly, they can see the breakdown: what events occurred, when they occurred, and how they contributed to the score. This turns a black-box number into an auditable record of behavior.
Risk levels are categorized clearly: 0-25 is low (monitor only), 26-50 is medium (warning to student), 51-75 is high (flag for teacher review), and 76-100 is critical (auto-submit + immediate flag). This gives teachers actionable guidance on which submissions need attention.
Layer 3: Real-Time Intervention That's Fair
We built intervention that's educational, not punitive. When a student triggers a violation, they see a dismissible banner explaining what happened: 'TAB_SWITCH: Student switched tabs (1 total)' or 'PASTE_EVENT: Pasted 150 characters (1 total pastes).' The banner shows the current risk score and auto-hides after 5 seconds.
This serves two purposes: it deters cheating by making students aware they're being monitored, and it gives honest students who accidentally switch tabs a chance to correct their behavior without immediate penalty. Only repeated violations trigger auto-submit.
The auto-submit threshold is configurable. Schools can choose strict mode (3 tab switches = auto-submit), lenient mode (warnings only), or disable monitoring entirely for low-stakes assignments. This flexibility ensures the system serves different educational contexts rather than imposing a one-size-fits-all policy.
Layer 4: AI Content Analysis Without False Accusations
After submission, we run AI-powered content analysis on the answers. This is not a 'gotcha' tool—it's a review aid that helps teachers identify potential issues. We analyze three things: writing style consistency, AI-likelihood scores, and answer length anomalies.
Style consistency checks compare a student's answers across different questions. If one answer uses sophisticated vocabulary and complex sentence structures while another uses simple language, that's a style shift worth investigating. We use embedding similarity to quantify the difference, but we don't flag it as proof of cheating—just a reason to look closer.
AI-likelihood scoring runs each answer through AI detection models using existing API keys (Groq, Gemini, OpenRouter). The score (0-100) indicates how likely the text is AI-generated. Here's the crucial part: we don't use this score to reject answers or reduce marks. We surface it as a data point for teacher review. A score of 80 might merit a closer look, but it's not evidence of guilt.
Answer length analysis flags answers that are unnaturally long or short for the question type. A 50-word response to a 2-mark short answer question is suspicious. A 10-word response to an 8-mark essay question is also suspicious. Again, these are flags, not judgments.
Teacher Control: Always the Final Decision
Every layer of our system is designed to inform teachers, not replace them. The behavioral tracking provides evidence. The risk score provides a summary. The AI analysis provides additional signals. But the teacher decides what to do with that information.
In the teacher dashboard, each submission shows an integrity score, a list of events, and AI analysis results. Teachers can review the evidence, dismiss flags if they believe the behavior was legitimate, and mark submissions as 'verified' for future reference. If a student has a genuine reason for a tab switch (checking a reference allowed by the teacher), the teacher can override the system's flag.
This approach preserves academic integrity while protecting students from false accusations. It treats detection as a tool for inquiry, not a substitute for judgment.
Privacy by Design
We built this system with privacy as a core principle. We don't collect personal data beyond what's necessary for academic integrity. We don't use webcam monitoring, screen recording, or invasive fingerprinting. All behavioral data is stored with the submission and auto-deleted after teacher review.
Students are informed about monitoring before the exam starts. They can see exactly what's being tracked and why. Schools can configure the system's sensitivity level or disable it entirely for assignments where monitoring isn't appropriate.
The data retention policy is clear: behavioral events are kept for 30 days, then auto-purged. High-risk flags are retained until resolved by a teacher. Students can request data deletion at any time. This ensures GDPR compliance and gives students control over their data.
The Result: Integrity Without Overreach
This four-layer system provides strong security while respecting student privacy and preserving teacher authority. It catches AI-assisted cheating by detecting the behaviors that accompany it: tab switches to look up answers, paste events to insert AI-generated text, and unnatural typing patterns. It provides teachers with actionable evidence rather than black-box accusations. It gives students fair warning before penalties and allows teachers to override automated decisions.
Most importantly, it maintains trust in assessment. Teachers can feel confident that grades reflect actual learning, not AI assistance. Students can feel confident that they won't be falsely accused based on unreliable detection methods. The system makes cheating harder while preserving fairness—exactly what modern education needs.
Technical Implementation Notes
The behavioral tracking SDK is implemented in TypeScript in `frontend/lib/antiCheatSDK.ts`. It's lightweight (<5% CPU usage, <1MB memory) and uses standard browser APIs with no external dependencies. Events are submitted asynchronously to the backend via `POST /api/student/integrity` and stored in a JSONB field in the `vedai_classroom_students` table.
The risk scoring algorithm is transparent and documented in `ANTI_CHEAT_SYSTEM.md`. Schools can configure sensitivity levels via the institution dashboard. The auto-submit threshold, paste policy, and monitoring mode are all adjustable per assignment.
For schools interested in implementing this system, we provide a migration script to add the integrity_data column to existing databases. The system is backward-compatible and can be enabled or disabled without affecting existing workflows.
