Aller au contenu

Recherche en Sécurité IA : La Couche de Tokenisation et l'Exploitation du BPE

Dans la sécurité applicative traditionnelle, des vulnérabilités telles que l’injection SQL et la contrebande de requêtes HTTP (HTTP Request Smuggling) reposent fortement sur la manipulation de l’analyseur (le parseur). Si un attaquant parvient à désynchroniser la façon dont un proxy frontal et un serveur backend analysent les en-têtes HTTP, il peut introduire des charges utiles en contrebande.

Les systèmes d’IA Agentique souffrent exactement de la même classe de vulnérabilité au tout premier stade de leur pipeline : la tokenisation.

Les grands modèles de langage ne “lisent” pas des caractères ou des mots. Ils lisent des jetons (tokens) — des identifiants entiers représentant des unités de sous-mots. Lorsqu’un utilisateur saisit du texte, un script de tokenisation (s’exécutant sur le CPU) découpe le texte en un tableau d’entiers, qui est ensuite transmis au réseau de neurones (s’exécutant sur le GPU) pour récupérer des vecteurs (embeddings) à haute dimension.

Si un attaquant peut manipuler la façon dont une chaîne de caractères est découpée en entiers, il peut modifier complètement la représentation interne du prompt par le modèle, contournant ainsi les filtres qui ont été entraînés uniquement sur des entrées textuelles standards.

Les LLM modernes (incluant les familles GPT, Llama et Mistral) utilisent le Byte Pair Encoding (BPE) ou des algorithmes de tokenisation en sous-mots similaires (comme WordPiece ou SentencePiece).

Le BPE est une technique de compression de données. Lors de la phase de pré-entraînement du modèle, le tokenizer analyse des téraoctets de texte pour trouver les paires d’octets les plus fréquentes et les fusionne en un seul jeton.

  • Les mots courants deviennent des jetons uniques : [password]TokenID: 45902.
  • Les mots peu courants sont divisés en fragments de sous-mots : [passw, ord]TokenID: 1024, TokenID: 88.

La vulnérabilité : la tokenisation “canonique”

Section intitulée « La vulnérabilité : la tokenisation “canonique” »

Le BPE crée un chemin de découpage déterministe et hautement optimisé connu sous le nom de tokenisation canonique. Lorsque les ingénieurs en alignement de sécurité entraînent un LLM (via RLHF) à refuser les requêtes dangereuses (ex: “Comment fabriquer une bombe ?”), le réseau de neurones apprend à associer la séquence de jetons canonique de cette phrase à une forte pénalité de refus.

Le défaut architectural réside dans le fait que le réseau de neurones n’apprend jamais à refuser des tokenisations non canoniques du même concept sémantique.

3. Tokenisation adverse (Le glissement sémantique)

Section intitulée « 3. Tokenisation adverse (Le glissement sémantique) »

Comme le démontre l’article de référence de 2025 Adversarial Tokenization (Geh et al., ACL 2025), les LLM ne prennent en compte qu’une seule tokenisation possible lors de l’entraînement, ignorant un nombre exponentiel de tokenisations alternatives valides.

Les acteurs de la menace exploitent cela en forçant intentionnellement le tokenizer à diviser des mots dangereux de manière non canonique.

  1. La cible : l’attaquant veut que le LLM génère un script malveillant, ce qui déclencherait normalement les jetons canoniques pour [malware] ou [exploit].
  2. La manipulation : en introduisant de subtiles anomalies spatiales, des caractères de largeur nulle (zero-width characters), ou en exploitant des wrappers d’API qui permettent l’injection directe de tableaux, l’attaquant force une scission en sous-mots.
  3. Le contournement : au lieu que le LLM reçoive [malware], il reçoit [mal, ware].
  4. L’angle mort cognitif : le garde-fou de sécurité (entraîné uniquement sur le jeton canonique) ne se déclenche pas. Cependant, les couches profondes du Transformer sont suffisamment sophistiquées pour comprendre quand même le sens sémantique de [mal, ware] et générer avec succès la charge utile malveillante demandée.

Cette technique prouve que les adversaires peuvent contourner les alignements de sécurité de pointe sans modifier le texte visible de la requête nuisible, exposant une vulnérabilité critique dans les modèles basés sur les sous-mots.

Au-delà de modifier les limites de mots, les adversaires chassent des anomalies mathématiques dans l’espace de vocabulaire du tokenizer, connues sous le nom de Glitch Tokens.

