Ce problème a été rapidement corrigé et divulgué sous le nom « CVE-2026-34219 » avec le crédit de l’équipe. La préoccupation plus large, cependant, était de séparer les véritables bugs des agents de ceux qui se faisaient passer pour tels.
« La surprise a été de voir à quel point peu de travail a été consacré à leur recherche, et combien a été consacré à distinguer les vrais bugs de ceux qui semblaient réels », a écrit Nikos Baxevanis, auteur du message.
La difficulté a commencé avec ce qu’un agent produit. Un fuzzer, l’outil standard qui envoie des données mal formées au logiciel jusqu’à ce que quelque chose se brise, renvoie un crash et un enregistrement de l’endroit où il s’est produit, qu’un ingénieur peut confirmer en quelques minutes.
Cependant, un agent renvoie un récit créé. Il retrace comment la faille a pu être atteinte, explique pourquoi elle est importante, propose une évaluation de la gravité et fournit un code fonctionnel qui démontre l’attaque. Tout cela arrive dans une prose fluide, se lisant de la même manière, que le bug soit réel ou inventé.
Trois types de faux positifs sont récurrents, selon la Fondation.
Le premier était un crash qui ne se produit que dans une version de test, où le compilateur active des contrôles de sécurité que le logiciel fourni ne comporte pas, de sorte que rien ne se casse pour les vrais utilisateurs.
La seconde était une attaque qui ne fonctionne que si la valeur dangereuse est insérée manuellement dans le programme, car tout chemin qu’un étranger pourrait emprunter pour la transmettre rejette d’abord la valeur. Le troisième est venu de la vérification formelle, la pratique consistant à prouver mathématiquement que le code se comporte correctement, où une preuve réussissait en démontrant quelque chose de trivialement vrai et ne disait rien aux évaluateurs sur le logiciel.