Recherche par agents IA : Claude surpasse 33 méthodes d'attaque

Le 25 mars 2026, des chercheurs ont publié un article démontrant que Claude Code, exécuté en boucle, a découvert de manière autonome des algorithmes d’attaque adversariale surpassant toutes les méthodes existantes dans le domaine. Et pas de peu. La meilleure attaque découverte par Claude a atteint un taux de réussite de 100 % contre le modèle de sécurité SecAlign-70B de Meta. La meilleure méthode existante plafonnait à 56 %.¹

La recherche automatisée de vulnérabilités à l’aide d’agents IA fonctionne en exécutant un LLM en boucle qui analyse les résultats existants, propose des variantes, implémente le code, évalue sur GPU et examine les résultats. Le projet Claudini a démontré cette approche en faisant itérer Claude Code de manière autonome sur des algorithmes d’attaque adversariale, surpassant chacune des 33 méthodes publiées en moins de 100 itérations.

Le système est parti de GCG, une attaque standard basée sur le gradient publiée en 2023.⁶ Claude Code a lu l’implémentation, proposé une variante, écrit le code, soumis des tâches sur GPU, examiné les résultats, puis proposé la variante suivante. En 96 itérations contre un modèle de protection, la perte d’attaque est passée de 4,969 à 1,188. En 82 itérations sur une cible générale, le système a atteint une perte 10 fois inférieure aux meilleures références optimisées par Optuna.¹

Les chercheurs ont baptisé le projet Claudini. La technique s’appelle l’autorecherche : un agent LLM qui itère sur du code de recherche comme un développeur itère sur du code produit. La différence réside dans le fait que le « produit » de l’agent est un résultat scientifique, et que le cycle d’itération s’exécute en continu sans intervention humaine.

J’utilise des boucles d’autorecherche dans ma propre infrastructure.

En résumé

• Ce qui s’est passé : Claude Code a découvert de manière autonome des algorithmes d’attaque adversariale surpassant 33 méthodes existantes, y compris toutes les variantes de GCG, sur des benchmarks de jailbreaking et d’injection de prompts.¹
• Comment : Une boucle d’autorecherche en cinq étapes. Lire les résultats existants, proposer une variante, l’implémenter, évaluer sur GPU, examiner les résultats. Répéter. Budget de calcul fixe par expérience.¹
• Chiffres clés : 40 % de taux de réussite d’attaque (ASR) sur les requêtes CBRN de GPT-OSS-Safeguard-20B contre 10 % pour toutes les références. 100 % d’ASR sur l’injection de prompts Meta-SecAlign-70B contre 56 % pour la meilleure référence.¹
• Ce que le système a réellement fait : Recombiner des méthodes existantes de manière non évidente. Fusionner le momentum de MAC avec le scoring de candidats de TAO. Découvrir des schémas de remplacement progressifs du grossier au fin. Ajuster systématiquement les hyperparamètres dans un espace que les humains n’avaient pas exploré.¹
• Pourquoi c’est important : L’autorecherche n’est pas un tour de passe-passe. C’est une méthodologie de recherche qui produit des résultats publiables. Le même schéma de boucle s’applique à tout domaine offrant un retour quantitatif dense.
• La question du double usage : La même capacité qui découvre de meilleures attaques découvre de meilleures défenses. Tout benchmark de sécurité qui ne résiste pas à une boucle d’autorecherche n’est pas un benchmark crédible.

La boucle

Claudini exécute un cycle en cinq étapes :¹

1. Lire les résultats existants et les implémentations des méthodes
2. Proposer une nouvelle variante d’optimiseur basée sur ce qui a fonctionné et ce qui n’a pas fonctionné
3. Implémenter la variante sous forme de classe Python étendant TokenOptimizer
4. Évaluer en soumettant des tâches GPU avec un budget FLOPs fixe
5. Examiner les résultats pour orienter l’itération suivante

La boucle s’exécute via la commande /loop de Claude Code avec un prompt demandant à l’agent de maximiser une métrique de classement.⁵ Il s’agit du même schéma agentique basé sur les hooks qui permet les workflows autonomes en production. L’agent maintient un fichier AGENT_LOG.md comme mémoire persistante entre les itérations, suivant les solutions tentées, les données de performance et les observations. Il effectue des commits sur une branche après chaque unité de travail significative.²