Les Glitch Tokens sont des artefacts du processus d’entraînement — souvent des jetons qui étaient présents dans le vocabulaire du tokenizer mais qui sont apparus extrêmement rarement (ou manquaient de contexte) dans le corpus d’entraînement réel (ex: des chaînes de noms d’utilisateurs Reddit aléatoires ou des séquences hexadécimales obscures comme [ SolidGoldMagikarp]).

Lorsqu’un LLM rencontre un Glitch Token, sa représentation interne du texte s’effondre mathématiquement. Parce que le modèle n’a pratiquement aucun poids entraîné pour la façon dont ce jeton se rapporte aux autres, le vecteur d’embedding déclenche des activations chaotiques et imprévisibles.

Selon des recherches de 2025 (GlitchMiner: Mining Glitch Tokens in Large Language Models via Gradient-based Discrete Optimization, Wu et al.), les attaquants peuvent extraire systématiquement ces jetons pour atteindre deux objectifs malveillants distincts :

1. Paralysie du modèle (Déni de Service)

l’injection de Glitch Tokens spécifiques peut faire entrer le LLM dans un “blocage de génération de jetons” (token-generation deadlock). Le modèle se retrouve piégé dans une boucle infinie de répétition du même caractère ou d’espaces blancs, épuisant la VRAM du serveur et provoquant un Déni de Service (DoS) systémique pour tous les autres utilisateurs s’appuyant sur l’API.

2. Déraillement des garde-fous de sécurité

en ajoutant des Glitch Tokens soigneusement sélectionnés à un prompt hautement malveillant, l’attaquant dégrade de force la capacité de raisonnement sémantique du modèle juste assez pour briser le conditionnement de sécurité RLHF, mais pas suffisamment pour détruire sa capacité à répondre au prompt malveillant principal.

Détecter les attaques de tokenisation exige de déplacer l’observabilité aux toutes premières frontières de l’architecture de l’IA. Le filtrage traditionnel par mots-clés est inutile, car la charge utile de l’attaquant ressemble à du texte standard pour un humain.

Détection d’anomalies du ratio de jetons (Token-Ratio Anomaly)

Section intitulée « Détection d’anomalies du ratio de jetons (Token-Ratio Anomaly) »

Les centres opérationnels de sécurité (SOC) doivent surveiller le ratio jetons/caractères des prompts entrants. Dans un texte anglais ou français normal, un tokenizer BPE fait généralement une moyenne de ~4 caractères par jeton. Si un attaquant utilise la Tokenisation Adverse (forçant le tokenizer à diviser des mots normaux en minuscules fragments), le nombre de jetons grimpera de manière drastique sans augmentation correspondante de la longueur en caractères.

token_anomaly_sensor.py
# Un capteur middleware pour détecter les tentatives de Tokenisation Adverse
# avant que le prompt n'atteigne le moteur d'inférence du LLM.
import tiktoken
def analyze_token_ratio(user_prompt: str, threshold: float = 1.5) -> bool:
# Charger le tokenizer BPE spécifique utilisé par le modèle (ex: GPT-4)
tokenizer = tiktoken.encoding_for_model("gpt-4o")
char_count = len(user_prompt)
token_count = len(tokenizer.encode(user_prompt))
# Calculer le ratio
ratio = char_count / token_count if token_count > 0 else 0
# Si le ratio chute significativement (ex: en dessous de 1.5 caractère par jeton),
# cela indique une fragmentation excessive des sous-mots, signature d'une évasion.
if ratio < threshold:
print(f"[ALERTE] Fragmentation de jetons détectée. Ratio : {ratio:.2f}")
return True # Marquer comme suspect
return False

La tokenisation est la frontière d’exécution méconnue de l’Intelligence Artificielle. Alors que l’industrie de la cybersécurité se concentre sur le raisonnement sémantique et le Tool Injection, les acteurs de la menace redescendent au niveau du parseur.

Comprendre l’exploitation du BPE et les Glitch Tokens modifie fondamentalement la façon dont nous devons envisager la sécurité de l’IA. Une posture de sécurité robuste ne peut reposer uniquement sur “l’alignement” interne du LLM. Elle exige des pipelines de validation déterministes et rigoureux qui inspectent l’entropie, l’intégrité structurelle et les distributions de tokenisation de chaque prompt avant même qu’il n’atteigne le GPU.