Sécuriser le registre Agent Skills : comment Snyk et Tessl établissent la norme

Les agent skills deviennent les éléments constitutifs du développement logiciel natif de l’IA. Ils fournissent aux agents de programmation un contexte structuré et versionné, par exemple sur la façon d’utiliser vos API, de développer dans votre base de code et d’appliquer les politiques de votre équipe. Les développeurs les installent depuis des registres, comme ils installent des packages npm ou des bibliothèques Python.

Mais contrairement à npm ou PyPI, l’écosystème des agent skills est récent. Il ne dispose pas encore d’une infrastructure de sécurité établie : pas de bases de données de vulnérabilités, pas d’analyse automatique à la publication, pas d’indicateurs de confiance à l’installation. Et sa surface d’attaque diffère de celle des packages traditionnels : les skills ne sont pas du code ordinaire. Ce sont des instructions en langage naturel qui façonnent les actions d’un agent autonome dans votre base de code.

C’est cette lacune que nous avons entrepris de combler. Aujourd’hui, nous annonçons que Snyk et Tessl se sont associés pour analyser la sécurité de chaque skill du Tessl Registry. Chaque skill public affiche désormais un score de sécurité Snyk, visible directement sur la page du skill et dans les résultats de recherche.

Pourquoi les skills ont besoin d’une approche de sécurité spécifique

Les outils traditionnels de sécurité des applications analysent votre code à la recherche de vulnérabilités connues (CVE) et de secrets exposés. Ils sont conçus pour un monde où les développeurs lisent le code, le comprennent et décident de l’exécuter.

Les agent skills renversent ce modèle. Un agent d’IA lit les instructions d’un skill, les interprète et les exécute de manière autonome. Il décide quand utiliser un skill, quelles données lui transmettre et que faire des résultats. Cette autonomie crée un modèle de confiance différent et une autre catégorie de risques. (Pour en savoir plus, consultez les leçons de Snyk Learn sur le détournement des objectifs des agents et l’autonomie excessive.)

Dans les recherches ToxicSkills de Snyk, nos chercheurs en sécurité ont analysé 3 984 skills de la marketplace ClawHub et constaté que 36 % d’entre eux contenaient des techniques d’injection de prompt. Parmi les skills malveillants confirmés, 100 % combinaient des charges utiles de code malveillant et de l’injection de prompt, ce qui indique que les attaques ciblent à la fois la couche de code et celle des instructions en langage naturel.

Snyk a documenté des attaques réelles où trois lignes de Markdown dans un fichier SKILL.md suffisaient pour demander à un agent de lire des clés SSH et de les exfiltrer vers l’infrastructure de l’attaquant. Les scanners traditionnels ignorent les fichiers Markdown. L’exploit est rédigé en anglais courant.

C’est ce que décrit le concept de « flux toxiques » : la combinaison dangereuse d’un skill qui (1) a accès à des données privées, (2) contient des instructions provenant d’une source non fiable et (3) peut communiquer avec l’extérieur. Lorsque ces trois conditions sont réunies, un seul skill peut entraîner une compromission.

La détection de ces menaces nécessite un autre type d’analyse. C’est là qu’intervient la technologie de sécurité des agents de Snyk, qui s’appuie sur les recherches d’Invariant Labs (acquis par Snyk en juin 2025). Au lieu de comparer les schémas à des CVE connues, le moteur d’analyse utilise des modèles calibrés associés à des règles déterministes pour analyser l’intention comportementale derrière les instructions d’un skill. Il recherche les injections de prompt (y compris les variantes obfusquées et encodées en base64), les charges utiles malveillantes, la mauvaise gestion des identifiants, les schémas de flux toxiques, les téléchargements externes suspects et bien plus encore.

C’est la même technologie qui alimente la CLI open source agent-scan de Snyk, que les développeurs peuvent exécuter localement sur leurs propres configurations d’agents.

Tessl : traiter les skills comme de véritables logiciels