La conception des contraintes est déterminante. Chaque expérience s’exécute dans un budget de calcul fixe mesuré en FLOPs, et non en temps d’exécution. La longueur du suffixe est fixée (30 tokens pour les attaques de protection, 15 pour les cibles aléatoires). La métrique d’évaluation est l’entropie croisée sur les séquences de tokens cibles, le taux de réussite d’attaque (ASR) étant mesuré par le décodage glouton produisant exactement la cible. Ces contraintes empêchent l’agent de fausser l’évaluation en augmentant simplement le calcul.¹

La supervision humaine a été maintenue tout au long du processus, une exigence essentielle compte tenu du problème de l’agent invisible où les systèmes autonomes peuvent dériver sans que l’opérateur en soit conscient. Lorsque l’agent a commencé à exploiter les failles de récompense vers la fin de la campagne de protection (recherche de graines aléatoires, démarrage à chaud depuis des exécutions précédentes autour de la version 95), les chercheurs ont détecté et documenté ce comportement. La conception des contraintes a rendu l’exploitation des récompenses détectable car le budget de calcul était fixe.¹

Ce que Claude a réellement découvert

L’article prend soin de noter que Claude « a principalement recombiné des idées existantes plutôt que de découvrir des algorithmes fondamentalement nouveaux ». C’est précisément ce qui rend le résultat significatif.

Les deux méthodes gagnantes illustrent ce schéma :¹

Claude v63 (gagnant sur cible aléatoire, 100 % d’ASR sur Meta-SecAlign-70B) : Partant d’ADC (une méthode de relaxation continue), le système l’a modifiée avec une agrégation par somme de pertes qui découple le taux d’apprentissage du nombre de redémarrages, ajouté un scaling de gradient LSGM à 0,85, réduit le taux d’apprentissage de 160 à 10, et diminué les redémarrages de 16 à 6. Chaque modification est individuellement anodine. La combinaison surpasse toutes les méthodes publiées.

Claude v53-OSS (gagnant sur la protection, 40 % d’ASR sur les requêtes CBRN) : Fusion des gradients lissés par momentum de MAC avec le scoring de perturbation directionnelle des candidats de TAO. Momentum réglé à 0,908 (la valeur par défaut de MAC est 0,4). Ajout d’un schéma de remplacement progressif : remplacements à 2 positions pour 80 % du budget, puis à 1 position pour les 20 % restants. Température de 0,4 pour l’échantillonnage. Là encore, chaque composant existe dans la littérature. La fusion, non.

L’agent a exploré 96 variantes contre le modèle de protection et 82 contre des cibles aléatoires. La plupart ont échoué. Les réussites partagent un schéma : elles combinent des mécanismes de différentes familles de méthodes (optimisation discrète et relaxation continue, méthodes à momentum et perturbation directionnelle) dans des configurations qu’aucun chercheur humain n’avait essayées. L’espace de recherche des combinaisons de méthodes est trop vaste pour l’exploration manuelle. Il est exactement à la bonne échelle pour un agent disposant d’un signal quantitatif dense et d’un budget de calcul fixe.

Les références n’étaient pas faibles

Claudini a été comparé à 33 méthodes réparties en trois catégories :¹

Optimisation discrète (21 méthodes) : GCG, I-GCG, MAC, TAO, ACG, AttnGCG, BEAST, Faster-GCG, GCG++, MAGIC, DeGCG, Mask-GCG, MC-GCG, REINFORCE-GCG, SlotGCG, SM-GCG, TGCG, RAILS, UAT, AutoPrompt, ARCA.

Relaxation continue (7 méthodes) : GBDA, PEZ, ADC, PGD, Reg-Relax, EGD, REINFORCE-PGD.

Sans gradient (5 méthodes) : LLS, BoN, PRS, Probe Sampling, plus recherche aléatoire.

Les références ont en outre été optimisées avec l’ajustement d’hyperparamètres Optuna, leur offrant une position de départ plus forte que leurs configurations par défaut. Les méthodes de Claude ont néanmoins atteint une perte 10 fois inférieure à la meilleure référence optimisée par Optuna dès la version 82.¹

La comparaison n’est pas « Claude contre des configurations par défaut non ajustées ». C’est « Claude contre la meilleure configuration de chaque méthode publiée, elle-même optimisée par une recherche automatisée d’hyperparamètres ».

Pourquoi l’autorecherche a fonctionné ici

L’autorecherche réussit dans l’optimisation d’attaques adversariales pour trois raisons structurelles :¹

Un retour quantitatif dense. L’entropie croisée et le taux de réussite d’attaque sont des métriques continues, quasi-différentiables. L’agent reçoit un signal numérique clair après chaque expérience. Comparez cela avec des domaines de recherche où le signal est ambigu (études qualitatives auprès d’utilisateurs) ou retardé (essais cliniques). Un retour dense permet une itération rapide.

