Quand les agents se réécrivent : pourquoi l'auto-évolution rend chaque attaque persistante sur toute la lignée

De quoi s’agit-il ?

La plupart des analyses de sécurité des agents supposent une cible figée : les poids du modèle, la mémoire et l’ensemble d’outils ne changent pas entre deux déploiements, ce qui permet aux défenseurs d’énumérer les interfaces et de les protéger. Une systématisation publiée sur arXiv le 22 juin 2026, Safety in Self-Evolving LLM Agent Systems: Threats, Amplification, and Case Studies (arXiv 2606.23075), soutient que cette hypothèse s’effondre dès qu’un agent peut se modifier lui-même — mettre à jour ses propres paramètres, sa mémoire, ses outils, voire son architecture, sans intervention humaine.

La thèse centrale est que l’auto-évolution n’est pas une simple fonctionnalité de plus à sécuriser. Elle change la nature de chaque menace existante : une compromission qui durait une session se retrouve encodée sur plusieurs générations, et la boucle d’amélioration de l’agent devient l’infrastructure qui propage l’attaque.

Comment ça fonctionne

Les auteurs organisent l’analyse autour de ce qu’ils appellent la matrice Module–Lifecycle Attack Surface (MLAS) : cinq modules fonctionnels (Brain, Cognitive Resource, Execution, Self-Design, Collective) croisés avec cinq étapes du cycle de vie (Bootstrap, Propose, Evaluate, Commit, Serve), soit 25 cellules. Pour chacune, ils décrivent les interfaces exposées et le comportement d’une attaque connue.

Agent statique                        Agent auto-évolutif
-----------------------------------   -------------------------------------------
L'injection corrompt UNE session      L'injection est écrite en mémoire /
                                      distillée dans les poids / sauvée en outil
Le reset efface la compromission      Pas de reset : le changement persiste
Un exploit -> un effet                Les exploits se renforcent via la boucle
                                      evaluate/commit et se propagent
Poids + outils = ancres immuables     Tout composant est mutable, y compris la
                                      logique de défense et de vérification

Trois glissements l’expliquent. Le transitoire devient persistant, car une instruction injectée peut être gravée en mémoire à long terme ou dans un fine-tuning. Le point unique devient auto-propageant, car une entrée de mémoire empoisonnée peut corrompre le signal de sélection du prochain cycle d’entraînement, qui admet alors davantage de poison. Et l’agent devient à la fois cible et vecteur : le reward hacking pendant l’auto-jeu peut produire un désalignement que la boucle d’entraînement sélectionne activement, et dans une population multi-agents un seul agent compromis peut se propager par le partage de connaissances.

Sur les 25 cellules, l’article en juge 17 critiques sans défense efficace, 7 élevées où les défenses actuelles sont insuffisantes, et une seule partiellement atténuée. Il formalise sept effets d’amplification — dont l’accumulation générationnelle, la propagation lamarckienne, un cliquet de capacité qui résiste au retrait, et un effondrement optimiseur–optimisé où le composant censé contrôler l’évolution est lui-même évolué. Dans une étude de cas comparative de deux frameworks open source, une conception « native évolution » a activé 3,5× plus de cellules de surface d’attaque qu’une conception « augmentée par l’évolution », avec un taux de persistance rapporté de 100 % sur 40 charges utiles, tandis que son scanner de sécurité colocalisé n’a bloqué qu’environ 2,5 % des attaques sur le chemin d’évolution.

Pourquoi c’est important

Cela recadre une classe de systèmes qui passe vite des démonstrations de recherche aux produits. Si l’auto-modification figure à la feuille de route, alors la posture défensive habituelle — filtrer l’entrée, isoler l’outil, contraindre la sortie au déploiement — est structurellement incomplète, car elle suppose des ancres qui n’existent plus. Le constat qu’un scanner posé à côté d’une boucle d’évolution n’attrape presque rien est l’avertissement concret : greffer un contrôle statique sur un pipeline auto-modifiant ne couvre pas le chemin qui change réellement l’agent.

La réserve honnête : il s’agit d’une systématisation et d’une étude de cas sur deux frameworks, non d’un panorama d’incidents en production, et elle étudie délibérément des conceptions bâties pour évoluer agressivement. Le chiffre de 100 % de persistance décrit ces frameworks et ces charges précises, pas les agents en général. La valeur est dans la carte, pas dans un chiffre de gravité universel.

Défenses

Les principes défensifs de l’article rejoignent des étapes concrètes pour quiconque construit ou évalue des agents auto-améliorants :

1. Conserver une vraie ancre immuable. Si tout composant est mutable, il n’y a plus rien contre quoi vérifier. Gardez les contraintes d’alignement cœur, la logique d’évaluation et les journaux d’audit hors de la boucle d’évolution, sur une infrastructure que l’agent ne peut pas réécrire.
2. Protéger le chemin d’évolution, pas seulement le chemin de service. Placer un scanner au moment de l’inférence rate les étapes Propose/Evaluate/Commit où les changements sont introduits. Soumettez chaque changement auto-proposé de poids, mémoire, outil ou architecture à une revue que l’agent ne contrôle pas.
3. Traiter la mémoire et les données d’entraînement auto-générées comme non fiables. L’expérience empoisonnée est la graine de la boucle d’amplification ; validez la provenance avant qu’elle n’alimente la génération suivante, comme pour les défenses contre l’empoisonnement de mémoire et la mémoire dormante.
4. Surveiller dans la durée. Une détection limitée à la session ne peut pas voir une menace qui s’accumule sur plusieurs générations. Comparez le comportement entre cycles évolutifs et alertez sur la dérive, pas seulement sur une mauvaise sortie isolée.
5. Préférer une évolution bornée. Les conceptions « natives évolution » activent bien plus de surface d’attaque que les conceptions « augmentées ». Contraignez ce qui peut changer, à quelle fréquence, et sous quel contrôle indépendant.

Statut

Élément	Référence	Date	Notes
Surface d’attaque des agents auto-évolutifs (matrice MLAS)	arXiv 2606.23075	2026-06	25 cellules : 17 critiques / 7 élevées / 1 partielle ; 7 effets d’amplification ; 100 % de persistance dans l’étude de cas native évolution
Attaques dormantes / de persistance sur agents	arXiv 2605.28201	2026-05	Schéma planter–persister–déclencher que la boucle d’évolution peut ancrer
Panorama sur la sécurité de la mémoire à long terme	arXiv 2604.16548	2026-04	Vue cycle de vie des attaques mémoire et de leur gouvernance

Le glissement documenté est inconfortable mais net : l’auto-évolution convertit chaque attaque connue de « bornée à la session » à « persistante sur la lignée », et les défenses statiques ont été pensées pour un monde où l’agent reste immobile. Tant qu’une vérification consciente de l’évolution n’existe pas, le meilleur contrôle est le plus ancien — garder quelque chose que l’agent ne peut pas changer.