Anti-LLM Obfuscation: How a Fingerprinting Script Disrupted AI Code Analysis

Security researcher veritas published an investigation on October 28 into a browser-fingerprinting script containing misleading names and hidden text apparently intended to trigger AI safeguards. The researcher reports that some AI-assisted analysis attempts were refused. The finding concerns interference with code analysis, not evidence that the script creates biological weapons.

What the researcher found

The original investigation began with a crawl of 10,000 websites to examine browser fingerprinting. One script contained alarming function names and encoded text that resembled instructions to an AI system.

Veritas reports that Astra declined to deobfuscate it, including with the Daybreak Blue option, while GLM-5.3 complied with the same prompt. The author interprets the unusual contents as anti-LLM obfuscation and says the script otherwise appears to collect conventional browser and graphics signals.

Those are observations from one researcher's investigation. They do not establish how frequently this technique works, whether every deployed model version behaves the same way, or the intent of every party associated with the script. The report also includes suspicious-looking code whose purpose the author treats cautiously.

Why this differs from ordinary obfuscation

Code obfuscation usually makes a program harder to understand by hiding its structure or meaning. The interesting possibility here is that a file can also interfere with the tool being used to inspect it.

An analyst asking what a program does is not necessarily asking the model to carry out the program's instructions. If those two requests become indistinguishable, a deliberately alarming string can prevent a legitimate review from getting very far.

The content being inspected is not an instruction to the analyst. That boundary matters whether the content appears in a web page, a repository comment or a document attached to a support ticket. Recognizing a dangerous-looking phrase and understanding its role in a program are different tasks.

What this result does not prove

The Hacker News discussion includes debate about model refusals and safeguards. It is useful context for why developers are interested, but comments are not independent reproductions of the reported result.

A model agreeing to analyze a file does not by itself show better security judgment. Refusing everything suspicious can leave legitimate work unfinished; accepting everything can expose an analyst to untrusted instructions. Neither behavior alone tells us whether the final analysis is accurate.

I would evaluate this as an analysis-quality problem. A useful system should distinguish a quoted instruction from a user request, explain uncertainty about what a program actually does, and avoid executing untrusted material merely to understand it. Those are separate outcomes worth measuring.

The implication for AI-assisted review

For a team using AI to review unfamiliar code, a refusal should remain a visible unresolved result, not silently become a clean bill of health. The same applies when a model produces a confident explanation without establishing which code paths can run.

The next useful evidence would be independent testing across realistic review tasks, with both successful analysis and safe handling measured. The goal is a reviewer that keeps examining the evidence without adopting the instructions hidden inside it.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain research and engineering work clearly, without losing the caveats that make the story trustworthy.

Book a 30-minute call.