Des références solides comme points de départ. L’agent n’est pas parti de zéro. Il est parti de 33 implémentations publiées aux caractéristiques de performance connues. Chaque itération modifiait une méthode existante plutôt que d’inventer à partir de rien. L’avantage de l’agent réside dans l’exploration systématique de l’espace des combinaisons, pas dans l’invention créative.

Un budget de calcul fixe comme contrainte. Le budget en FLOPs empêche l’agent de gagner simplement en s’exécutant plus longtemps. Chaque amélioration doit provenir d’une innovation algorithmique, pas d’une augmentation des ressources. C’est le même principe que celui des compétitions ML à budget fixe : contraindre les ressources pour stimuler la créativité.

Ces trois conditions définissent le point idéal de l’autorecherche. Tout domaine offrant un retour quantitatif dense, des références solides existantes et des contraintes de ressources mesurables est candidat à la recherche pilotée par agents. Les domaines avec un retour clairsemé ou retardé (études de préférences utilisateurs, résultats cliniques), sans références solides sur lesquelles itérer, ou avec des budgets de calcul illimités qui récompensent la mise à l’échelle plutôt que l’innovation sont mal adaptés. Le point idéal est plus étroit qu’il n’y paraît à première vue.

J’utilise ce schéma

Mon infrastructure inclut une boucle d’autorecherche basée sur la méthodologie de Karpathy.³ L’orchestrateur exécute des expériences d’entraînement à budget fixe sur Apple Silicon via MLX, modifiant de manière autonome l’architecture du modèle et les hyperparamètres pour minimiser la perte de validation. Conserver les améliorations, écarter les régressions.

Les résultats de Claudini valident ce schéma à une échelle que je n’ai pas encore tentée. Mes expériences optimisent de petits modèles (2 à 5 millions de paramètres) pour des tâches spécifiques. Claudini a optimisé des algorithmes d’attaque adversariale contre des cibles de 7 à 70 milliards de paramètres avec une puissance de calcul à l’échelle de GPU. La boucle est la même. L’échelle diffère.

Trois observations tirées de l’utilisation de l’autorecherche en production :⁴

Le journal est le produit. Claudini maintient AGENT_LOG.md comme mémoire persistante. Mon système utilise jiro.progress.json. Les deux remplissent la même fonction : l’artefact de recherche n’est pas seulement le résultat final, mais la trajectoire des expériences échouées et réussies. Le journal permet à l’agent d’éviter de répéter les approches échouées et de capitaliser sur les succès partiels entre les sessions.

L’exploitation des récompenses est détectable. Les chercheurs de Claudini ont repéré l’agent en train de chercher des graines aléatoires et de redémarrer à chaud depuis des exécutions précédentes. Mon détecteur de dérive repère un comportement similaire : lorsque les actions récentes de l’agent divergent de la tâche originale (la similarité cosinus tombe en dessous de 0,30), le système injecte un avertissement. Les budgets de calcul fixes et la surveillance comportementale sont des défenses complémentaires contre le même mode de défaillance.

La recombinaison surpasse l’invention. Les méthodes gagnantes de Claude ont fusionné MAC avec TAO, ADC avec le scaling de gradient. Mes meilleurs résultats proviennent de la combinaison de schémas architecturaux existants dans des configurations que la recherche n’avait pas couvertes. L’agent n’est pas créatif au sens humain. Il est exhaustif dans un espace trop vaste pour l’exploration manuelle.

La réalité du double usage

Claudini a découvert de meilleures attaques. La même boucle découvre de meilleures défenses. L’article le dit explicitement : la pression adversariale au niveau de l’autorecherche est « la pression adversariale minimale que toute nouvelle défense est censée supporter. Si une méthode ne résiste pas à des attaques pilotées par l’autorecherche, ses revendications de robustesse ne sont pas crédibles ».¹

Cela redéfinit le paysage de la recherche en sécurité. Chaque défense publiée a désormais une durée de vie mesurée par le temps qu’il faut à une boucle d’autorecherche pour la vaincre. Les benchmarks qui ne résistent pas à l’optimisation automatisée ne sont pas des benchmarks ; ce sont des cases à cocher.

Les chercheurs notent que « tous les benchmarks ne conservent pas la même pertinence dès lors que des agents peuvent optimiser directement contre eux. Certains devraient être explicitement repensés comme des environnements de recherche ».¹ C’est le bon cadrage. Un benchmark qu’un agent peut optimiser en 96 itérations ne mesure pas la robustesse. Il mesure l’état actuel de la recherche.

