Back to Projects
Project

Online Assessment LLM SecurityFeatured

Online Assessment LLM Security

HTML, CSS, and JavaScript cannot stop a candidate from using a language model to answer every question on a remote competency test. This study establishes why, and what would actually raise the cost.

Remote, unproctored online assessment has become the standard first filter for hiring and certification. LLMs capable of reading web pages, interpreting screenshots, and operating browsers arrived after that infrastructure was built. The asymmetry is structural: defenders can only patch their HTML; attackers can switch attack modality. This study maps where that mismatch ends.

What was tested

The study confined the defender to page-level changes only: no server-side modifications, no network monitoring, no environmental control. Most assessment platforms cannot touch server infrastructure without a rebuild, so this is the constraint defenders actually face.

Eight defense variants (v0 through v7) cover three classes of technique:

  • Prompt encapsulation - wrapping question text in instructions intended to suppress LLM cooperation
  • Modality denial - removing DOM text, rendering content to canvas, encoding via base64 or Unicode steganography
  • Agent and environment detection - fingerprinting browser automation signals and attempting to block extension-based tools

The assessment itself was a fixed 20-question test: 10 programming questions, 5 management questions, and 5 logic questions. All eight variants used the same question set so scores are directly comparable across runs.

Six attack vectors (A1 through A6) covered the methods a candidate with moderate technical skill can reach without physical access to the server. These six vectors are delivered across five attack modalities:

  • DOM text extraction (innerText scraping)
  • HTML source analysis
  • Vision attacks via screenshot
  • A manual browser extension passing page content to an LLM
  • Autonomous computer-use agents perceiving the rendered screen and operating controls directly

(The six vectors map onto these five modalities; more than one vector can run through the same modality using a different method.)

Five models ran across the attack matrix: gpt-4o-mini, gpt-4o, gpt-5-mini, gemma, and llama3.1:8b. The local models (gemma, llama3.1:8b) ran through Ollama, so no API calls were required for those runs. Total: 157 runs logged.

What held and what did not

Across all 157 runs, no defense held: a determined attacker reached 20/20 on every variant by picking the right model-method pair.

Determined-attacker score across all eight defense variants

Defense class What it blocked What it did not block
DOM text removal (canvas rendering) innerText extraction (3-7/20) HTML source reading, vision attacks, computer-use agents (18-20/20)
Base64 encoding Nothing LLMs read encoded text straight through and answered as if it were plain
Unicode steganography Nothing Same result as base64 - zero effect
Prompt encapsulation Nothing consistently Refusals occurred 6 times across 157 runs; every refusal was bypassed via another attack route
Agent/environment detection Some naive automation detection Autonomous computer-use agents, which perceive the rendered screen like a human does

Canvas rendering produced the only measurable reduction: removing text from the DOM did drop scores to 3-7/20 for naive innerText scraping. The reduction disappears when the attacker reads the HTML source (which still contains the question data) or takes a screenshot (vision models answered those at 18-20/20).

Attack accuracy across the defense variants

Encoding-based defenses failed because they misunderstand how LLMs process input. Base64 and Unicode steganography produce payloads that LLMs recognize and decode without prompting. Wrapping a question in base64 does not obscure it; it adds one decoding step that the model handles automatically.

Autonomous computer-use agents defeated every defense end-to-end. By perceiving the rendered screen and operating browser controls directly, they bypass canvas rendering, encoding, and extension detection entirely. Local models (llama3.1:8b, gemma) scored 18-20/20 this way, without API calls.

Refusals - cases where the model declined to answer - occurred 6 times across 157 runs; some models refused at 0% of attempts. Every refusal was bypassed by switching to a different model or a different attack modality, so refusal rate offers no reliable protection.

The defense ladder

The data point to four layers of control, in ascending cost for both defender and attacker:

Page layer (L0): HTML/CSS/JavaScript changes. Eight variants cover the main page-level techniques across three defense classes: prompt encapsulation, modality denial, and agent detection. None held. The core problem is structural: the defender controls the page; the attacker controls the modality. With six vectors available, blocking one or two leaves the rest open. Canvas rendering was the only change that produced measurable score reduction (down to 3-7/20 for DOM scraping), and that reduction disappeared the moment the attacker switched to HTML source reading or a screenshot.

Browser isolation (L1): A locked browser that prohibits extensions, blocks clipboard access to other processes, and prevents screen capture by other applications. This removes the autonomous agent and extension attack vectors, the first real increase in attacker cost. It does not stop a candidate photographing their screen with a phone.

The layers above L1 address physical attack surface, each with a different trade-off:

Layer What it controls Gap it leaves
L2 - OS lockdown Restricts processes running alongside the browser (managed device or locked VM) Physical phone-camera photograph
L3+ - Live proctoring Human or AI proctor via webcam during the session Privacy concerns; significant cost; scalability

For high-stakes credentials - professional certifications, security clearances, regulated industry qualifications - no client-side option closes the gap between what a candidate demonstrates and what they actually know. The assessment should be in-person, or the operator should treat remote delivery as a lower-assurance proxy and set passing thresholds accordingly.

Lower-stakes uses - screening rounds, formative assessment, practice tests - are a different calculation. Browser isolation at L1 will not stop cheating, but it raises the bar above opportunistic attempts and leaves only a prepared attacker a way through.

Reproducibility

The repo ships everything needed to audit the results without rerunning any model or paying for API calls: all 157 run logs, the generated defense variants, the attack scripts, and the aggregated result matrices and figures. Data and figures are licensed under CC-BY-4.0; code under MIT.

The study used Python with Playwright for browser automation, Ollama for local inference, and the OpenAI API for the GPT family models. The test variants are plain HTML/CSS/JavaScript files.

The repo accompanies a paper of the same title.


Source code, run logs, and result matrices: github.com/AlexWaha/online-assessment-llm-security

SecurityLLMResearchPythonEdTechRed Teaming