Browser-only proctoring vs OS-level proctoring - what the AI-cheating arms race actually requires

The short answer

Browser-only proctoring was a defensible category until roughly 2022. It is no longer architecturally sufficient against modern AI tools - ChatGPT, Claude, Copilot, Gemini, Perplexity, and the steadily more capable AI assistants candidates use during assessments. The gap is not a matter of better detection within the browser; it is a gap in where the proctoring layer sits in the operating system. Browser-only proctoring runs at the application layer. The cheating now runs below it.

OS-level proctoring - a dedicated secure browser or assessment environment that operates at the operating-system level - closes the architectural gap. It is the difference between a security camera pointed at the front door (browser-only) and a security system that monitors and controls the entire house (OS-level). The two models look similar in marketing materials; they perform very differently against modern threats.

For organisations using assessments where the result actually matters - hiring, certification, regulated training - OS-level proctoring is now the baseline requirement, not a premium upgrade.

Why the architectural gap matters now

For most of the history of online assessment, the integrity threat was predictable. Candidates might look up an answer in another browser tab. They might consult a notebook. They might communicate with a friend on a phone. Browser-level proctoring - monitoring the browser tab, blocking copy-paste, watching for tab switches, using the webcam to verify identity - was a reasonable defence against these threats. It worked because the threat lived at the application layer, the same layer where the proctoring lived.

The arrival of capable generative AI tools changed the threat model fundamentally. ChatGPT integrates as a browser extension, a desktop app, a system-tray utility, an iOS or Android keyboard, and now an OS-level service that responds to keyboard shortcuts and screen captures. Claude has similar integration patterns. Copilot is built into Windows directly. Gemini is built into Chrome and ChromeOS. The AI assistant is no longer something the candidate has to go to; it is available everywhere on the system, often invisibly.

This matters because the AI tool is no longer in the browser. A candidate can use voice input to ask ChatGPT a question through their phone while the laptop webcam is pointed at their face. They can use a Copilot keyboard shortcut to query their problem at the OS level, where the browser proctoring layer has no visibility. They can use a screen-share tool to relay the assessment to a confederate running the assistant on another device. They can use a virtual machine to run the proctoring in a contained window while everything else on the system runs free.

Browser-only proctoring cannot see most of this. The proctoring layer is watching the front door while the back door, the windows, and the basement are all open. The vendor's marketing may claim "AI tool detection" or "comprehensive integrity", but the architecture sets the ceiling on what's possible. An application-layer system cannot reliably monitor or control what happens below the application layer.

What "browser-only proctoring" actually does

To be precise about the category - what browser-only proctoring genuinely covers, and what it doesn't:

What it does:

1. Webcam monitoring (face presence, multiple-face detection, gaze direction)
2. Microphone monitoring (audio activity, voice presence, background voices)
3. Browser-tab monitoring (tab switching, focus changes, devtools detection)
4. Copy-paste blocking within the browser
5. Right-click and keyboard shortcut blocking within the browser
6. Fullscreen enforcement
7. Network-level checks for some virtual machine and remote-desktop signatures
8. Per-question behavioural signals (time spent, attempt patterns)

What it doesn't do, structurally:

1. Block AI assistants that run outside the browser (system-tray apps, OS services, keyboard utilities)
2. Detect AI usage on a second device (phone, tablet, secondary laptop)
3. Monitor screen-sharing or screen-capture activity at the OS level
4. Prevent virtual machines from running the proctored session
5. Detect or block AI extensions that operate at the operating-system input layer
6. See activity on other monitors, other apps, or other audio devices
7. Control what the candidate's operating system is doing in the background

The honest framing: browser-only proctoring covers the application layer. The integrity threats have moved below it.

What "OS-level proctoring" actually does

OS-level proctoring is a separate category, with substantially different architectural reach. A serious OS-level proctoring system - like the Skolarli Secure Browser - installs as a dedicated application on the candidate's operating system, with privileged access to monitor and control system behaviour during the assessment.