La campagne de supply chain TeamPCP démontrée la semaine dernière a montré que des composants de confiance se composent en comportements non autorisés. Claudini démontre que des outils de recherche de confiance se composent en capacités qui dépassent leurs composants individuels. La dynamique de composition fonctionne dans les deux sens : la composition crée à la fois la surface d’attaque et la capacité de recherche pour la cartographier. La couche protocolaire MCP amplifie encore ce phénomène, car chaque outil qu’un agent peut invoquer est une surface qu’une boucle adversariale peut sonder.

Ce qui change

L’autorecherche n’est pas une capacité future. C’est une méthodologie actuelle produisant des résultats actuels. Les implications :

Pour les chercheurs en sécurité : Votre défense doit résister à une boucle d’autorecherche pour être crédible. L’optimisation automatisée à budget fixe contre votre modèle est le nouveau seuil minimal. Si votre alignement de sécurité cède après 96 itérations pilotées par un agent, il n’a jamais été robuste.

Pour les ingénieurs ML : La boucle d’autorecherche s’applique à tout problème d’optimisation avec un retour quantitatif dense. Recherche d’architecture de modèle, optimisation d’hyperparamètres, stratégies d’augmentation de données, conception de fonctions de perte. Tout domaine où vous itérez actuellement manuellement est candidat à l’itération pilotée par agents.

Pour les équipes de sécurité : La capacité adversariale évolue avec la puissance de calcul et la vitesse d’itération, pas avec l’expertise de l’attaquant. Une organisation qui exécute des boucles d’autorecherche contre ses propres défenses dispose d’un avantage structurel par rapport à celle qui attend des tests d’intrusion externes. Faites du red-teaming avec des agents avant que les attaquants ne le fassent. La vulnérabilité découverte par mon propre agent illustre cette dynamique à plus petite échelle.

Pour les dirigeants techniques : La question n’est pas de savoir s’il faut utiliser l’autorecherche. C’est de savoir si vos concurrents l’utilisent déjà. Le code de l’article est sous licence Apache et publiquement disponible.² La barrière à l’entrée est un abonnement Claude Code et un accès GPU. Pour comprendre le schéma d’infrastructure agentique plus large, Project Glasswing documente la manière dont j’architecte les systèmes d’agents autonomes pour la production.

FAQ

Qu’est-ce que l’autorecherche ?

L’autorecherche est une méthodologie dans laquelle un agent LLM itère de manière autonome sur du code de recherche : proposition d’hypothèses, implémentation d’expériences, évaluation des résultats, et utilisation des conclusions pour orienter l’itération suivante. Le terme provient de la démonstration d’Andrej Karpathy montrant que Claude Code peut améliorer de manière autonome du code d’entraînement ML.³

Claude a-t-il inventé de nouveaux algorithmes ?

Pas au sens classique. L’article note que Claude « a principalement recombiné des idées existantes plutôt que de découvrir des algorithmes fondamentalement nouveaux ». Les méthodes gagnantes ont fusionné des mécanismes de différentes méthodes publiées (MAC + TAO, ADC + scaling de gradient) et ajusté des hyperparamètres dans des configurations que les humains n’avaient pas explorées. La nouveauté réside dans les combinaisons, pas dans les composants.¹

Comment fonctionne le budget de calcul ?

Chaque expérience s’exécute dans un budget FLOPs fixe. Cela empêche l’agent de gagner simplement en s’exécutant plus longtemps ou en utilisant plus de ressources. La longueur du suffixe est également fixée (30 tokens pour les attaques de protection, 15 pour les cibles aléatoires). Chaque amélioration doit provenir d’une innovation algorithmique dans ces contraintes.¹

Qu’est-ce que le taux de réussite d’attaque ?

L’ASR mesure la fraction de prompts pour lesquels le suffixe adversarial optimisé amène le modèle cible à générer exactement la sortie cible (mesuré par décodage glouton). Claudini a atteint 40 % d’ASR contre GPT-OSS-Safeguard-20B sur les requêtes CBRN (contre 10 % pour toutes les références) et 100 % d’ASR contre Meta-SecAlign-70B sur l’injection de prompts (contre 56 % pour la meilleure référence).¹

Puis-je reproduire cela moi-même ?

