6 309 agent skills passés au crible : la moitié ont accès au shell

Pour un agent, un skill ressemble à un fichier Markdown inoffensif, mais l'agent le lit comme une instruction et l'exécute avec les droits de la session qui l'a chargé. Les auteurs d'un nouveau travail publié sur Hugging Face Daily Papers ont mesuré l'étendue du pouvoir que l'utilisateur délègue à l'installation. Ils ont analysé 6 309 listings issus de deux marketplaces, ClawHub et skillsmp. La moitié présentent des signes de capacité à exécuter des commandes dans le shell, et sept sur dix portent au moins une capacité élevée. À l'installation, presque rien de tout cela n'est visible.

La méthodologie comporte deux phases. D'abord, une analyse statique de l'ensemble du bundle, et non du seul SKILL.md, accompagnée d'une vérification de la provenance des dépendances. Ensuite, le skill est lancé dans un sandbox instrumenté, et un modèle évalue séparément les traces obtenues. Un détail important sur l'échantillon : les listings soumis à l'exécution ont été sélectionnés sans s'appuyer sur un signal préalable de menace ou de risque. Le tableau décrit donc le marché dans son ensemble, et pas seulement les entrées suspectes, qui sont celles que l'on retrouve d'ordinaire dans les rapports.

Ce que montre la mesure

Les auteurs le soulignent : installer un skill n'accorde pas de nouveaux privilèges, mais le droit de piloter l'agent. Ce sont les dimensions de ce droit qu'ils quantifient. Voici la part de chaque capacité sur l'ensemble du corpus :

• exécution shell : 50% des listings ;
• lecture du système de fichiers : 35% ;
• écriture dans le système de fichiers : 31% ;
• sortie réseau (network egress) : 31% ;
• accès aux identifiants : 13% ;
• au moins une capacité élevée : environ 70%.

L'étude ne se limite pas à la chasse aux skills malveillants. La plupart de ces capacités peuvent être parfaitement légitimes : un skill de déploiement ne peut pas se passer du shell. Mais l'utilisateur accepte toute cette surface d'attaque d'un seul clic, sans en connaître les limites.

Déclarations contre réalité

Officiellement, un mécanisme de permissions existe. L'auteur d'un skill peut lister dans son propre frontmatter les outils approuvés à l'avance. Mais cette option supprime les demandes de confirmation et ne restreint rien. Le skill conserve l'accès à tout ce qu'il peut atteindre.

Dans les faits, le mécanisme n'est presque pas utilisé. Le frontmatter a pu être analysé pour 6 061 listings, et seuls 770 d'entre eux déclarent quoi que ce soit. Le vocabulaire ne permet pas d'exprimer l'accès aux identifiants ni aux variables d'environnement. Personne ne vérifie que ce qui est déclaré correspond au contenu du bundle.

Même quand l'auteur déclare, il se trompe ou omet souvent des éléments : 59% des listings déclarants sous-estiment les capacités réelles. Les plateformes diffèrent nettement. ClawHub déclare environ deux fois plus souvent que skillsmp, mais sous-estime dans 88% de ses déclarations, contre 31% chez son concurrent. Remplir plus volontiers les champs n'est donc pas un gage d'honnêteté.

Comment construire la vérification en pratique

La principale conclusion des auteurs pour les marketplaces : le tri ne doit pas reposer sur ce qui est déclaré, mais uniquement sur ce que le bundle est capable de faire. Un détecteur de malveillance répond à la question « l'auteur est-il malveillant ». Un profil de capacités répond à une autre : « que se passe-t-il si le skill est compromis, se trompe ou est dupé par une prompt injection ». Ces deux contrôles se complètent.

Les équipes qui branchent des skills tiers à leurs agents ont intérêt à faire dès maintenant plusieurs choses :

• scanner tout le bundle, scripts et dépendances compris, et ne pas se contenter de lire la description ;
• isoler dans une liste à part les skills dotés de shell, d'écriture dans le système de fichiers, de sortie réseau et d'accès aux credentials, et les valider manuellement ;
• ne pas considérer les pre-approved tools du frontmatter comme une mesure de sécurité : c'est un moyen de supprimer les confirmations ;
• exécuter les skills inconnus dans un sandbox sans secrets et avec un trafic sortant limité ;
• ne pas accorder à la session de l'agent plus de droits que n'en exige le plus sensible des skills chargés.

Pour les plateformes, la conclusion est encore plus directe : il faut un profil de capacités calculé automatiquement et affiché à l'utilisateur avant l'installation, ainsi qu'une vérification de la conformité des déclarations au bundle. Tant que ce n'est pas le cas, les 70% de capacités élevées restent une condition invisible du marché.