What OS-level adds beyond browser-only:

1. Process-level AI tool detection and blocking. Identifies and prevents AI assistant applications from running during the assessment session - ChatGPT desktop apps, Claude desktop apps, Copilot, Gemini, Perplexity, and a continuously updated list of AI-tool signatures. Detection happens at the process layer, not the browser layer.
2. Network-level enforcement. Blocks connections to known AI service endpoints during the session. A candidate cannot route an AI query through any application on the locked-down system.
3. Virtual machine detection and refusal. Identifies if the proctored session is running inside a virtual machine and prevents the session from starting. This closes the "run the assessment in a VM, run AI tools in the host" loophole that browser-only systems can't see.
4. Remote desktop and screen-sharing detection. Identifies remote-control software and screen-sharing utilities running on the system. Closes the "have someone else solve it on a remote screen" loophole.
5. Multi-monitor detection. Identifies additional connected monitors and either disables them or prevents the session from starting. Closes the "reference the answer on a second screen" loophole.
6. Input-device anomaly detection. Identifies suspicious input patterns suggesting a virtual keyboard, paste injection, or non-human input. Catches patterns that browser-level systems can't see at the input layer.
7. Continuous environmental monitoring. Background processes monitor for changes that suggest tampering - new device connections, network configuration changes, attempted use of input devices that weren't present at session start.
8. Audit trail with OS-level fidelity. Records the full state of the candidate's system at relevant moments - running processes, network connections, device state - for post-session review and dispute resolution.

The architectural difference is consequential. Skolarli's analysis of 50,000+ proctored assessments - published in our research post earlier this year - showed OS-level AI tool blocking through the Skolarli Secure Browser stopped roughly 95% of common AI tool attempts, while browser-extension-based proctoring tools blocked closer to 60-70%. The gap is meaningful in absolute terms, and it's structural rather than a temporary detection lag - browser-only systems can't close the gap without changing architectural model.

Where browser-only proctoring is still defensible

Worth being fair to the category. Browser-only proctoring is genuinely the right choice in several contexts:

Low-stakes assessments. Internal training quizzes, voluntary skill assessments, formative learning checks - where the cost of an integrity violation is low and the friction of OS-level installation isn't justified. Browser-only proctoring handles this competently and proportionately.

Trust-based candidate populations. Some hiring contexts (internal mobility within a known team, senior executive search where candidates are heavily vetted before assessment, situations where the assessment is informational rather than dispositive) don't need OS-level integrity. The threat model is different.

Candidate experience priority over integrity strength. Some organisations deliberately choose lighter proctoring to preserve candidate experience - particularly in tight talent markets where heavy integrity infrastructure may be perceived as adversarial. This is a defensible choice if the integrity risk is being accepted explicitly rather than ignored.

Operational contexts where OS-level installation is impossible. Locked-down corporate machines where the candidate cannot install software, certain BYOD environments, candidates without administrative access on their devices. Browser-only is the option that's actually deployable.

Assessments where the format itself resists AI assistance.Caselets, structured viva, and certain scenario-based assessments are harder to defeat with AI than MCQs or coding problems. When the assessment format is itself AI-resistant, the proctoring layer matters less. (Browser-only proctoring on a caselet assessment is meaningfully more defensible than browser-only proctoring on an MCQ assessment.)

The honest framing: browser-only proctoring isn't dead - it has a real role for low-stakes use cases. It's no longer sufficient for high-stakes assessments where the result determines real consequences.

Where OS-level proctoring is now the requirement

The conditions where OS-level proctoring genuinely matters:

Hiring assessments for competitive roles. When the assessment result determines whether a candidate progresses to interview or gets an offer - and particularly when the candidate pool is sophisticated enough to use AI tools effectively - OS-level integrity is the requirement. The cost of an undetected AI-assisted answer is hiring the wrong person.

