Lock-down browser vs OS-level lock-screen: why it matters for AI cheating.

Two different security perimeters

The terms "lock-down browser" and "lock-screen" sound similar. They describe fundamentally different security perimeters.

A lock-down browser is, technically, a browser process that has been configured to restrict the user's actions within that process. It can prevent the user from opening new tabs, copying text, taking screenshots through the browser's own APIs, and (sometimes) switching to other applications via OS-level focus events. The browser is, however, just a process — one of many running on the operating system. Anything the OS allows other processes to do, those processes can still do, regardless of what the browser is doing.

An OS-level lock-screen is a native application — typically a privileged daemon plus a foreground UI — that runs as a system-managed shell. It can block process spawning, intercept input events at the OS layer, prevent screen recording at the compositor level, disable USB peripherals, and reject accessibility-API access by other applications. The exam surface it controls is the entire device, not just one window.

This is the difference between locking a single room and locking the building. Both are useful in different contexts. They are not interchangeable.

The autonomous-AI-agent threat

The threat that exposes the gap most clearly, in 2026, is the autonomous AI agent.

A modern AI agent — there are several commercial and open-source examples — runs as a desktop application, watches the screen via accessibility APIs (which exist on macOS, Windows, and Android for legitimate disability-support reasons), reasons about what it sees with a frontier language model, and produces output via simulated input (keyboard and mouse events injected into the OS event queue). It does not need to be a browser plugin. It does not need to be installed inside the exam browser. It runs alongside the exam, watching the same screen the student sees, typing the same answers the student would type — except faster and, for many subjects, more accurately.

From the lock-down browser's perspective, this is invisible. The browser is not aware of other processes reading its screen output. It is not aware of synthetic keystrokes being injected into the OS event queue, because by the time those keystrokes arrive at the browser, they look like normal user input. The standard lock-down-browser controls — block tab switching, block copy-paste, block printing — don't see the agent at all.

From the OS-level lock-screen's perspective, this is a normal threat. The lock-screen, as a privileged process, can deny accessibility-API access from non-system processes, can deny synthetic input injection, can prevent the agent process from being spawned in the first place. These are existing OS primitives. The lock-screen just uses them.

The lock-down browser doesn't see the AI agent because the agent isn't in the browser. It's running in the same OS. The browser was never the right perimeter.

What lock-down browsers actually defend against

It would be unfair to say lock-down browsers do nothing. They defend against a specific set of threats — the threats that mattered most when they were designed, roughly 2010–2020.

They prevent the student from opening another tab to Google an answer. They prevent copy-paste from the exam to ChatGPT (though this defence relies on the student using copy-paste; manual transcription works fine). They prevent the student from taking screenshots through standard browser keyboard shortcuts. They flag if the browser loses focus, which catches naive alt-tab to other applications.

For a low-stakes formative assessment in 2018 — a weekly quiz, a self-paced learning check, a non-credit-bearing module — these defences were adequate. The marginal student wasn't going to install a desktop AI agent to cheat on a quiz.

For a high-stakes credential-bearing exam in 2026, the marginal student now is the student running a desktop AI agent. The cost of using one has dropped to nearly zero (free tools exist; commercial tools cost $10–20). The benefit is high (passing a subject, retaining funding, advancing in degree). The lock-down browser perimeter is no longer the right one.

What OS-level lock-screens require

Implementing an OS-level lock-screen is meaningfully harder than building a lock-down browser, which is part of why the legacy proctoring vendors haven't done it. The technical requirements vary by OS:

macOS: requires Notarization, system-extension entitlements, and accessibility / screen-recording permissions handled with explicit user grants. Apple Silicon adds Secure Enclave integration possibilities. Per-process accessibility-API gating is available but requires careful configuration.

Windows: requires elevated installer with Windows-signed binaries, optional kiosk-mode integration, hooks into Win32 input pipeline, and (in some configurations) Windows Hello for biometric integration. Group Policy integration helps in managed-fleet contexts.

Android: requires native app with Device Owner or Profile Owner role (provisioned via QR code or zero-touch enrolment), kiosk-mode lock task API, and accessibility-service registration. Samsung Knox and similar OEM frameworks add additional control on supported devices.

iPadOS: requires Single App Mode or Autonomous Single App Mode (the latter requires institutional MDM), with assessment-specific entitlements that Apple has been progressively expanding.

Each of these requires native development, signed deployment, OS-version-specific testing, and an installer / provisioning experience that's substantially more involved than "install browser, click here." The reward is that the lock actually locks. The cost is real engineering investment.

The accessibility-API problem

One specific technical detail worth surfacing: accessibility APIs are the surface most commonly exploited by AI agents.

Accessibility APIs (UIAutomation on Windows, AX API on macOS, AccessibilityService on Android) exist for legitimate reasons — they allow assistive technology to read screen contents and inject input on behalf of users with visual or motor disabilities. They are also the easiest path for an automated agent to read screen contents and inject input on behalf of a cheating student.

An OS-level lock-screen has the option to selectively allow only system-approved accessibility services during the exam — disabling third-party services that haven't been explicitly authorised. A lock-down browser has no equivalent capability; the accessibility surface sits below the browser, at the OS layer.

This is, technically, the single largest defensive gap that browser-based proctoring has against contemporary AI agents. It is not patchable from within the browser. The OS layer is where the defence has to live.

When each is the right tool

This isn't an argument that lock-down browsers should disappear. It's an argument that they should be sized correctly.

Use a lock-down browser when: the assessment is low-stakes (formative, self-paced, non-credit-bearing); the student is trusted to follow policy and the system is providing a deterrent rather than an enforcement; the institution wants minimal procurement and integration overhead.

Use an OS-level lock-screen when: the assessment is high-stakes (final, qualifying, credential-bearing, or appeal-exposed); the threat model includes AI agents and motivated cheating; the institution needs an evidence chain that survives a tribunal; the credential's defensibility matters.

For most institutions, both are useful in different contexts. The mistake is using the lock-down browser for the second category, on the assumption that "browser-based proctoring" is a complete solution. In 2026 it isn't.

What to ask when evaluating lock-screen claims

Vendors describe their lock capabilities in marketing language that often blurs the browser/OS distinction. Six questions to clarify:

1. Is this a browser, a browser extension, or a native OS application? Native = separately installed binary, not a Chrome extension or web app.
2. Does it block third-party accessibility services during the exam? If the answer is "we don't do anything with accessibility APIs," it doesn't block AI agents.
3. Does it block screen-recording by other processes at the OS compositor level? Browser-level screenshot blocking is not the same as OS-level capture prevention.
4. Does it require elevated installation? A user-level browser process can be defeated by a higher-privilege agent. Privilege parity matters.
5. What OSes are natively supported, with feature parity? "Windows-only with browser fallback on Mac" is a downgrade for half your users.
6. Has the lock been independently audited or pen-tested? If so, ask for the report. Reluctance is a flag.

Conclusion

The transition from lock-down browser to OS-level lock-screen mirrors the transition from edge-perimeter security to defence-in-depth in enterprise IT, twenty years ago. The threat moved from outside the perimeter to inside it. The perimeter had to move accordingly.

For online exams, the threat moved from "student opens another browser tab" to "AI agent runs on the same device." The perimeter has to move accordingly. Browser-only locks were the right answer to the previous threat. They are not the right answer to this one.

Institutions evaluating high-stakes proctoring in 2026 should be asking, specifically, where the lock lives. If the answer is "in a browser," the lock isn't where the threat is. The right perimeter is the OS itself, and the systems that lock at that layer are the only ones that close the exam surface against contemporary AI cheating.