Tokenization attacks expose a new bypass layer in LLM security

At a glance

What this is: This research explains how adversaries abuse tokenization quirks in LLMs to bypass guardrails, hide malicious prompts, and manipulate downstream model behaviour.

Why it matters: It matters because AI security programmes that only inspect model outputs, rather than raw text and tokenized inputs, will miss a growing class of evasive attacks across agentic AI and enterprise LLM deployments.

👉 Read HiddenLayer's research on tokenization attacks against LLMs

Context

Tokenization is the process that turns human language into machine-readable units, and in LLM systems it is one of the earliest points where an attacker can influence how content is interpreted. When tokenization is weakly defended, prompt injection becomes easier to disguise, classifier verdicts become easier to skew, and security tooling can be bypassed before the model sees the payload.

For IAM and security teams, the identity lesson is straightforward: the attack surface is not limited to the model or the application wrapper. AI pipelines need controls that inspect raw input, normalise Unicode, and validate the integrity of the text before it reaches any policy, classifier, or tool-call workflow.

Key questions

Q: How should security teams defend LLMs against tokenization attacks?

A: Defence should start before the model sees the prompt. Security teams should normalise Unicode, block invisible or uncommon character ranges where appropriate, and test the full pipeline at both raw-text and tokenized levels. The goal is to keep the classifier, the sanitizer, and the model making decisions on the same underlying input.

Q: Why do tokenization attacks bypass prompt-injection classifiers?

A: They work because the classifier and the target model may not interpret the same text in the same way. If an attacker changes token boundaries with added characters or hidden Unicode, the classifier can misread the prompt while the model still understands the intended malicious instruction.

Q: What breaks when hidden Unicode is allowed into AI workflows?

A: Hidden Unicode breaks the assumption that human review and machine review are seeing the same payload. A prompt can appear clean in a UI while carrying instructions the model will execute. That creates a blind spot in moderation, code review, and any downstream tool-calling workflow.

Q: How can organisations tell if their LLM guardrails are actually working?

A: They should test whether benign-looking variants of the same malicious prompt receive consistent verdicts across sanitizers, classifiers, and the model itself. If a small token change flips the decision, the control is brittle and vulnerable to evasion rather than genuinely effective.

Technical breakdown

Why tokenization becomes a security boundary in LLMs

Tokenizers split text into tokens that the model converts into embeddings, so they shape both meaning and control flow. If an attacker can alter token boundaries or introduce unusual character sequences, they can change how a prompt is scored by a classifier without changing the human-visible message. That creates a gap between semantic intent and machine interpretation. In practice, this is why input handling belongs in the security model, not just the model stack.

Practical implication: inspect and normalise input before classification so the security decision is based on stable text, not attacker-controlled token boundaries.

Glitch tokens and invisible Unicode attacks

Glitch tokens exploit vocabulary and training mismatches, while invisible Unicode attacks hide malicious instructions in characters most users cannot see. Both techniques rely on the fact that many systems trust rendered text more than underlying byte sequences. A prompt can look harmless to a reviewer and still carry instructions that are fully legible to the model. That makes preprocessing and visual inspection insufficient on their own.

Practical implication: block or sanitise uncommon Unicode ranges, and test whether your pipeline treats rendered text and raw input consistently.

TokenBreak and classifier evasion

TokenBreak attacks deliberately perturb words so a prompt-injection classifier sees different subword patterns from the model that ultimately receives the payload. The classifier may downgrade the risk because the token sequence no longer resembles a known malicious phrase, even though the semantic attack still survives. This is a classic control split: one system flags the pattern, another system executes the meaning, and the attacker uses the gap between them.

Practical implication: evaluate prompt-injection defenses at both classifier and model layers, then verify that evasive token variants still trigger the same verdict.

NHI Mgmt Group analysis

Tokenization is now a governance boundary, not just a model implementation detail. The article shows that adversaries can attack the layer that converts text into tokens before any policy decision is made. That means security teams cannot treat prompt content as trustworthy simply because it looks normal to a human reviewer. The practical conclusion is that LLM governance must extend to preprocessing, not only inference-time controls.

Invisible prompt content creates an identity verification problem for AI systems. Human reviewers and automated classifiers may be looking at different representations of the same input, which breaks the assumption that all decision-makers see the same prompt. When that assumption fails, security controls can approve text that the model interprets as a malicious instruction set. Practitioners should recognise this as a control integrity issue, not a model-quality issue.

