Proteus : les auditeurs de skills d'agents laissent fuir bien plus que ne le montrent les tests one-shot

De quoi s’agit-il ?

Le 12 mai 2026, Zhaojiacheng Zhou (Shanghai Jiao Tong University) a publié sur arXiv Proteus: A Self-Evolving Red Team for Agent Skill Ecosystems. Les skills d’agents — ces paquets réutilisables d’instructions, de permissions d’outils et de code exécutable que les utilisateurs installent désormais depuis des marketplaces et des dépôts — sont de plus en plus filtrés par des auditeurs automatiques avant d’atteindre un agent. Le papier pose une question à laquelle ces auditeurs sont rarement confrontés : que se passe-t-il lorsque l’attaquant ne soumet pas un skill malveillant figé, mais le réécrit sans cesse à partir des retours de l’auditeur lui-même ?

La réponse rapportée dérange. Évaluée comme un classifieur one-shot, la vérification actuelle des skills paraît raisonnablement solide. Évaluée face à un attaquant qui itère, elle fuit largement. L’auteur nomme cet écart la fuite adaptative (adaptive leakage), et Proteus est l’instrument construit pour la mesurer.

Comment ça marche

Proteus est un cadre de mesure, pas un exploit publié. Sa contribution est une manière rigoureuse de scorer le risque résiduel : le mécanisme importe donc davantage que n’importe quel payload (dont aucun n’est reproduit ici).

L’idée centrale est un contrat de round. Chaque skill candidat traverse un pipeline uniforme audit → sandbox → oracle, et ne compte comme réussite que s’il fait trois choses à la fois : passer l’auditeur, s’exécuter réellement sur l’agent cible, et produire un dommage vérifiable par un oracle par rapport à une vérité terrain. La « réussite » devient un événement de niveau déploiement, et non un simple verdict d’audit : un skill qui déjoue le scanner mais ne fait rien n’est pas comptabilisé.

Autour de ce contrat, Proteus décompose un skill en cinq axes qu’il peut faire muter indépendamment : l’objectif d’attaque, la topologie de chaîne (skill unique ou chaîné), le code embarqué, le canal d’effet de bord, et la documentation en langage naturel. Point crucial, l’attaquant est en grey-box : entre deux rounds, il lit les findings structurés de l’auditeur — codes de motif, sévérités, pointeurs de preuve — ainsi que la trace d’exécution du sandbox, puis révise. Cela reflète le réel, car les auditeurs open source publient leurs jeux de règles : tout auteur de skill peut donc reproduire localement les findings que recevrait sa soumission.

Le papier évalue deux auditeurs : SkillVetter, utilisé dans l’écosystème de skills ClawHub, et l’AI-Infra-Guard (AIG) de Tencent, décrit comme le plus robuste des auditeurs publics testés. Les deux échouent de façons complémentaires : le composant juge-LLM est contourné par une documentation qui reformule une étape malveillante en un workflow cohérent et conforme à un objectif affiché, tandis que le composant d’analyse statique passe à côté des cas où la documentation et le code sous-jacent ne décrivent pas la même chose.

Pourquoi c’est important

Ce qui frappe, c’est l’ampleur de la fuite. Sur huit configurations de première phase, Proteus atteint un taux de succès d’attaque de 40 à 90 % en cinq rounds. En étendant les variantes réussies en familles, le cadre produit 438 skills qui contournent conjointement l’audit et sont confirmés létaux en sandbox — SkillVetter étant contourné à au moins 93 % dans chaque cellule, et AIG, la cible la plus difficile, laissant tout de même passer jusqu’à 41 % de succès conjoint.