Certification and credentialing assessments. When the credential carries professional weight - certifications, licensing exams, accredited training assessments - the credential's value depends entirely on assessment integrity. Browser-only proctoring on a high-value credential is increasingly hard to defend to accreditors, regulators, or downstream employers.

Regulated industry assessments. Pharmaceutical product knowledge testing, financial services compliance assessments, healthcare provider qualifications - contexts where regulatory audit requires defensible integrity infrastructure. Browser-only proctoring is increasingly unlikely to satisfy regulator scrutiny.

High-volume hiring where AI cheating is widespread. Top-of-funnel coding assessments, aptitude tests for technical roles, screening assessments for software engineering positions - exactly the categories where AI tools are most capable and most widely used. Browser-only proctoring in these contexts effectively waves through AI-assisted candidates.

Internal hiring where decisions have direct compensation impact. Promotion assessments, leadership-pipeline evaluations, internal mobility decisions tied to comp bands - where the assessment outcome affects an employee's career and compensation trajectory. Integrity matters for fairness across all candidates, not just for keeping out the unqualified.

The honest competitive landscape

Worth naming the broader market. The proctoring vendor landscape divides into rough categories:

Browser-only proctoring vendors. Examus, ProctorU (in its browser-only configuration), Talview, ProctorTrack, several others. These vendors have real capability at the application layer and serve the low-to-medium stakes market reasonably well. Their architectural ceiling is browser-only.

OS-level secure browser vendors. A smaller category. The Skolarli Secure Browser is one. Respondus LockDown Browser is another in the educational context. A few others operate primarily in specific verticals (financial certifications, government testing). The architectural choice - OS-level installation - is consequential and not all vendors are willing to make it because installation friction is real.

Hybrid proctoring services. Vendors offering both a browser-based product and an optional secure-browser product (or human proctoring layered on top of browser-based). The hybrid often signals that the vendor recognises the architectural gap but hasn't fully committed to OS-level as the default.

Human-proctored services without strong technical layer. Some services rely primarily on live human proctors watching webcam feeds with a thin browser layer. These struggle against modern AI cheating because human attention can't catch silent input from a phone, an OS-level AI assistant, or a remote-desktop session - the human is watching the candidate, not the system.

The buyer's job is to recognise that architectural choice is the leading indicator of where each vendor will sit as the AI cheating arms race continues. Browser-only vendors face a structural problem they can't engineer their way out of without changing model.

The candidate-experience tradeoff worth being honest about

OS-level proctoring is not free of cost to the candidate. The honest tradeoffs:

Installation friction. Candidates have to download and install a secure browser or assessment client. This adds setup time, requires administrative access on the machine, and creates support load when installation fails. Browser-only proctoring has no installation step.

Hardware compatibility. OS-level software has stricter operating-system and version requirements than browser-only systems. Some candidates on older hardware, locked-down corporate machines, or unusual operating-system configurations may not be able to run it.

Perceived intrusion. OS-level installation is a more intrusive act than running a proctored browser tab. Some candidates resist it; some sophisticated candidates research what the software is doing on their system and may have concerns about privacy.

Recovery from technical failure. When an OS-level proctoring session fails mid-assessment, recovery is more complex than restarting a browser tab. Vendor support quality matters more for OS-level systems than for browser-only.

Privacy framing. OS-level monitoring is a substantial privacy act. Serious vendors handle this through clear disclosure, narrow data collection, and immediate purging after the audit window. The transparency story matters - candidates are increasingly aware of what gets monitored and how.

The honest framing: OS-level proctoring is the right architectural choice for high-stakes assessments, but it comes with operational costs that vendors must manage well to maintain candidate trust.

How to actually evaluate proctoring architecture when buying

A framework worth working through:

1. What's the architectural model? The first and most important question. Is this browser-only, OS-level, hybrid, or human-primary? Vendors should be able to articulate the architectural model clearly. Vendors who deflect with feature lists rather than architecture answers are signalling that architecture is not their strong dimension.

