Adversarial Tokenization

Renato Lui Geh, Zilei Shao, Guy Van den Broeck
3/4/2025
cs.CLcs.AIcs.LG

No confident code implementation found for this paper. 5 possible matches can be shown below.

Abstract

Current LLM pipelines account for only one possible tokenization for a given string, ignoring exponentially many alternative tokenizations during training and inference. For example, the standard Llama3 tokenization of penguin is [p,enguin], yet [peng,uin] is another perfectly valid alternative. In this paper, we show that despite LLMs being trained solely on one tokenization, they still retain semantic understanding of other tokenizations, raising questions about their implications in LLM safety. Put succinctly, we answer the following question: can we adversarially tokenize an obviously malicious string to evade safety and alignment restrictions? We show that not only is adversarial tokenization an effective yet previously neglected axis of attack, but it is also competitive against existing state-of-the-art adversarial approaches without changing the text of the harmful request. We empirically validate this exploit across three state-of-the-art LLMs and adversarial datasets, revealing a previously unknown vulnerability in subword models.

View on arXivView PDF

Code Implementations

No confident code match yet

We couldn't find an author-owned or strongly-evidenced community implementation for this paper. 5 weaker matches are hidden by default — verify before relying on them.

No code implementations found yet.

Know of an implementation? Let us know in the comments below!

Similar Papers

Cite this paper

@article{geh2025adversarial,
  title  = {Adversarial Tokenization},
  author = {Renato Lui Geh and Zilei Shao and Guy Van den Broeck},
  year   = {2025},
  eprint = {2503.02174},
  archivePrefix = {arXiv},
  url    = {http://arxiv.org/abs/2503.02174v2}
}

Add a badge to your README

Shows whether official code is linked for this paper.

Code of Paper badge
[![Code of Paper](https://codeofpaper.com/badge/2503.02174.svg)](https://codeofpaper.com/paper/2503.02174)

Discussion