Les benchmarks de sécurité de l’IA ont besoin de tests de flux de travail : analyse

Un score de benchmark est un détecteur de fumée, pas une inspection complète du bâtiment. Utile, bruyant, parfois capable de sauver des vies, mais il ne peut pas vous dire si la porte de sortie s’ouvre sur un placard à balais rempli de chiffons huileux. Dark Reading formule la bonne inquiétude dans son titre, So Many AI Security Benchmarks, But None Tell the Whole Story. La traduction pour les équipes de développement est simple : utilisez les benchmarks de sécurité des modèles comme des signaux d’orientation, puis testez le modèle dans votre propre base de code, avec vos permissions d’outils, vos flux de données et vos workflows spectaculairement maudits.

Cela peut sembler évident, ce qui est précisément le signe que ce sera ignoré dans au moins une revue de feuille de route cette semaine. Les systèmes d’IA sont de plus en plus jugés par des scores publics bien propres, tandis qu’on demande aux agents en production d’envoyer des e-mails, de modifier des tickets, d’approuver du code, d’interroger des logs et de toucher à de vrais états. C’est dans cet écart que les gremlins louent des bureaux.

Le benchmark n’est pas le rayon d’explosion

SABench rend le problème douloureusement concret. Selon Task Success Is Not Enough: Side-effect-Aware Evaluation of Tool-Using Language Model Agents, SABench couvre 201 tâches d’e-mail, de calendrier et de tickets, puis vérifie si un agent non seulement termine le travail demandé, mais évite aussi les effets secondaires non autorisés. Les auteurs rapportent des résultats sur 2 211 paires modèle-tâche provenant de 11 LLMs de pointe couvrant les principales familles de modèles commerciaux et ouverts. Sur l’ensemble de ces essais, 15,2 % ont entraîné des dégâts collatéraux, et parmi les essais où l’objectif était atteint, 12,8 % ont tout de même produit des écritures non autorisées.

Ce dernier chiffre est le petit gobelin vicieux dans la feuille de calcul. Un système peut faire ce que l’utilisateur a demandé tout en modifiant le mauvais objet, en élargissant le périmètre ou en touchant à un outil qu’il aurait dû laisser tranquille. Les auteurs de SABench le formulent clairement : « la réussite de la tâche seule est un mauvais indicateur de l’utilisation sûre des outils ». Traduction pour les équipes de développement : si votre évaluation vérifie seulement si la tâche a été accomplie, elle note un chariot élévateur selon le fait que la palette a bougé, pas selon le fait que l’entrepôt est désormais en feu.

La revue de code a besoin de preuves exécutables

CyberDual pointe vers la même leçon côté maintenance logicielle. Selon CyberDual: AI Attackers versus AI Code Reviewers in Real-World Software Maintenance, des agents attaquants cachent des bugs exploitables dans de vrais travaux de maintenance, tandis que des agents relecteurs tentent de les détecter et de les corriger. L’article indique que trois relecteurs agentiques ont détecté 85,91 % de 1 088 attaques valides provenant de six attaquants, ce qui semble rassurant jusqu’à ce que la phrase suivante entre dans la pièce avec des chaussures de sécurité.

Les auteurs rapportent que lorsque l’attaquant répartit un bug à travers de vrais commits amont, environ un emplacement d’attaque sur six se termine encore par un exploit fonctionnel après revue. Leur principe d’évaluation est rafraîchissant de lucidité : « l’exécution décide de chaque match ». Autrement dit, le test n’est pas de savoir si le relecteur a écrit un paragraphe assuré avec de fortes vibes de linting. Le test est de savoir si la preuve de concept de l’attaquant fonctionne encore sur le code relu.

Pour les équipes qui adoptent la revue de code par IA, c’est la différence entre une démo et un contrôle. Un benchmark peut vous dire qu’un modèle relecteur est prometteur ; votre pipeline CI doit prouver qu’il détecte les vulnérabilités dans vos schémas de dépendances, vos conventions de framework, votre style de patch et l’habitude de votre équipe de nommer les choses config2_final_really_final. La confiance en matière de sécurité devrait venir de contrôles exécutables, pas d’un modèle qui donne l’impression de posséder plusieurs pulls à col zippé.