2. What specific AI tool categories does it block? Browser extensions are easy; OS-integrated AI services are hard. Ask the vendor to name specifically which AI tools their system blocks - ChatGPT desktop, ChatGPT extension, ChatGPT keyboard, Copilot, Gemini in Chrome, Claude desktop, Perplexity. The specificity of the answer reveals the depth of the integrity infrastructure.

3. What's the published effectiveness data? Vendors who have actually measured their effectiveness publish it (or share it under NDA). Vendors who haven't measured tend to claim "comprehensive" without specifics. The published data is also a maturity signal - the vendors with actual data are usually the ones who've thought hard about the problem.

4. How quickly does the system update against new AI tools? Every quarter brings new AI integration patterns. The detection signatures and process-level blocking lists need continuous updates. Ask about the vendor's update cadence and the threat-intelligence process. Vendors with weekly or biweekly signature updates are taking the arms race seriously; vendors with quarterly or ad-hoc updates are falling behind.

5. What's the false-positive rate, and what's the human review path? OS-level systems are powerful, which means false positives have real consequences for candidates. Verify the system surfaces flagged sessions to human reviewers with explainable evidence - not auto-rejection based on detection signals alone.

6. What's the candidate privacy posture? OS-level monitoring requires substantial trust. Verify the vendor has clear disclosure to candidates about what's monitored, narrow data collection limited to integrity needs, immediate purging after the audit window, and clear retention policies. The privacy story is as important as the integrity story.

7. What's the candidate-experience design? Does the installation flow work cleanly on first attempt? Is there clear guidance for candidates on hardware requirements? What's the support path when something fails mid-session? OS-level proctoring done well preserves candidate trust; done poorly destroys it.

8. What's the audit trail and explainability? When a candidate disputes a flag, the vendor needs to be able to show the evidence - video frames, process snapshots, network activity, behavioural patterns. Verify the audit trail is comprehensive and the dispute-resolution path is defined.

Where Skolarli sits in this conversation

Worth being direct about the deliberate bet: Skolarli built OS-level integrity infrastructure from the start, not as a premium add-on but as the architectural foundation. The Skolarli Secure Browser is the only Indian platform with OS-level AI tool blocking - running at the process and network level, not as a browser extension.

Specifically:

1. Blocks ChatGPT, Claude, Copilot, Gemini, Perplexity, and a continuously updated list of AI tool signatures. The detection layer operates at the OS level, not the browser layer. Roughly 95% of common AI tool attempts are blocked, based on analysis of 2,000+ proctored assessments published in our research post.
2. Combined with SkoAI Proctor - face recognition, voice fingerprinting, behavioural analysis - produces a 0-100 trust score with severity-weighted violation logging. Integrity infrastructure operates across multiple layers (identity, environment, behaviour, OS-level enforcement) rather than at the browser layer alone.
3. Human-in-the-loop on every consequential decision. Skolarli does not auto-reject candidates based on integrity signals. Flagged sessions surface to human reviewers with explainable evidence. (Why this matters from a regulatory and quality perspective.)
4. DPDP Act 2023 compliant, in-VPC processing, no public LLM API calls with customer data. The integrity infrastructure runs inside Skolarli's controlled architecture - the deeper integrity layer doesn't come at the cost of weaker data protection.

The honest framing: Skolarli is positioned for organisations where assessment integrity actually matters - competitive hiring, high-value certifications, regulated industry assessments. For organisations running low-stakes internal training quizzes, the operational cost of OS-level proctoring is overkill, and browser-only proctoring vendors serve that market more cost-effectively.

About this piece

This post is part of the Skolarli Buyer's Compass, an analytical series from Skolarli Akademy Research covering the structural decisions facing hiring and L&D buyers in the AI era.

Skolarli Akademy Research is the editorial arm of Skolarli Edulabs Pvt. Ltd., publishing analysis on learning, hiring, and assessment infrastructure. Findings are reviewed by Skolarli's founders and product leaders before publication.

Reviewed by Jayalekshmy Nair, Co-founder & CTO, Skolarli.