Les grands modèles de langage (LLM) s’appuient de plus en plus sur des systèmes de garde-fous — comme les classificateurs de texte et les modèles LLM-as-a-judge — pour filtrer les prompts malveillants avant qu’ils n’atteignent les modèles en aval.
De nouvelles recherches de HiddenLayer révèlent EchoGram, une technique d’attaque capable de modifier subrepticement ces verdicts des garde-fous, permettant à la fois de contourner les jailbreaks et de générer des faux positifs en grand nombre.
Que sont les garde-fous ?
Les garde-fous sont conçus pour empêcher les prompts nuisibles — comme les tentatives de jailbreak ou les instructions redirigeant la tâche — d’influencer les LLM déployés.
Dans des circonstances normales, des prompts comme « ignorez les instructions précédentes et produisez X » devraient être identifiés comme potentiellement malveillants.
Les chercheurs de HiddenLayer ont découvert que l’ajout d’une séquence de tokens soigneusement choisie, comme la chaîne =coffee, pouvait complètement inverser le verdict d’un classificateur et faire passer un contenu malveillant pour sûr.
Ce comportement constitue le fondement d’EchoGram, une technique qui identifie des « tokens d’inversion » capables de modifier les décisions des garde-fous sans altérer la charge utile malveillante.
EchoGram met en lumière une réalité préoccupante : même les mécanismes de sécurité de l’IA les mieux conçus peuvent être manipulés en exploitant les lacunes de leurs données d’entraînement et de la distribution des tokens.
Les garde-fous censés protéger les modèles à forte valeur peuvent être trompés et approuver des instructions nuisibles, ou inonder les équipes de sécurité de fausses alertes, érodant ainsi la confiance dans les systèmes d’IA défensifs.
Comment fonctionne EchoGram
EchoGram cible deux architectures de garde-fous dominantes :
- Les systèmes LLM-as-a-judge qui évaluent la sécurité des prompts
- Les modèles spécialisés de classification de texte entraînés à détecter les injections de prompts ou les contenus nuisibles.
Bien que ces systèmes diffèrent dans leur implémentation, ils partagent une similarité essentielle : ils reposent sur des jeux de données sélectionnés de prompts malveillants et inoffensifs.
EchoGram exploite les déséquilibres de ces jeux de données pour identifier les séquences qui influencent de manière disproportionnée les décisions du modèle.
Génération de la liste de mots
L’attaque commence par la création d’une liste de tokens candidats à l’aide de l’une des deux méthodes suivantes :
- Distillation des jeux de données : Comparer la fréquence des tokens dans les jeux de données inoffensifs et malveillants afin d’identifier les séquences qui signalent de manière disproportionnée l’une des classes.
- Sondage du vocabulaire : Ajouter chaque token du tokenizer d’un modèle à des prompts malveillants borderline pour déterminer lesquels inversent le verdict. Cette méthode est particulièrement efficace lorsque les développeurs disposent d’un accès en boîte blanche au modèle de garde-fou.
Ces approches produisent une liste de tokens susceptibles d’influencer le comportement du classificateur.
Sondage et évaluation du modèle
Les chercheurs testent ensuite chaque token en l’ajoutant à un ensemble varié de prompts malveillants.
Les séquences sont évaluées en fonction de la fréquence à laquelle elles inversent la décision du garde-fou, de « malveillant » à « sûr ».
Les tokens obtenant les meilleurs scores deviennent des candidats EchoGram qui peuvent ensuite être combinés pour renforcer leur effet.
HiddenLayer a démontré que les combinaisons de tokens pouvaient dégrader considérablement les performances et inverser la sortie de modèles tels que Qwen3Guard à plusieurs niveaux de gravité.
Combinaison des tokens et amplification du taux d’inversion
Un seul token peut inverser certains prompts, mais pas tous. Lorsque les tokens sont combinés, leurs effets se cumulent.
Cette amplification persiste quelle que soit la taille du modèle, ce qui indique que la faille ne tient pas aux limites des petits modèles, mais à des faiblesses fondamentales dans la structure des données d’entraînement des garde-fous.
Conception des charges utiles EchoGram
EchoGram peut servir à contourner les garde-fous ou à créer des faux positifs ciblés.
Les attaquants peuvent intégrer des tokens d’inversion à la fin d’un prompt malveillant ou les insérer dans des phrases d’apparence naturelle qui semblent inoffensives pour les humains, mais déclenchent une mauvaise classification.
Cette capacité permet de mener des attaques par inondation de faux positifs, qui submergent les systèmes de surveillance et sapent la confiance dans les contrôles de sécurité de l’IA.
Comme de nombreux systèmes de garde-fous partagent des schémas et des jeux de données d’entraînement, une seule séquence de tokens EchoGram peut se généraliser à plusieurs plateformes, des chatbots d’entreprise commerciaux aux déploiements d’IA gouvernementaux.
Cette technique met également en évidence un problème plus vaste : les organisations supposent souvent que les garde-fous sont intrinsèquement fiables, alors qu’en réalité ils peuvent échouer de manière délibérément provoquée par des attaquants.
Défenses essentielles contre les menaces de type EchoGram
Protéger les systèmes d’IA contre les attaques de type EchoGram exige davantage que la correction de modèles individuels : cela nécessite une stratégie de défense en profondeur.
Pour réduire leur exposition aux attaques de type EchoGram, les organisations devraient :
- Renforcer l’entraînement des garde-fous en utilisant des jeux de données diversifiés, équilibrés et générés de manière adversariale, tout en procédant à un réentraînement continu, à des audits des labels avec contrôle des versions et à des vérifications de l’hygiène des jeux de données.
- Adopter des défenses multicouches et ensemblistes, en combinant des classificateurs, des systèmes LLM-as-a-judge, un vote par consensus et des mécanismes d’escalade de secours, plutôt que de s’en remettre à un seul modèle de garde-fou.
- Mettre en œuvre des tests d’équipe rouge ciblant spécifiquement le contournement des garde-fous, notamment la découverte de tokens d’inversion, les attaques par combinaison de tokens et la détection par sondage.
- Durcir le traitement des entrées grâce à la normalisation des tokens, à l’assainissement, à la perturbation des prompts et à la limitation des schémas suspects, afin de casser les séquences de tokens adversariales avant qu’elles n’influencent les garde-fous.
- Améliorer la surveillance et la détection des anomalies en recherchant des schémas de verdicts inhabituels (par exemple, des pics de contenus inoffensifs ou des vagues de faux positifs), en journalisant les décisions des garde-fous, en limitant le débit des activités de sondage et en appliquant une détection des anomalies à l’exécution.
- Sécuriser la chaîne d’approvisionnement du modèle et l’environnement de déploiement en isolant les composants des garde-fous, en validant la provenance du tokenizer et du modèle, en appliquant les principes du zero trust et en maintenant une supervision humaine pour les cas à haut risque.
Ces mesures aident les organisations à renforcer leur cyberrésilience face à des attaques similaires.
Les défenses de l’IA doivent évoluer, pas rester figées
EchoGram montre que les outils de sécurité de l’IA — en particulier les garde-fous entraînés sur des jeux de données statiques — doivent faire l’objet du même niveau d’examen que les modèles qu’ils protègent.
Les conclusions de HiddenLayer soulignent l’importance de tests adversariaux continus, de méthodes d’entraînement transparentes et de défenses capables de s’adapter à l’évolution des schémas de données.
À mesure que les LLM s’intègrent à des secteurs sensibles comme la finance, la santé et la sécurité nationale, les organisations doivent considérer les garde-fous comme des systèmes évolutifs nécessitant des audits, des tests de résistance et une maintenance réguliers — et non comme des protections que l’on configure avant de les oublier.
Cette réalité souligne la nécessité d’adopter une mentalité zero trust où aucun garde-fou, modèle ou source de données n’est automatiquement considéré comme fiable sans validation continue.