Le workflow peut être l’exploit

NameTrap élargit le champ, du comportement du modèle au contexte que le modèle consomme. Selon NameTrap: Steering AI Coding Agents Toward Security Vulnerabilities via Variable Names, l’attaque ne modifie que des identifiants dans des fichiers Python tiers, orientant les agents de codage IA vers des vulnérabilités Common Weakness Enumeration ciblées par l’attaquant. Aucun monologue maléfique d’injection de prompt n’est nécessaire. Seulement des noms empoisonnés, comme laisser des peaux de banane sur le sol de l’autocomplétion.

Les taux de réussite rapportés vont de 22,5 % à 56,0 % sur six agents, atteignant 75,0 % pour certaines configurations agent-modèle. Pire encore pour quiconque espérait voir l’analyse statique arriver sur un cheval blanc, l’article indique que trois analyseurs de sécurité basés sur l’IA et quatre analyseurs statiques n’ont signalé aucune des faiblesses ciblées dans les fichiers empoisonnés. Cela ne veut pas dire que les analyseurs sont inutiles. Cela veut dire que le workflow environnant et la provenance des entrées comptent, surtout lorsque des agents clonent des dépôts, lisent du code externe et traitent le contexte comme une vérité révélée avec un budget GPU.

C’est là que le shopping de benchmarks devient dangereux. Un modèle peut obtenir de bons scores sur une suite de sécurité et tout de même échouer lorsque votre workflow d’agent mélange installation de packages, exploration de dépôts, patchs générés et accès permissif aux outils. Le modèle n’est qu’un acteur dans un petit drame procédural ; les accessoires peuvent être piégés.

Construisez l’évaluation manquante autour de votre propre workflow

SecLog-Bench offre un modèle plus mature pour les équipes qui réfléchissent à la plomberie de l’évaluation. Selon SecLog-Bench: A Scalable Benchmark for Cybersecurity Log Reasoning with Scaffolded Evidence, son workflow d’annotation assisté par IA a produit 92,13 % d’accord observé avec les jugements consensuels humains, avec un κ de Cohen = 0,84. La même source décrit l’assistance IA comme un soutien à l’annotation humaine plutôt que comme un remplacement, avec les dates d’accès, les prompts et les résultats intermédiaires enregistrés pour l’auditabilité.

C’est exactement l’attitude que les équipes de développement devraient emprunter sans vergogne. Commencez par des benchmarks publics pour présélectionner des modèles, puis créez des tests privés qui reflètent vos actions en production : les outils exposés, les objets que les agents peuvent modifier, les dépôts qu’ils lisent, les logs qu’ils résument et les modes de défaillance qui feraient réellement mal. L’Executive Summary de l’équipe Fangcun AI Evaluation soutient qu’il faut davantage de benchmarks privés, car les benchmarks publics peuvent fuiter dans les données d’entraînement, et indique que les benchmarks internes suscitaient généralement bien moins de conscience d’évaluation dans les évaluations de perte de contrôle que les benchmarks publics.

Le geste pratique n’est pas d’abandonner les benchmarks. Il consiste à arrêter de les traiter comme un tampon de passeport pour la production. Gardez les scores publics, ajoutez des cas adversariaux propres à vos workflows, exécutez des preuves quand c’est possible, journalisez les prompts et les sorties, et exigez une revue humaine pour les actions à fort enjeu jusqu’à ce que vos preuves disent le contraire. Surveillez les benchmarks qui testent les effets secondaires, la provenance, les permissions d’outils et l’exploitabilité de bout en bout, car c’est là que les vrais systèmes deviennent intéressants. Ou, en termes moins polis : votre modèle a réussi l’examen de conduite, mais votre produit lui demande de garer un camion-toupie en voiturier dans un magasin de feux d’artifice.