TokenBreak exposes a classifier-model split that attackers can systematically exploit. If the detector and the target model tokenise inputs differently, the defender and the attacker are no longer evaluating the same object. That weakens every downstream safeguard that depends on consistent text interpretation, including prompt filters, moderation layers, and tool-call validation. The implication is that token-level variance must be tested as part of AI security assurance.

AI security controls now need text normalisation and token-aware validation as baseline requirements. The article makes clear that hidden characters, malformed sequences, and token perturbations can alter verdicts before the model acts. That shifts the programme away from simple content filtering toward consistency checks across the full pipeline. Practitioners should treat tokenization abuse as an operational control gap, not an edge case.

OWASP-style adversarial testing belongs in LLM intake pipelines, not only red-team exercises. The attack patterns described here are repeatable, inexpensive, and easy to automate. That means organisations need routine validation of tokenizer behaviour, Unicode handling, and classifier robustness as part of production assurance. The lesson for practitioners is to test the boundary where text becomes tokens, because that is where the bypass begins.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• From our research: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• Forward-looking reading: Pair this with OWASP NHI Top 10 to map token-level evasion into broader AI and non-human identity threat models.

What this signals

Tokenization abuse will push AI security teams toward pipeline integrity controls rather than model-only safeguards. The practical shift is from asking whether the model can spot malicious intent to asking whether the entire ingestion path preserves input fidelity. That is where invisible characters, token splits, and classifier drift create the real operational risk.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the adjacent lesson is clear: attackers exploit every weak boundary in the software and AI supply chain, not just the obvious one. Token handling, secret exposure, and prompt filtering now belong in the same control conversation because the bypass often starts before execution.

Prompt injection testing should become part of continuous AI assurance, not a one-time red-team exercise. HiddenLayer's research points to a broader operational truth: if Unicode normalisation, token-aware validation, and classifier robustness are not re-tested as models and tools change, the control set will age faster than the threats it is meant to block.

For practitioners

• Normalize all inbound text before evaluation Strip or canonicalise invisible Unicode, variation selectors, and other non-printing character classes before prompts reach classifiers, routing logic, or model calls.
• Test classifier and model tokenization together Run the same malicious and near-miss prompts through both the guardrail layer and the target model, then compare verdicts for divergence caused by token boundary changes.
• Add token-aware prompt-injection cases to QA Build a regression set that includes glitch tokens, Unicode payloads, and word-splitting variants so security testing covers evasion, not only obvious malicious strings.
• Validate tool-call formatting after sanitization Check that sanitization does not create malformed tool-call strings or bypass conditions that let an attacker alter arguments after the classifier has already approved the input.

Key takeaways

• Tokenization attacks show that LLM security fails earliest at the input boundary, where invisible characters and token splits can distort both human review and automated verdicts.
• The evidence points to a control gap between classifiers and target models, which attackers can exploit by changing token structure without changing malicious intent.
• Practitioners should treat Unicode normalisation, token-aware testing, and input integrity checks as core AI security controls, not optional hardening steps.

Key terms

• Tokenizer: A tokenizer is the component that breaks human-readable text into machine-readable tokens for an LLM. It determines how text is represented before the model assigns meaning, so its behaviour directly affects prompt interpretation, classifier verdicts, and the success or failure of input-based attacks.
• Glitch Token: A glitch token is an unusual token that a model or tokenizer handles poorly because it was not represented well in training. In security terms, it can disrupt attention, distort output, or help an attacker smuggle text past simple filters by exploiting odd token behaviour.
• Invisible Unicode Attack: An invisible Unicode attack hides instructions in characters that are hard or impossible for humans to notice but still readable to machines. In AI pipelines, this creates a mismatch between what reviewers see and what the model processes, which makes prompt injection harder to detect.
• TokenBreak: TokenBreak is a text-perturbation attack that changes how a classifier tokenizes a prompt without removing the underlying malicious intent. The attacker uses small character changes to shift the detector's verdict while preserving semantics for the target model, creating a control split between the two systems.

What's in the full report

HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:

• Tokenizer examples showing how specific prompt variants change model and classifier behaviour in practice
• Step-by-step illustrations of invisible Unicode payload construction and why they evade human review
• TokenBreak examples that demonstrate how small text perturbations alter prompt-injection verdicts
• Discussion of how HiddenLayer positions AI-native defences against tokenizer abuse in production workflows

👉 HiddenLayer's full post shows the tokenizer examples, classifier bypass patterns, and mitigation guidance in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.