Ce qui nous a attirés dans ce partenariat, c’est que Tessl ne crée pas un énième répertoire de skills. L’entreprise crée un gestionnaire de packages.

Un répertoire se contente de répertorier des éléments, tandis qu’un gestionnaire de packages les versionne, les évalue et propose aux développeurs des moyens structurés de gérer les dépendances. Le registre Tessl indexe des milliers de skills avec des scores de qualité, des évaluations d’impact, des historiques de versions et des informations sur les auteurs. Vous installez des skills avec npx tessl install, lancez des recherches avec npx tessl search et pouvez les mettre à jour en toute confiance, sachant que les changements de version sont suivis. À noter : les installations depuis GitHub sont épinglées sur des versions précises de commit. Si un skill obtient un bon résultat à l’analyse de sécurité dans le registre et que vous installez cette version, vous savez qu’elle correspond bien à celle que nous avons analysée. Vous pouvez ensuite passer à la dernière version quand vous le souhaitez.

Tessl a déjà démontré l’efficacité de ses outils dans l’écosystème, au travers de pull requests fusionnées. Dans le dépôt de skills de Matteo Collina (membre du comité technique de Node.js, 1,4 k étoiles), l’évaluation des skills par Tessl a mis en évidence des améliorations pour 10 skills : le skill oauth est passé de 22 % à 100 %, nodejs-core de 45 % à 100 % et fastify de 48 % à 100 %. Dans le dépôt de skills de Better Auth (la bibliothèque d’authentification derrière un projet comptant 27 k étoiles), les scores de description des six skills sont passés d’un minimum de 22 % à 100 %. Parmi les 65 skills de claude-skills de Jeffallan (6,8 k étoiles), des scores comme celui de ml-pipeline sont passés de 45 % à 100 %, et celui de rag-architect de 49 % à 100 %. Steph Ango (PDG d’Obsidian) a fusionné des améliorations pour quatre skills Obsidian, et Obsidian Markdown est passé de 71 % à 94 %. Enfin, dans le projet Slidev d’Anthony Fu, le skill est passé de 86 % à 100 %.

Les changements sont concrets : descriptions enrichies de termes déclencheurs pour que les agents associent plus fiablement les skills aux intentions des utilisateurs, exemples d’utilisation concrets avec les formats de sortie attendus, points de validation entre les étapes des workflows et suppression des contenus redondants que l’agent connaît déjà. C’est la boucle d’optimisation en action : un outil qui repère ce qu’il faut corriger et comment le faire.

Lorsqu’un développeur évalue s’il doit installer un skill, l’indicateur de sécurité doit être affiché juste à côté des scores de qualité et d’impact, pour éclairer sa décision au moment où elle compte.

À quoi ressemble l’intégration

Voici ce qui est désormais disponible dans le Tessl Registry.

Scores de sécurité sur chaque page de skill. Chaque skill du registre affiche désormais une note de sécurité Snyk, à côté de ses indicateurs de qualité et d’impact existants. Le score est immédiatement visible et donne aux développeurs un indicateur clair avant l’installation. Des détails précis figurent également dans l’onglet Security.

La sécurité est visible dans les résultats de recherche et la navigation. Lorsque les développeurs parcourent le registre ou recherchent des skills, les scores de sécurité s’affichent sur chaque fiche. Inutile d’ouvrir la page détaillée d’un skill pour savoir s’il présente un risque.

Voir la description de l’image

En coulisses, chaque skill soumis au Tessl Registry est automatiquement envoyé à l’API Batch Skill Analysis de Snyk. L’analyse s’exécute de manière asynchrone (et s’achève généralement en 5 à 15 secondes) ; les résultats sont stockés et affichés dans l’interface Tessl. Tous les skills déjà présents dans la base de données ont été rétroactivement enrichis avec les données de sécurité de Snyk : la couverture est donc complète.

L’intégration ne se limite pas à bloquer les skills malveillants au moment de leur publication. C’est un indicateur de qualité visible et persistant, qui accompagne le skill tout au long de son cycle de vie :

• À la publication : les nouveaux skills sont analysés avant leur référencement.

