J'ai construit un scanner de sécurité IA — puis j'ai trouvé un bug dans mon propre détecteur

L'injection de prompt est l'un des principaux risques de sécurité pour les applications LLM. Vous fournissez au modèle un texte qui lui demande d'ignorer ses instructions initiales. Parfois, le modèle obéit.

J'ai conçu AgentProbe pour tester cela. Il lance 49 prompts d'attaque répartis sur 8 catégories, telles que les jailbreaks et l'extraction de données. Il indique la fréquence à laquelle un modèle échoue.

La véritable leçon n'était pas le scanner. C'était un bug dans mon code de détection.

Le plus difficile n'est pas l'attaque. Le plus difficile, c'est la détection.

Comment savoir si un modèle a réellement cédé à une attaque ? La recherche par mots-clés est la méthode simple. On cherche des phrases de refus comme « Je ne peux pas vous aider » ou des phrases de conformité comme « mode développeur ».

Mais les modèles utilisent un schéma de type « hésitation puis conformité » (hedge-then-comply). Ils disent « Je ne peux pas vous aider avec cela », mais fournissent ensuite les informations restreintes malgré tout. La recherche par mots-clés échoue ici car la phrase de refus est présente.

Pour corriger cela, j'ai utilisé un système de type « LLM-as-judge » (LLM comme juge). J'ai envoyé l'échange à un modèle plus puissant pour décider si la cible avait réellement cédé. Mon plan était d'utiliser d'abord des vérifications par mots-clés peu coûteuses, et de n'utiliser le juge coûteux que lorsque la vérification par mots-clés n'était pas concluante.

C'est alors que j'ai trouvé mon bug.

Mon détecteur de mots-clés renvoyait un score de confiance de 1 lorsqu'il trouvait un schéma « hésitation puis conformité ». Cependant, mon code ne faisait confiance à l'étape des mots-clés que si la confiance était de 2 ou plus.

Cela signifiait que mon détecteur « économique » ne prenait jamais réellement de décision. Chaque cas était transmis au juge coûteux. Je payais un juge pour chaque cas, même lorsque mon outil gratuit aurait dû s'en charger.

Cette erreur m'a enseigné trois leçons sur l'utilisation des LLM pour évaluer d'autres LLM :

  • Le juge doit être plus intelligent que la cible. Si le juge est de la même taille que la cible, il partagera les mêmes angles morts.
  • La précision peut être trompeuse. Si la plupart des modèles refusent, un juge qui dit toujours « refusé » semble précis mais n'apprend rien. Utilisez des métriques comme le kappa de Cohen pour tenir compte de la chance.
  • Le juge doit être stable. Lancez le même test cinq fois. Si le juge change d'avis, le résultat est ambigu et nécessite un œil humain.

Si vous développez avec des LLM, gardez ces points à l'esprit :

  • Détecter la conformité est plus difficile que de la provoquer.
  • Surveillez les modèles qui refusent dans la première phrase mais obéissent dans la seconde.
  • Ne faites pas aveuglément confiance à un juge LLM. Mesurez sa fiabilité.
  • Partagez vos bugs. Découvrir ma propre faille m'a plus appris qu'un lancement parfait ne l'aurait fait.

Source : https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi