Every Open-Weight LLM You’re Running Is Impersonatable Right Now

Your AI agent can’t tell if a tool result came from your server or from an attacker. Neither can your model. The researchers audited 256 deployed chat tokenizers and found every single one vulnerable to a class of attack your standard defenses miss more than half the time.

What happened

Three researchers from Korea University audited 256 deployed chat tokenization setups and found a universal problem: open-weight models publish the exact strings their chat templates use to mark turn boundaries, roles, and tool results. Because those strings are public, anyone who can inject text into a prompt can forge a turn boundary that is indistinguishable from one your own serving stack wrote — a clean, direct path for prompt injection. The flag most commonly recommended as a fix still leaves 56.6% of tokenizers forgeable, specifically because it misses tool and reasoning markers — the exact tokens that agentic workflows depend on. Their proposed fix, “nameless tokenization,” strips the surface string from control token entries while leaving the reserved identifier intact, so user-controlled content can never encode a genuine delimiter. Across five tokenizer families, the method reproduces the standard token stream exactly on clean data and lifts accuracy on delimiter-bearing text from 8.5% to 59.9% — a range where conventional sanitizers simply destroy the content rather than pass it safely.

Cold read

The 8.5% → 59.9% accuracy jump sounds dramatic, but that benchmark is a purpose-built “probe of delimiter-bearing text” — a synthetic test designed to showcase precisely this failure mode, not a real-world distribution of user inputs. The paper doesn’t show attack success rates against live production systems or quantify how often real adversaries actually craft these forgeries in deployed products. All 256 tokenizers being “forgeable” is a theoretical audit of surface-string exposure, not a measured exploit campaign — the gap between “theoretically forgeable” and “practically exploited at scale” is doing a lot of work here. Nameless tokenization requires changes at the tokenizer and model-serving layer; any operator running a quantized or fine-tuned open-weight model off a standard HuggingFace checkpoint can’t just flip a switch. The method also doesn’t address prompt hacking vectors that operate above the token level, so it solves one layer of a multi-layer problem.

What it means for you

• Signal maturity: 2/5 — Academic proof-of-concept with no production integration path yet
• Who gets hurt: Operators running open-weight models (Llama, Mistral, Qwen derivatives) in agent pipelines that ingest external tool results, web content, or user-supplied documents
• What breaks if this is true: Your RAG pipeline or tool-calling agent is potentially roleplaying instructions from attacker-controlled content as if they came from your own system prompt, with no reliable detection layer between them
• Why it might not land: Nameless tokenization requires coordinated changes to model training and serving infrastructure — model providers have to ship retrained checkpoints, not just a config flag, for this to actually close the hole
• Watch for: A major open-weight model host (HuggingFace, Ollama, vLLM) merging a nameless-tokenization PR or publishing an advisory citing this paper’s vulnerability count

Forecast as of 2026-09-16

By Q3 2027, at least one major open-weight model serving framework (vLLM, Ollama, or TGI) will ship a formal advisory acknowledging control-token forgery as a documented attack class — but nameless tokenization specifically will not be the default in any top-5 open-weight model family’s official release within that window, because it requires retraining, not patching.

Source: Nameless Tokenization: A Lossless Tokenizer-Level Defense Against Control-Token Forgery in Open-Weight LLMs — Kisu Yang, Yoonna Jang, Heuiseok Lim. https://arxiv.org/abs/2609.16984v1