In traditional application security, vulnerabilities like SQL Injection and HTTP Request Smuggling rely heavily on manipulating the parser. If an attacker can desynchronize how a frontend proxy and a backend server parse HTTP headers, they can smuggle payloads.
Agentic AI systems suffer from the exact same class of vulnerability at the very first stage of their pipeline: Tokenization.
Large Language Models do not “read” characters or words. They read tokens—integer IDs representing subword units. When a user inputs text, a tokenizer script (running on the CPU) chunks the text into an array of integers, which is then fed into the neural network (running on the GPU) to retrieve high-dimensional embeddings.
If an attacker can manipulate how a string of characters is chunked into integers, they can completely alter the model’s internal representation of the prompt, evading filters that were trained solely on standard textual inputs.
Modern LLMs (including the GPT, Llama, and Mistral families) utilize Byte Pair Encoding (BPE) or similar subword tokenization algorithms (like WordPiece or SentencePiece).
BPE is a data compression technique. During the model’s pre-training phase, the tokenizer analyzes terabytes of text to find the most frequently occurring byte pairs and merges them into a single token.
[password] → TokenID: 45902.[passw, ord] → TokenID: 1024, TokenID: 88.BPE creates a deterministic, highly optimized chunking path known as Canonical Tokenization. When safety alignment engineers train an LLM (using RLHF) to refuse dangerous requests (e.g., “How do I build a bomb?”), the neural network learns to associate the canonical token sequence of that phrase with a high refusal penalty.
The architectural flaw is that the neural network never learns to refuse non-canonical tokenizations of the same semantic concept.
As demonstrated in the landmark 2025 paper Adversarial Tokenization (Geh et al., ACL 2025), LLMs account for only one possible tokenization during training, ignoring exponentially many alternative valid tokenizations.
Threat actors exploit this by intentionally forcing the tokenizer to split dangerous words in non-canonical ways.
[malware] or [exploit].[malware], it receives [mal, ware].[mal, ware] and successfully generate the requested malicious payload.This technique proves that adversaries can bypass state-of-the-art safety alignments without changing the visible text of the harmful request, exposing a critical vulnerability in subword models.
Beyond shifting boundaries, adversaries hunt for mathematical anomalies in the tokenizer’s vocabulary space known as Glitch Tokens.
Glitch tokens are artifacts of the training process—often tokens that were present in the tokenizer’s vocabulary but appeared extremely rarely (or lacked context) in the actual training corpus (e.g., strings of random Reddit usernames or obscure hexadecimal sequences like [ SolidGoldMagikarp]).
When an LLM encounters a glitch token, its internal representation of the text mathematically collapses. Because the model has virtually no trained weights for how this token relates to others, the embedding vector triggers unpredictable, chaotic activations.
According to 2025 research (GlitchMiner: Mining Glitch Tokens in Large Language Models via Gradient-based Discrete Optimization, Wu et al.), attackers can systematically mine these tokens to achieve two distinct malicious goals:
1. Model Paralysis (Denial of Service)
Injecting specific glitch tokens can cause the LLM to enter a “token-generation deadlock.” The model gets trapped in an infinite loop of repeating the same character or outputting blank spaces, exhausting the server’s VRAM and causing a systemic Denial of Service (DoS) for all other users relying on the API.
2. Safety Guardrail Derailment
By appending carefully selected glitch tokens to a highly malicious prompt, the attacker forcefully degrades the model’s semantic reasoning capability just enough to break the RLHF safety conditioning, but not enough to destroy its ability to answer the core malicious prompt.
Detecting tokenization attacks requires shifting observability to the very edge of the AI architecture. Traditional keyword filtering is useless because the attacker’s payload looks like standard text to a human.
Security Operations Centers (SOC) must monitor the Token-to-Character Ratio of incoming prompts. In normal English text, a BPE tokenizer typically averages ~4 characters per token. If an attacker is using Adversarial Tokenization (forcing the tokenizer to split normal words into tiny fragments), the token count will spike drastically without a corresponding increase in character length.
# A middleware sensor to detect Adversarial Tokenization attempts# before the prompt reaches the LLM inference engine.import tiktoken
def analyze_token_ratio(user_prompt: str, threshold: float = 1.5) -> bool: # Load the specific BPE tokenizer used by the model (e.g., GPT-4) tokenizer = tiktoken.encoding_for_model("gpt-4o")
char_count = len(user_prompt) token_count = len(tokenizer.encode(user_prompt))
# Calculate the ratio ratio = char_count / token_count if token_count > 0 else 0
# If the ratio drops significantly (e.g., below 1.5 chars per token), # it indicates excessive subword splitting, a hallmark of evasion. if ratio < threshold: print(f"[ALERT] Token fragmentation detected. Ratio: {ratio:.2f}") return True # Flag as suspicious return FalseTokenization is the unsung execution boundary of Artificial Intelligence. As the cybersecurity industry focuses on semantic reasoning and Tool Injection, threat actors are descending to the parser level.
Understanding BPE exploitation and glitch tokens fundamentally changes how we must view AI safety. A robust security posture cannot rely solely on the LLM’s internal “alignment.” It requires rigorous, deterministic validation pipelines that inspect the entropy, structural integrity, and tokenization distributions of every prompt before it ever reaches the GPU.