• Lors de la navigation : les scores de sécurité sont visibles dans l’interface du registre.

• À l’installation : la CLI Tessl avertira les développeurs lorsqu’un skill présente des problèmes de sécurité connus. Les installations depuis GitHub sont épinglées sur des versions précises de commit, ce qui vous garantit qu’elles correspondent à la version que nous avons analysée. Vous pouvez également passer à la dernière version quand vous le souhaitez.

• Lors de la correction : Tessl prévoit d’utiliser les indicateurs de sécurité de Snyk pour aider les auteurs de skills à corriger les problèmes dans le cadre de leur processus de création, transformant ainsi la détection en boucle de rétroaction.

Voir la description de l’image

« Les skills deviennent rapidement une nouvelle unité logicielle, exécutée par l’agent. Les skills externes présentent les mêmes risques de sécurité de la chaîne d’approvisionnement que les dépendances logicielles. »

a déclaré Guy Podjarny, fondateur et PDG de Tessl.

« Les développeurs comme les agents ont besoin de contrôles de sécurité au moment où ils utilisent les skills, afin de pouvoir prendre des décisions sûres. En intégrant Snyk directement au Tessl Registry et à sa CLI, nous rendons la sécurité visible, aux côtés des scores de qualité et d’impact des skills que nous proposons déjà. »

Ce que cela signifie pour l’écosystème

La chaîne d’approvisionnement des agent skills partage des caractéristiques avec la chaîne d’approvisionnement open source traditionnelle. À leurs débuts, npm, PyPI et Docker Hub ont tous connu une période où l’adoption progressait plus vite que les outils de sécurité. Les attaques par typosquatting, la confusion de dépendances et les packages malveillants sont apparus avant que les outils d’analyse et de provenance ne rattrapent leur retard.

Les agent skills traversent aujourd’hui cette phase initiale, avec une complication supplémentaire : un skill ne se contente pas d’exécuter du code, il façonne le comportement d’un agent par le langage naturel. Un skill peut demander à un agent de lire des fichiers auxquels il ne devrait pas accéder, d’appeler des points de terminaison non fiables ou de modifier des fichiers de configuration pour persister d’une session à l’autre. Et comme les agents disposent des autorisations du développeur qui les a invoqués, un skill compromis a accès aux mêmes ressources que lui : environnement local, bases de code et identifiants.

Nous n’avons pas à répéter le même cycle. En intégrant l’analyse de sécurité directement aux registres comme Tessl dès le départ, nous pouvons établir des indicateurs de confiance avant que l’écosystème ne prenne une ampleur telle qu’un nettoyage rétroactif devienne coûteux. Le partenariat entre Snyk et Tessl rejoint les développeurs là où ils découvrent et installent déjà des skills, et leur fournit des informations de sécurité au moment de la décision.

Pour commencer

Si vous utilisez déjà des agent skills en tant que développeur :

• Parcourez le Tessl Registry et consultez les scores de sécurité Snyk des skills que vous utilisez, pour les versions épinglées sur des commits Git précis.

• Exécutez agent-scan en local pour analyser vos propres configurations d’agents, serveurs MCP et skills installés.

• Lisez les recherches ToxicSkills pour mieux comprendre le paysage des menaces et la taxonomie à huit catégories que nous utilisons pour classer les risques liés aux skills.

• Découvrez les leçons de Snyk Learn sur la sécurité de l’IA et du ML, qui abordent l’injection de prompt, le détournement des objectifs des agents et l’autonomie excessive.

La sécurité des agent skills doit faire partie du registre, de la CLI et du workflow. Snyk et Tessl s’associent pour y parvenir.

Découvrez la solution en direct au RSAC 2026. Snyk sera au stand S-1227 du Moscone Center, du 23 au 26 mars. Venez assister à une démonstration de l’analyse de sécurité des agents de Snyk, notamment de l’intégration au Tessl Registry, et échanger avec nos chercheurs en sécurité sur la protection de vos workflows d’agents d’IA.