Protéger les LLMs : pourquoi l’injection de requêtes exige une défense en couches
Le danger principal de l’injection de requêtes ne réside pas uniquement dans la manipulation des réponses—c’est que chaque jeton dans la fenêtre de contexte d’un LLM peut être interprété comme une instruction. Que ce soit des entrées utilisateur, des documents récupérés ou des invites système, le modèle les traite tous de la même façon. Cette confusion des rôles explique pourquoi l’injection de requêtes est si subtile, et pourquoi le filtrage seul ne suffit pas à la contrer.
Une première ligne fragile : le filtrage échoue à grande échelle
Les premières défenses, comme le filtrage d’entrée ou le blocage de mots-clés, semblent simples : interdire certains termes et bloquer les requêtes malveillantes. Pourtant, les attaquants contournent ces mesures avec facilité : synonymes, fautes d’orthographe, leetspeak ou références indirectes passent entre les mailles. Moralité ? La correspondance de chaînes de caractères ne stoppe pas l’intention. Les listes autorisées et la classification sémantique des intentions fonctionnent mieux, mais supposent que les attaquants ne s’adapteront pas. Quant au filtrage en sortie, il repère les fuites évidentes, mais s’effondre lorsque les secrets sont fragmentés ou encodés—rendant la recherche de sous-chaînes inutile.
Empiler des couches ne suffit pas
Combiner filtres d’entrée et de sortie relève le niveau de difficulté, mais chaque couche hérite des mêmes faiblesses. Une fois passé le premier filtre, l’obfuscation contourne le second. La défense en profondeur compte, mais « plus de filtres » ne rime pas avec sécurité. La vraie solution réside dans la réduction des accès des LLMs dès l’origine. Considérez toute entrée comme hostile, et supposez que chaque sortie doit être validée—notamment censurée.
Les limites de l’IA et de la supervision humaine
Un LLM secondaire jouant le rôle de garde-fou semble prometteur—il comprend le sens, pas seulement le texte. Pourtant, il reste vulnérable au social engineering, où les attaquants transforment des secrets en éléments inoffensifs ou exploitent des lacunes dans son entraînement. La revue humaine ne fait pas mieux : un texte rendu masque l’ASCII smuggling, où des charges utiles cachées échappent à la fois au modèle et à l’œil humain. Le constat ? Aucune couche n’est infaillible. La sécurité doit commencer par des contrôles d’accès stricts et s’étendre à la purification brute des entrées, avant qu’un humain ou une IA ne les voie.
En définitive, l’injection de requêtes n’est pas qu’une faille technique—c’est une contrainte de conception. Les LLMs n’ont pas de frontières nettes, donc les défenses ne peuvent s’y reposer. La solution consiste à traiter chaque interaction comme une surface d’attaque potentielle et à construire des garde-fous qui intègrent cette réalité.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.