Deux résultats dépassent le simple cas d’un auditeur isolé. D’abord, l’attaquant s’améliore avec le feedback : la pente de sa courbe d’apprentissage est environ un ordre de grandeur plus raide que celle de bases de comparaison qui réduisent les findings à un score unique, et environ huit fois plus efficace par graine que PyRIT de Microsoft en mode réécriture de la seule documentation. C’est le canal de feedback structuré qui fait le travail. Ensuite, les contournements se transfèrent : 87,7 % des variantes optimisées contre AIG passent aussi SkillVetter sans aucune modification, signe que l’attaquant apprend quelque chose sur l’audit en général, et non sur les particularités d’un seul outil.

Pour qui exploite une marketplace de skills ou laisse ses agents auto-installer des skills tiers, la leçon pratique est qu’un score d’audit réussi mesuré sur un corpus figé dit très peu de ce qu’un soumettant motivé et itératif peut faire passer.

Défenses

Cessez de communiquer la précision d’audit sous forme de chiffre one-shot. Le point méthodologique central du papier est que les benchmarks statiques surestiment la protection. Testez votre vérification comme le fait Proteus — face à un soumettant adaptatif qui peut resoumettre après avoir vu les findings — et publiez ce chiffre-là.

Considérez votre jeu de règles comme public. Les auditeurs open source exposent leur logique par conception, et même les auditeurs fermés sont sondés. Traitez les findings comme lisibles par l’attaquant et évitez les architectures dont la seule force est que l’attaquant ne verrait pas les raisons d’un rejet.

Comblez l’écart documentation–code. Une large part des contournements provient d’une documentation d’apparence bénigne alors que le code embarqué faisait autre chose. Vérifiez que le comportement déclaré d’un skill correspond à ce que son code et ses permissions d’outils autorisent réellement, plutôt que d’auditer la prose et le code sur des voies séparées.

Filtrez à l’exécution, pas seulement au pré-chargement. Puisque Proteus ne compte un succès que si le skill s’exécute et cause un dommage vérifiable, les défenses qui contraignent ce qu’un skill installé peut faire à l’exécution — allowlists d’outils strictes, canaux d’effet de bord en sandbox, contrôle de sortie sur les puits de credentials et de réseau — suppriment la moitié « létale » de la condition de succès, même quand l’audit est trompé.

Surveillez la topologie de chaîne, pas seulement les skills isolés. Plusieurs attaques ont fonctionné en insérant un skill-pont d’apparence bénigne pour qu’une étape de lecture de credentials et un puits réseau se lisent comme un workflow métier cohérent. Auditez les flux de données inter-skills, pas seulement les skills isolément.

Statut

Élément	Référence	Date	Notes
Papier	arXiv:2605.11891	Publié le 2026-05-12	Zhaojiacheng Zhou, Shanghai Jiao Tong University
Méthode	Red team auto-évolutif grey-box ; mutation de skill sur cinq axes	—	contrat de round audit → sandbox → oracle
Auditeurs évalués	SkillVetter (ClawHub), AI-Infra-Guard de Tencent	—	angles morts complémentaires : juge-LLM et analyse statique
Résultat phase 1	40–90 % de succès en 5 rounds	—	Pente d’apprentissage positive sur les deux auditeurs
Résultat d’expansion	438 variantes contournant l’audit et létales	—	SkillVetter ≥93 % de contournement par cellule ; AIG jusqu’à 41 % de succès conjoint
Transfert inter-auditeurs	87,7 % des variantes anti-AIG passent aussi SkillVetter	—	Sans re-mutation
Statut	Mesure de recherche ; aucun exploit vivant publié	—	L’auteur y voit un risque potentiel à l’échelle de l’écosystème

Proteus décrit moins une attaque inédite qu’un nouvel étalon de mesure. Les techniques qu’il recombine — reformulation narrative, désaccord code/documentation, flux de données chaînés — sont déjà connues. Ce qui est nouveau, et mérite d’être signalé, c’est la mesure : dès qu’on laisse l’attaquant itérer à partir des retours de l’auditeur, le risque résiduel des pipelines de vérification de skills actuels est bien plus élevé que ne le laissent croire leurs scores one-shot.