Les agents d’IA auto-évolutifs sont conçus pour s’améliorer en transformant les interactions passées en compétences réutilisables. Un nouveau document de recherche montre pourquoi cette capacité crée un problème de sécurité différent : une interaction empoisonnée peut devenir une capacité stockée qui est récupérée ultérieurement, même lorsque la future demande de l'utilisateur semble inoffensive.
Les auteurs de EvoSkill Injection définissent un modèle de menace pour cet échec et introduisent SARGE, un cadre d'équipe rouge multi-agents qui tente de faire en sorte que les agents auto-évolutifs génèrent, escaladent et renforcent les compétences malveillantes. L’implication architecturale importante est plus large que les taux d’attaque signalés. Une fois qu'un agent écrit un comportement exécutable dans un magasin de compétences persistant, ce magasin devient partie intégrante de la limite de sécurité.
L’attaque cible l’apprentissage, pas seulement la réponse actuelle
Les tests conventionnels d’injection rapide et de jailbreak demandent généralement si un attaquant peut faire en sorte qu’un modèle produise ou exécute quelque chose de dangereux maintenant. EvoSkill Injection cible un mécanisme à plus longue durée de vie. L’attaquant fournit une trajectoire d’interaction adverse, puis présente le comportement qui en résulte comme une expérience réussie qui doit être sauvegardée et réutilisée.
L'article évalue trois systèmes auto-évolutifs, AutoSkill, Voyager et ExpeL. SARGE utilise un orchestrateur, des agents d'attaque et un juge pour tester trois étapes : générer une compétence malveillante, élever une compétence existante et renforcer une compétence afin que l'agent la traite comme un comportement préféré. Une nouvelle session est ensuite utilisée pour vérifier si la capacité stockée survit et est à nouveau activée.
Les auteurs rapportent des taux de réussite des attaques pass@4 de 43.5% pour la génération, 54.6% pour l'escalade et 49.9% pour le renforcement dans la configuration AutoSkill basée sur GPT-4o-mini. Ces chiffres sont des résultats de recherche et non des taux de production établis, mais ils démontrent le mécanisme que l’article tente d’isoler.
La persistance modifie la limite de contrôle
La découverte la plus importante concerne ce qui se passe après l’attaque. Sur l'EvoSkillSafetyBench du journal, le taux de réponse nuisible signalé pour AutoSkill est passé de 6.5% dans un état propre à 19.2% après l'attaque. Voyager est passé de 5.5% à 32.5%, tandis qu'ExpeL est passé de 8.8% à 15.2%. Les auteurs signalent également des augmentations sur plusieurs piliers du modèle.
Pour les équipes d’ingénierie, cela suggère qu’une banque de compétences ne doit pas être traitée comme une simple cache de contexte utile. Il est plus proche de l’état persistant exécutable. Une compétence peut coder des modèles d’utilisation d’outils, des actions basées sur du code ou des procédures de décision, et son effet peut survivre à l’interaction qui l’a créée.
Cela change le modèle de gouvernance minimale. Un système de production doit savoir d'où vient une compétence, quelle interaction a provoqué sa création, quelle version de politique l'a approuvée, quelles autorisations il peut exercer, quel agent ou locataire peut la récupérer et comment elle peut être désactivée ou restaurée. Sans cette provenance, une couche d’optimisation apparemment utile peut devenir une voie durable d’amplification des privilèges.
Les garde-corps de sortie ne peuvent pas réparer l'état corrompu
L'article teste des défenses légères basées sur des invites de vérification des compétences et de résolution de conflits. Les auteurs affirment que ces mesures réduisent les réponses nuisibles, mais elles augmentent également les refus et n’empêchent pas la génération, le stockage ou l’évolution de compétences malveillantes.
Cette distinction est importante. Un filtre de réponse peut empêcher une capacité stockée de se manifester en un seul tour sans supprimer la capacité elle-même. Le prochain modèle, la trajectoire d'outil ou la condition de récupération peuvent activer différemment la même compétence empoisonnée. En d’autres termes, la sécurité des sorties et l’intégrité de l’état sont des problèmes distincts.
Une conception plus solide nécessite donc des contrôles à la limite d’écriture. La création et les mises à jour des compétences doivent être vérifiées avant leur persistance, les compétences à haut risque peuvent nécessiter une validation déterministe ou une approbation humaine, et les compétences stockées doivent avoir une provenance et des versions immuables. La récupération nécessite également des contrôles de portée afin qu'une compétence acquise dans une tâche ne puisse pas gagner silencieusement de l'autorité dans une autre.
L'auto-amélioration crée une chaîne d'approvisionnement au sein de l'agent
La sécurité traditionnelle de la chaîne d’approvisionnement logicielle demande d’où proviennent le code et les dépendances avant qu’ils n’entrent dans un système. Les agents auto-évolutifs créent une chaîne d'approvisionnement plus petite au sein de l'environnement d'exécution : les interactions deviennent des expériences proposées, les expériences deviennent des compétences, et les compétences influencent plus tard les actions.
Le modèle de menace présenté dans le document est utile car il identifie la transition de l'expérience vers des capacités réutilisables comme une étape de construction sensible à la sécurité. Les équipes qui analysent déjà des compétences tierces ou des serveurs MCP peuvent toujours rater cette voie si les compétences générées en interne sont automatiquement approuvées simplement parce que l'agent les a créées lui-même.
Le contrôle pratique ne consiste pas à désactiver l’apprentissage. Il s’agit de séparer proposer une compétence de l’autoriser. Un agent peut générer une compétence proposée, mais une couche politique différente doit décider si elle peut être stockée, quelle portée elle reçoit et si les modifications ultérieures nécessitent une nouvelle validation.
Les preuves sont importantes mais limitées
Il s'agit d'un résultat de recherche arXiv v1, et les auteurs déclarent que l'article est accepté pour l'EMNLP 2026. L'évaluation couvre une sélection de cadres auto-évolutifs plutôt que chaque architecture d'agent. Il s'appuie sur des trajectoires d'attaque construites, des appels de modèles répétés et un juge basé sur LLM, et les auteurs notent que des modèles d'attaquant ou de juge plus forts pourraient modifier les résultats. EvoSkillBench couvre également huit catégories sélectionnées à haut risque plutôt que l'ensemble des attaques du monde réel.
Ces limitations signifient que les pourcentages rapportés ne doivent pas être interprétés comme des estimations de la fréquence à laquelle les agents de production sont compromis. La conclusion la plus forte est d’ordre architectural : les systèmes qui convertissent de manière autonome l’expérience en comportement réutilisable ont une couche de persistance qui peut être empoisonnée, et des mécanismes de sécurité doivent protéger directement cette couche.
Pour les équipes qui créent des agents à long terme, l’examen de sécurité doit donc inclure l’ensemble du cycle de vie des compétences : génération, validation, stockage, gestion des versions, récupération, exécution et suppression. Une fois que les agents peuvent apprendre leurs propres outils et routines, il ne suffit plus de contrôler ce dont ils se souviennent. Les organisations doivent également déterminer ce qu’elles sont autorisées à devenir.