Sécurité et confidentialité

La descente de gradient brise les classificateurs d'injection de prompts à poids ouverts

Tom Ganz démontre que les attaques Greedy Coordinate Gradient peuvent contourner les détecteurs populaires d'injection de prompts en ajoutant des suffixes de tokens optimisés.

Un bouclier en verre se brisant sous des symboles mathématiques et des tuiles de lettres
Illustration générée pour cet article

Traduit automatiquement depuis l'original anglais.

Les chercheurs en sécurité s'appuient souvent sur de petits modèles de classification pour filtrer les invites malveillantes avant qu'elles n'atteignent les grands modèles de langage. Dans une analyse technique récente, Tom Ganz montre que cette défense courante est fragile lorsque les poids du classificateur sont publiquement disponibles. En appliquant des techniques de descente de gradient, les attaquants peuvent ajouter de courts suffixes sans sens aux invites malveillantes, forçant ainsi les détecteurs à les classer comme bénignes.

Ce qui s'est passé

Le conseil standard pour prévenir l'injection de prompts consiste à placer un classificateur léger devant le modèle principal. Ce filtre lit le texte entrant et décide s'il contient une tentative d'injection, écartant les entrées dangereuses avant qu'elles ne consomment des ressources de calcul coûteuses. Ganz a développé Smolaya-guard, un modèle de 323 millions de paramètres basé sur l'architecture Laya, qui note les invites en une seule passe avant. Sur des données de test réservées, ce classificateur a atteint une AUC de 0,9998 et détecté 99,7 % des injections avec seulement un taux de faux positifs de 1 %, semblant constituer une frontière de sécurité robuste.

Malgré ces métriques solides, Ganz a démontré que tout détecteur dont les poids sont ouverts peut être contourné en utilisant des attaques Greedy Coordinate Gradient (GCG). La méthode consiste à attacher un court suffixe de tokens à la fin d'une invite malveillante. L'attaquant optimise ces tokens pour minimiser le score de confiance du détecteur, le faisant passer sous le seuil de sécurité. Comme les poids du modèle sont publics, l'attaquant peut calculer exactement comment chaque changement potentiel de token affecte la marge de sortie, lui permettant de créer un suffixe qui trompe le classificateur tout en laissant l'intention malveillante originale intacte pour le modèle cible.

Comment cela fonctionne

Un détecteur d'injection de prompts produit généralement un score de marge, calculé comme la différence entre les logits « injection » et « bénin ». Si cette marge dépasse un seuil spécifique, l'invite est signalée. Pour Smolaya-guard, le seuil est fixé à -3,18 pour maintenir un faible taux de faux positifs, tandis que les injections réelles obtiennent généralement des scores compris entre +7 et +9. L'objectif de l'attaque est de trouver un suffixe qui réduit cette marge sous le seuil.

Puisque les tokens sont des unités discrètes, la descente de gradient standard ne peut pas être appliquée directement. GCG résout ce problème en traitant temporairement les embeddings de tokens comme des variables continues. L'algorithme calcule le gradient de la marge par rapport à chaque position de token, identifiant quels mots du vocabulaire abaisseraient le plus significativement le score s'ils étaient substitués. Il teste ensuite un lot de ces substitutions candidates contre le vrai modèle, conservant le changement qui produit la marge la plus basse. Ce processus se répète pendant quelques étapes jusqu'à ce que l'invite soit mal classifiée.

Détails clés

  • Ganz a testé l'attaque contre trois modèles à poids ouverts : Smolaya-guard, protectai/deberta-v3-base-prompt-injection-v2 et nvidia/Nemotron-3.5-Content-Safety.
  • L'attaque a réussi à contourner les trois détecteurs, ramenant des scores d'injection confiants à des niveaux bénins.
  • Pour Smolaya-guard, 12 des 12 injections testées ont été mal classifiées après l'ajout d'un suffixe de 30 tokens optimisé sur 10 étapes.
  • Un suffixe universel a été créé pour le modèle ProtectAI qui a abaissé la marge moyenne d'un lot d'injections de +15,3 à -13.
  • Le modèle plus grand Nemotron-3.5-Content-Safety a nécessité 136 étapes d'optimisation pour inverser son verdict de non sûr à sûr.
  • Les suffixes ajoutés sont souvent du charabia ou contiennent des mots irrélevants comme « benign », servant uniquement à manipuler les calculs internes du modèle.

Pourquoi c'est important

Cette analyse révèle une faiblesse fondamentale dans le fait de compter sur des classificateurs à poids ouverts comme frontières de sécurité. Lorsque les poids du modèle sont publics, les adversaires ont un accès complet aux informations de gradient nécessaires pour créer des exemples adverses. Cela signifie que publier un classificateur avec des poids ouverts fournit effectivement aux attaquants les outils pour le briser. La taille ou la complexité du modèle n'empêche pas cela ; même un juge génératif de 4,3 milliards de paramètres comme Nemotron a été trompé par la même approche basée sur le gradient, bien qu'avec plus de calcul.

Pour les ingénieurs développant des applications IA, cela implique que le filtrage des prompts seul est insuffisant si le filtre est vulnérable aux attaques par gradient. L'hypothèse qu'un score AUC élevé sur des ensembles de tests statiques se traduit par une sécurité réelle est erronée lorsque l'adversaire peut s'adapter à la frontière de décision spécifique du modèle. Les stratégies de sécurité doivent tenir compte du fait que toute barrière déterministe et différentiable avec des paramètres exposés peut être optimisée contre elle.

Ce que vous pouvez faire

  • Évitez de compter uniquement sur des classificateurs à poids ouverts pour les décisions critiques de sécurité dans les environnements de production.
  • Envisagez d'utiliser des outils de modération basés sur API fermées où les informations de gradient ne sont pas accessibles aux attaquants.
  • Mettez en œuvre des stratégies de défense en profondeur, telles que la validation des sorties et le sandboxing, plutôt que de faire confiance exclusivement aux filtres d'entrée.
  • Surveillez les motifs de tokens inhabituels ou les suffixes à haute entropie dans les entrées utilisateur qui pourraient indiquer des tentatives adverses.
  • Mettez à jour et faites tourner régulièrement les modèles de détection pour augmenter le coût de création de suffixes adverses universels.
  • Testez vos propres classificateurs contre les attaques GCG pendant le développement afin de comprendre leurs vulnérabilités spécifiques.

Outils de la Boutique Bytechap

Continuer la lecture

Tous les articles