Notes de l'équipe de sécurité du protocole de la Fondation Ethereum sur l'exécution d'agents d'IA coordonnés sur du vrai code de protocole, y compris la façon dont nous organisons le travail, ce qui résiste à l'examen, et ce que les équipes clientes et les chercheurs en sécurité peuvent en tirer. Cet article se suffit à lui-même ; des articles ultérieurs approfondiront les clients individuels.
Ce que nous avons exécuté, et ce qui nous a surpris
Au sein de l'équipe de sécurité du protocole de la Fondation Ethereum, nous avons exécuté des agents d'IA coordonnés sur les types de systèmes dont dépend le réseau, comme les logiciels système, le code cryptographique et les contrats qui se doivent d'être corrects. Les agents ont trouvé de vrais bugs. L'un d'eux est désormais public : une panique déclenchable à distance dans le gossipsub de libp2p, une partie essentielle de la couche pair à pair sur laquelle s'exécutent les clients de consensus d'Ethereum, corrigée et divulguée sous le nom de CVE-2026-34219 en créditant l'équipe.
Que les agents trouvent des bugs n'était pas la surprise. La surprise a été de constater à quel point la recherche de ces bugs a demandé peu de travail, et à quel point il a fallu en fournir pour distinguer les vrais bugs de ceux qui en avaient seulement l'air.
Cet article s'adresse aux équipes clientes et aux chercheurs en sécurité qui souhaitent faire de même. Il couvre la façon dont nous organisons les agents, le niveau d'exigence qu'un candidat doit atteindre avant d'être considéré comme une découverte, et les habitudes qui permettent de maintenir la fiabilité des résultats.
D'autres équipes convergent vers la même recette. La Frontier Red Team d'Anthropic a construit un agent qui écrit des tests basés sur les propriétés et a trouvé de vrais bugs dans tout l'écosystème Python. Cloudflare a exécuté un modèle Frontier via un harnais de recherche en sécurité sur ses propres systèmes. Tout le monde aboutit à la même boucle : pointer un modèle performant sur une base de code, le laisser chercher, et trier ce qui en ressort. La vraie question est donc de savoir comment faire cela sans se noyer dans un bruit qui semble pourtant très sûr de lui.
Une mise en garde d'emblée : les outils pour les audits pilotés par des agents évoluent rapidement, et toute configuration spécifique devient obsolète en quelques semaines. Cet article porte donc délibérément sur les méthodes, qui sont pérennes, plutôt que sur les outils. La divulgation est un sujet à part entière et fera probablement l'objet d'un article dédié.
Un agent est un outil de recherche, pas un oracle
Un agent pointé sur une base de code est un outil de recherche, un peu comme un fuzzer. La différence réside dans ce qui en ressort. Un fuzzer vous donne un plantage et une trace d'appels. Un agent vous donne beaucoup plus, y compris un compte-rendu (chaîne d'appels, réclamation d'impact, gravité suggérée) et les artefacts pour l'étayer, comme une preuve de concept que vous pouvez exécuter sur le vrai code.
Tout cela rend le résultat facile à lire et digne de confiance, la preuve de concept fonctionnelle par-dessus tout. Ne comptez donc pas le nombre de candidats qu'un agent produit. Comptez combien s'avèrent être réels.
Comment le travail est organisé
Nous exécutons de nombreux agents en parallèle sur une seule cible. Ils se coordonnent via le dépôt lui-même, avec un état partagé dans le contrôle de version et aucun processus central distribuant le travail. Un agent rédige une réclamation là où les autres peuvent la voir, fait le travail, et valide (commit).
Nous avons tiré cette approche de l'article d'Anthropic sur la construction d'un compilateur C avec une flotte d'agents, qui se coordonne de la même manière. Il n'y a pas de coordinateur central à construire ou à maintenir, et moins de choses qui peuvent mal tourner.
Les rôles sont générés par le travail qui est découvert :
- La reconnaissance transforme une surface d'attaque en hypothèses concrètes et testables. Pas « auditer le décodeur » mais « ce champ est considéré comme fiable au-delà de ce point ; voici la propriété qu'il devrait conserver, la façon dont il pourrait se briser, et la preuve qui le confirmerait ».
- La traque prend une hypothèse, trace le chemin du code, et essaie de construire un reproducteur.
- Le comblement des lacunes examine ce qui a été accepté et ce qui a été rejeté, rédige le prochain lot d'hypothèses, et suit la couverture afin que les agents ne repassent pas sans cesse sur le même terrain.
- La validation revérifie chaque candidat de manière indépendante, supprime les doublons, et décide.
Nous n'avons pas inventé ce pipeline. Cloudflare décrit les mêmes étapes : reconnaissance, traque parallèle, validation indépendante, déduplication, signalement, et leur article a contribué à façonner le nôtre.
Voici à quoi ressemble un candidat avant d'être considéré comme une découverte :
cible : composant et point d'entrée qu'un attaquant peut réellement atteindre invariant : la propriété qui doit être maintenue mécanisme : la manière spécifique dont il pourrait être amené à se briser succès : preuve observable : une panique, un blocage, une entrée invalide acceptée reproducteur : un artefact autonome qui s'exécute sur le vrai code dédup : une clé, pour que deux agents ne poursuivent pas la même chose
Le schéma est là pour une raison. Il impose une réclamation spécifique et testable ainsi qu'une définition claire de ce qui est terminé. Un agent qui doit rédiger une preuve observable ne peut pas se rabattre sur « cela semble risqué ».
Reproductible ou ça n'a pas eu lieu
Une règle compte plus que toute autre. Un candidat n'est pas une découverte tant qu'il n'y a pas d'artefact autonome qui reproduit l'échec sur le vrai code, et qui s'exécute pour quelqu'un qui ne l'a pas écrit.
Le reproducteur ne lit pas le compte-rendu, et il se moque de l'assurance avec laquelle le modèle s'est exprimé. Soit il s'exécute, soit il ne s'exécute pas.
L'essentiel de sa valeur réside dans les faux positifs qu'il détecte. Trois d'entre eux reviennent sans cesse, et chacun d'eux correspond à un agent qui obtient un laissez-passer pour la mauvaise raison :
- Une panique qui ne se produit que dans une version de débogage. Compilez-le et exécutez-le de la manière dont le logiciel est réellement livré, et la valeur boucle simplement. Rien ne plante. Cela ressemble à un plantage, mais ce n'en est pas un.
- Un reproducteur qui construit une valeur interne à la main, une valeur qu'aucune entrée réelle ne pourrait jamais produire, car chaque chemin contrôlé par un attaquant la rejette plus tôt. Le bug ne se « reproduit » que sur une fonction que rien d'accessible n'appelle de cette façon.
- Dans le travail de vérification formelle, une preuve qui aboutit mais qui ne signifie pas ce que vous vouliez. L'énoncé est trivialement vrai indépendamment de ce que fait le code, ou il est plus faible que la propriété que vous vouliez capturer. Le vérificateur est satisfait, mais le théorème ne contraint pas le comportement qui vous importait réellement.
Rien de tout cela n'est nouveau. C'est la même chose qu'un test qui réussit parce qu'il ne vérifie en fait rien. Ce qui est nouveau, c'est le volume. Un agent écrit la version inutile aussi vite que la vraie, et avec autant d'assurance. La vérification doit donc être automatique. Vous ne pouvez pas compter sur l'agent pour se corriger lui-même.
Le rapport signal/bruit représente l'essentiel du travail
La plupart des candidats sont erronés, en double ou hors de portée. Ce n'est pas un problème avec la méthode ; c'est ainsi qu'elle fonctionne. L'objectif est de rejeter rapidement les mauvais et d'étayer les vrais avec des preuves difficiles à contester.
Chaque candidat qui survit fait l'objet de deux vérifications indépendantes. Un véritable attaquant peut-il réellement l'atteindre dans une configuration normale ? Et que coûte-t-il à l'attaquant de le réaliser, par rapport à ce qu'il en coûte au réseau s'il réussit ? Un bug que n'importe quel pair individuel peut déclencher est très différent d'un bug qui nécessite un accès spécial ou une énorme quantité de ressources.
Tout est vérifié par rapport à une liste actualisée de ce qui est déjà connu, corrigé ou rejeté. Sans cela, les agents continuent de redécouvrir le même problème fermé et de le signaler encore et encore.
Les taux d'acceptation varient beaucoup d'une cible à l'autre, et cette variation est utile en soi. Exécutez ceci sur un code mature et fortement audité et presque rien ne survit, ce qui vaut quand même la peine d'être su. « Nous avons cherché attentivement et n'avons rien trouvé » est un vrai résultat. Exécutez-le sur un code moins exploré, ou sur un code formellement vérifié, où une preuve vérifiée par machine couvre un modèle et où le bytecode déployé est seulement supposé y correspondre, et davantage de choses passent.
Nous ne sommes pas les seuls à avoir constaté que le tri est la partie difficile. La principale conclusion de Cloudflare était qu'une portée étroite vaut mieux qu'une analyse large. L'agent de tests basés sur les propriétés d'Anthropic a généré quelque chose comme un millier de rapports candidats, puis a utilisé un classement et un examen par des experts pour se réduire à un niveau supérieur qui a tenu la route environ 86 % du temps. La génération était la partie facile. Je ne vais pas publier nos propres chiffres ici ; liés à une cible spécifique, ils en diraient plus sur la cible que sur la méthode.
Ce pour quoi les agents sont doués, et là où ils induisent en erreur
Il y a de l'engouement dans les deux sens, voici donc une liste simple de ce que les agents font bien et là où ils induisent en erreur.
| Doués pour | Trompeurs pour |
|---|---|
| Lire la spécification et le code ensemble | Les chaînes d'appels qui semblent accessibles mais ne le sont pas |
| Énoncer et vérifier un véritable invariant | Contourner la vérification de succès (une réussite pour la mauvaise raison). |
| Rédiger un reproducteur à partir d'une idée d'une ligne | Gonfler la gravité pour correspondre au ton dramatique du compte-rendu |
| Suggérer une cause profonde avant que vous n'ayez regardé | Les bugs qui s'étendent sur une séquence d'étapes valides |
La répartition n'est même pas constante d'une tâche à l'autre. Stanislav Fort, en testant une gamme de modèles sur de vraies vulnérabilités, appelle cela une frontière irrégulière (jagged frontier), où un modèle qui récupère une chaîne d'exploitation complète sur une base de code peut échouer au traçage de base du flux de données sur une autre. Vous ne pouvez pas supposer qu'un bon résultat signifie que le suivant tiendra la route, ce qui est une autre raison pour laquelle chaque candidat est vérifié individuellement.
La dernière ligne est la plus importante. Une session d'agent unique est douée pour le raisonnement ponctuel et mauvaise pour les bugs qui s'étendent sur une séquence d'étapes, où chaque étape est valide et où seul l'ordre est incorrect. Pour ceux-là, l'agent n'est pas l'outil de recherche. Son travail consiste à suggérer quelles séquences valent la peine d'être exécutées via un harnais de test avec état. Utilisé de cette façon, il fonctionne bien. Utilisé en remplacement du harnais, il passe à côté des bugs les plus coûteux qui soient, ceux qui n'apparaissent qu'à travers une séquence.
Rester honnête
Quelques habitudes font l'essentiel du travail pour rendre les découvertes des agents dignes de confiance, et aucune d'entre elles n'est compliquée.
- La provenance de chaque artefact : ce qui l'a produit, avec quel contexte, sur quelle révision. Une découverte doit être quelque chose que vous pouvez réexécuter des mois plus tard.
- Le déterminisme là où ça compte : un environnement, une façon de construire et d'exécuter, de sorte que « se reproduit » signifie la même chose sur chaque machine, et pas seulement sur celle où il a été trouvé.
- Des normes, pas des scripts : dites aux agents ce qui compte, les invariants et le niveau d'exigence pour une vraie découverte, au lieu d'une procédure numérotée. Les agents trop scriptés se brisent de la même manière que les tests trop spécifiés, ils continuent de suivre les étapes après que celles-ci ont cessé d'avoir du sens. Une étude des fichiers de contexte de dépôt a révélé la même chose : les exigences supplémentaires ont réduit le succès des tâches et augmenté les coûts de plus de 20 %, et les auteurs recommandent de limiter le contexte aux exigences minimales.
- Une personne prend la décision finale : les agents suggèrent. Ils ne décident pas de ce qui est réel, de ce qui est un doublon d'un problème connu, ou de ce qui est divulgué et quand.
Le goulot d'étranglement s'est déplacé
L'IA n'a pas remplacé le chercheur en sécurité. Elle a déplacé le travail. Le temps qui était auparavant consacré à l'élaboration et à la poursuite d'hypothèses est désormais consacré à leur évaluation à grande échelle, y compris la construction de l'oracle, l'exécution du tri, la tenue de la liste des problèmes connus et la gestion de la divulgation.
Le goulot d'étranglement n'a pas disparu. Il est passé de la recherche de bugs à la confiance dans les résultats, ce qui est une meilleure place pour lui, car c'est là que le jugement humain compte vraiment. Mais cela reste un goulot d'étranglement, et l'ignorer est la façon dont vous finissez par livrer un faux « tout va bien ».
Les pratiques qui font que cela fonctionne ne sont pas nouvelles. Les échecs reproductibles, les vrais oracles et le tri minutieux sont les mêmes pratiques qui ont fait passer le fuzzing d'un sujet de recherche à une pratique standard au cours des quinze dernières années. Les outils sont nouveaux. Les pratiques ne le sont pas.
La vitesse à laquelle les outils continuent de changer est une question ouverte. Nicholas Carlini, prudent et autrefois sceptique lui-même, soutient que le cas exponentiel mérite d'être pris au sérieux, même s'il maintient de larges marges d'erreur à ce sujet. Si le côté génération grimpe aussi vite, le côté jugement doit grimper avec lui, sinon l'écart entre ce qui est produit et ce qui est réellement vérifié ne fera que se creuser.
Pour les systèmes dont dépend Ethereum, c'est la partie qui compte. Les agents nous permettent de couvrir beaucoup plus de terrain que nous ne pourrions le faire à la main. En échange, ils exigent un jugement plus attentif, sur une pile beaucoup plus importante de réclamations qui semblent sûres d'elles. C'est un échange qui en vaut la peine, tant que vous vous souvenez que le jugement est le véritable produit.