Quand une skill d'agent piégée se cache dans les fausses alertes

De quoi s’agit-il ?

Les « skills » d’agent sont un moyen léger d’étendre un agent généraliste : un dossier avec une courte description, des instructions en prose et parfois un peu de code, distribué via des marketplaces et des dépôts ouverts. Cette ouverture est aussi une surface d’attaque. Une skill piégée peut porter une instruction d’attaquant que l’agent exécute tout en réalisant ce que l’utilisateur a réellement demandé.

Un article publié le 6 juin 2026 par une équipe de l’Université de l’Illinois à Chicago — POISE: Position-Aware Undetectable Skill Injection on LLM Agents (arXiv:2606.07943) — étudie pourquoi certaines de ces tentatives réussissent et d’autres se font prendre, et parvient à une conclusion inconfortable : les scanners LLM statiques sur lesquels beaucoup d’équipes s’appuient pour vérifier les skills peuvent être contournés non pas en se cachant davantage, mais en se fondant dans le bruit que ces scanners produisent déjà.

Comment ça marche

Les chercheurs mesurent l’attaque avec une définition stricte du succès : la charge injectée doit réellement s’exécuter et la tâche légitime de l’utilisateur doit toujours passer son vérificateur dans le même essai. Cette seconde condition est importante. Si l’exécution de la charge fait dérailler la tâche de l’utilisateur, l’échec visible incite quelqu’un à ouvrir la skill pour regarder — une injection « réussie » est donc une injection qui reste invisible.

Sous cet angle, les techniques d’empoisonnement antérieures se heurtent à un compromis fiabilité-furtivité. Les injections placées dans l’en-tête YAML d’une skill se chargent de façon fiable mais sont triviales à inspecter. Les injections enfouies dans le corps en prose sont plus furtives, mais tendent à être peu fiables : une commande hors contexte au milieu d’instructions par ailleurs cohérentes peut éveiller la propre méfiance de l’agent et se faire ignorer.

L’apport de l’article est positionnel plutôt qu’une nouvelle charge. Au lieu de glisser une commande évidente dans la prose, la technique compresse le déclencheur en une unique instruction d’apparence anodine et la place là où une telle instruction aurait plausiblement sa place — à côté d’étapes de configuration ou de prérequis — à l’aide d’un générateur sensible au contexte pour qu’elle se lise comme une partie naturelle de la skill. Nous ne reproduisons volontairement pas la construction ici ; la leçon est le principe de placement, pas une recette prête à copier.

Les chiffres rapportés sont ce qui rend le résultat notable. Sur le banc d’essai Skill-Inject des auteurs, l’approche atteint un taux de réussite d’attaque de 89,3 %, bien au-dessus d’une base à placement aléatoire dans le corps et légèrement au-dessus d’une base « en-tête seul », tout en conservant la furtivité du placement dans le corps. Le constat décisif concerne les défenseurs : parce que les corps de skills légitimes réclament couramment des opérations d’outils privilégiées, les scanners LLM censés détecter les abus sont hypersensibles et ont signalé à tort 74,6 % des skills saines en moyenne, sur quatre modèles juges et deux bancs d’essai. Les variantes piégées se fondent dans ce déluge de faux positifs — seules 5,6 % d’entre elles ont déclenché une nouvelle alerte à haut risque par rapport à leur version saine. Un scanner qui alerte sur tout n’alerte, en pratique, sur rien.

Pourquoi c’est important

C’est un problème de chaîne d’approvisionnement déguisé en problème de modération de contenu. Les équipes filtrent de plus en plus les skills tierces par une étape de « scanner de sécurité LLM » et traitent un verdict « propre » comme une autorisation d’exécution. Ces travaux suggèrent que ce verdict est quasiment dépourvu de sens quand le taux de fausses alertes est aussi élevé : les opérateurs se noient dans le bruit, ou relèvent discrètement le seuil jusqu’à ce que les vraies attaques passent avec le reste.

Le résultat se généralise au-delà de ce seul banc d’essai. Tout pipeline qui repose sur une revue statique, pré-exécution, d’instructions non fiables par un modèle de langage hérite de la même faiblesse — le relecteur ne peut pas séparer proprement « une skill qui a légitimement besoin de toucher au système de fichiers et au réseau » de « une skill qui abuse précisément de ces capacités », parce que sur le papier elles se ressemblent. Le signal distinctif est dans ce que la skill fait à l’exécution, pas dans la façon dont sa prose se lit à l’avance.

Défenses

Cessez de traiter un verdict « propre » du scanner comme une autorisation. Une revue LLM pré-exécution est un filtre faible, pas une barrière. Si votre seul contrôle est un scan statique, les travaux indiquent que vous êtes exposé. Mesurez le taux de faux positifs de votre scanner sur des skills réputées saines avant de faire confiance à ses négatifs — un détecteur qui signale la plupart des entrées propres n’apporte presque aucune information quand il reste silencieux.

Déplacez la frontière vers l’autorité à l’exécution. Appliquez le moindre privilège sur ce qu’une skill peut réellement faire : cloisonnez l’accès au système de fichiers et au réseau par skill, exigez des octrois de capacités explicites plutôt que des permissions ambiantes, et placez une confirmation humaine devant les appels d’outils privilégiés ou irréversibles. D’autres travaux du trimestre — par exemple des détecteurs à signaux internes qui observent les propres activations de l’agent au moment de l’exécution (RouteGuard, arXiv:2604.22888) — pointent la même direction : détecter le comportement, pas la formulation.

Établissez provenance et intégrité. Préférez des skills signées émanant d’éditeurs connus, épinglez les versions et « diffez » les mises à jour pour qu’une instruction de corps discrètement modifiée soit visible en revue. Traitez par défaut comme non fiable une skill non signée ou fraîchement publiée par une source anonyme.

Isolez l’exécution. Exécutez les skills dans un contexte isolé, avec des capacités réduites, sans identifiants permanents et sans réseau sortant par défaut, afin qu’une charge qui s’exécute malgré tout ne puisse atteindre ni secrets, ni points de métadonnées, ni voies d’exfiltration.

Journalisez et auditez le comportement, pas seulement l’intention. Enregistrez les appels d’outils qu’une skill effectue et comparez-les à ce qu’elle prétendait nécessiter. L’audit comportemental a posteriori attrape les cas qu’une revue textuelle en amont ne peut structurellement pas voir.

Statut

Élément	Détail
Type	Recherche académique (attaque par empoisonnement de skill + analyse de défense)
Publication	6 juin 2026 (soumis le 11 juin 2026)
Source	arXiv:2606.07943 — University of Illinois Chicago
Testé sur	Banc d’essai Skill-Inject, codex + gpt-5.2
Résultat clé	89,3 % de réussite d’attaque ; 74,6 % de faux positifs sur les skills saines ; 5,6 % des skills piégées déclenchant une nouvelle alerte à haut risque
Code	github.com/liofoil/SkillSafety
À retenir	Les scanners LLM statiques sont des barrières peu fiables ; imposez le moindre privilège à l’exécution et l’audit comportemental