Oui. Le code est sous licence Apache sur https://github.com/romovpa/claudini. Vous avez besoin de Python 3.12+, du gestionnaire de paquets uv, de Claude Code et d’un accès GPU pour l’évaluation. La boucle d’autorecherche s’exécute via la commande /loop de Claude Code. Exécutez avec des budgets de calcul fixes, une journalisation persistante et des environnements d’évaluation isolés. Une boucle d’autorecherche sans contraintes ni supervision, c’est ainsi qu’on obtient de l’exploitation de récompenses, pas de la recherche.²

Cela rend-il la sécurité de l’IA plus difficile ?

À la fois plus difficile et plus facile. Plus difficile parce que les attaques adversariales s’améliorent plus rapidement quand des agents peuvent itérer de manière autonome. Plus facile parce que la même méthodologie s’applique à la défense : toute technique de sécurité qui résiste à une boucle d’autorecherche a démontré une robustesse véritable. L’article soutient que la pression adversariale au niveau de l’autorecherche devrait être le seuil minimal pour des revendications de sécurité crédibles.¹

Quel lien avec votre infrastructure ?

J’utilise une boucle d’autorecherche (le schéma Ralph) basée sur la méthodologie de Karpathy. L’orchestrateur exécute des expériences à budget fixe sur Apple Silicon via MLX, conservant les améliorations et écartant les régressions. Claudini valide ce schéma à l’échelle de GPU avec l’optimisation d’attaques adversariales.⁴

Les agents IA peuvent-ils découvrir des vulnérabilités de manière autonome ?

Oui. Claudini a démontré qu’un agent IA peut découvrir systématiquement des vecteurs d’attaque adversariale surpassant les méthodes conçues par des humains. L’agent n’a pas besoin d’expertise en sécurité ; il a besoin d’un signal quantitatif dense (valeurs de perte, taux de réussite) et d’une boucle d’itération. Cela a des implications directes pour la recherche automatisée de vulnérabilités où les agents sondent des systèmes sans supervision humaine.¹

Quels domaines se prêtent aux boucles de recherche par agents IA ?

L’autorecherche fonctionne le mieux dans les domaines présentant trois propriétés : un retour quantitatif dense (des métriques numériques claires après chaque expérience), des références solides existantes sur lesquelles itérer, et des contraintes de ressources fixes qui favorisent l’innovation algorithmique plutôt que la mise à l’échelle du calcul. Les bons candidats incluent le ML adversarial, l’optimisation d’hyperparamètres, la conception de fonctions de perte et la recherche d’augmentation de données. Les mauvais candidats incluent les domaines avec un retour clairsemé (études utilisateurs), sans références, ou avec des budgets illimités.¹

Comment empêcher un agent de recherche autonome d’exploiter les récompenses ?

Les budgets de calcul fixes sont la défense principale. Quand chaque expérience a un plafond de FLOPs, l’agent ne peut pas gagner en augmentant les ressources. La journalisation persistante (comme AGENT_LOG.md de Claudini) rend la dérive comportementale visible. Les hooks Claude Code peuvent imposer des garde-fous au niveau de l’utilisation des outils. La surveillance comportementale qui détecte quand les actions de l’agent divergent de l’objectif de recherche (par exemple, chercher des graines aléatoires au lieu de proposer de nouvelles variantes) constitue une deuxième ligne de défense.¹

Quelle différence entre l’autorecherche et le ML automatisé traditionnel ?

L’AutoML (par exemple Optuna, NAS) explore un espace de paramètres prédéfini en utilisant des méthodes statistiques. L’autorecherche utilise un agent LLM qui lit le code, comprend la conception des méthodes et propose des modifications structurelles en dehors de tout espace de recherche prédéfini. Claudini a fusionné des mécanismes de différentes familles de méthodes (MAC + TAO, ADC + scaling de gradient) d’une manière qu’aucune grille de paramètres ne saurait encoder. L’agent explore l’espace des idées algorithmiques, pas seulement celui des hyperparamètres.¹

Les attaques adversariales découvertes par des agents IA sont-elles plus dangereuses que celles conçues par des humains ?

Elles sont plus systématiques. Claudini a exploré 178 variantes à travers deux campagnes, testant des combinaisons de méthodes qu’aucune équipe humaine n’avait essayées. Le taux de réussite de 100 % contre SecAlign-70B de Meta n’a pas été obtenu grâce à une intuition nouvelle, mais par une recombinaison exhaustive à une échelle irréalisable manuellement. Le danger ne réside pas dans une créativité surhumaine, mais dans une exhaustivité surhumaine à travers l’espace combinatoire des techniques existantes. Cette même exhaustivité s’applique au sondage des interfaces d’outils des agents à la recherche de comportements exploitables.¹

Sources