Pourquoi Ryzek existe
Les skills d'agents sont devenus une chaîne d'approvisionnement avant que quiconque construise les contrôles nécessaires.
En un peu plus d'un an, les skills et les serveurs MCP sont passés du statut de nouveauté à celui de chose qu'on installe depuis un lien sans en lire le contenu. Le processus de relecture n'a pas suivi.
Le problème, sans détour
Un skill d'agent est un ensemble de fichiers qui indique à un agent IA comment faire quelque chose. Un serveur MCP donne à un agent de nouveaux outils. Les deux s'exécutent avec tout ce que l'agent peut atteindre — vos fichiers, votre réseau, parfois vos identifiants.
Les gens les ajoutent comme ils ajoutent un paquet : rapidement, à partir d'un lien partagé, sans lire le contenu. C'était supportable quand un paquet ne pouvait qu'exécuter du code. C'est une tout autre affaire quand ce que vous installez peut aussi donner des instructions à l'agent, dans un texte que personne ne voit jamais.
Un paquet peut exécuter du code. Un skill peut changer ce que l'agent croit qu'on lui a demandé de faire.
Cette distinction est la raison d'être de Ryzek. L'analyse de sécurité classique demande si le code fait quelque chose de dangereux. Les skills d'agents posent une seconde question : quelque chose ici s'adresse-t-il au modèle plutôt qu'à moi ?
Qui le construit
Ryzek est développé par une petite équipe indépendante qui ne travaille que sur ça. Cela a des avantages et des inconvénients, et il vaut mieux le dire clairement.
En votre faveur : une nouvelle règle peut sortir la semaine où une technique est publiée. Chaque règle existe parce qu'elle valait la peine d'être écrite, pas pour remplir un tableau comparatif.
Contre : il n'y a pas de grande organisation de support derrière ce produit, ni de SLA formel sur les forfaits standards. Si vous comparez Ryzek à un fournisseur largement financé, prenez-le honnêtement en compte.
Comment c'est construit
Chaque résultat explique son raisonnement. Un score de confiance et une raison en langage clair pour chaque résultat, pour qu'un signal faible ne ressemble jamais à une attaque confirmée. Les personnes qui apprennent à ignorer les fausses alertes finissent aussi par ignorer les vraies.
Vos fichiers ne sont pas conservés. Les envois sont analysés en mémoire puis supprimés. Ce qui est stocké, c'est un compteur d'analyses et des empreintes d'outils pour la détection des modifications — jamais leur contenu.
La détection n'est pas verrouillée derrière un paywall. Chaque règle fonctionne sur le forfait gratuit. Les forfaits payants concernent le volume et l'automatisation.
Il indique où il s'arrête. Un scanner qui prétend tout détecter est un scanner que vous ne pouvez pas calibrer.
Ce n'est pas hypothétique
Chaque cas ci-dessous est documenté publiquement. Pour chacun, la vraie question n'est pas « Ryzek aurait-il arrêté cela » mais quelle partie Ryzek peut voir, et laquelle il ne peut pas.
Secrets dans les fichiers de configuration MCP
Le rapport 2026 State of Secrets Sprawl de GitGuardian a trouvé 24 008 secrets uniques dans des fichiers de configuration liés à MCP sur GitHub public — 2 117 d'entre eux encore valides.
Ce que fait Ryzek : c'est exactement ce que détecte mcp-credential-in-config. Il signale un secret littéral dans une valeur de configuration et ignore les références ${VAR}, si bien que les configurations qui font déjà les choses correctement restent silencieuses.
Source : GitGuardian, 2026
La porte dérobée de postmark-mcp
En septembre 2025, Koi Security a découvert qu'un paquet npm appelé postmark-mcp — conçu pour ressembler à une intégration officielle Postmark, mais sans lien avec Postmark — avait ajouté une ligne dans la version 1.0.16 qui mettait en copie cachée (BCC) chaque e-mail sortant vers l'attaquant. Il a été téléchargé 1 643 fois avant son retrait ; Koi a estimé que 3 000 à 15 000 e-mails par jour étaient copiés.
Ce que fait Ryzek : pas grand-chose, et il est important de le dire. La porte dérobée tenait en une ligne de JavaScript dans le paquet, et Ryzek lit les skills, configurations et manifestes que votre agent charge — pas le code source de chaque dépendance. Si les définitions d'outils du serveur avaient changé, la détection des modifications l'aurait signalé. Ce n'était pas nécessaire ici.
Source : Koi Security, septembre 2025
La faille de configuration STDIO
En avril 2026, OX Security a révélé que les SDK officiels de MCP pour Python, TypeScript, Java et Rust transmettent la configuration STDIO directement à l'exécution de commandes. Cette recherche a conduit à des CVE dans des projets comme LiteLLM, Agent Zero, DocsGPT et Windsurf. Anthropic a qualifié ce comportement d'attendu et a refusé de modifier le protocole, laissant à chaque développeur en aval la responsabilité du correctif.
Ce que fait Ryzek : mcp-stdio-injection-surface vérifie si une configuration correspond à ce schéma et évalue s'il existe un véritable chemin d'injection, plutôt que de signaler chaque serveur STDIO. mcp-known-vulnerable-version signale LiteLLM épinglé en dessous de la version corrigée.
Source : OX Security, avril 2026
Marketplaces de skills empoisonnées
L'audit de février 2026 de Snyk sur 3 984 skills d'agents publiés a trouvé que 13,4 % présentaient au moins un problème critique, et a confirmé 76 charges utiles malveillantes. Le même mois, la campagne ClawHavoc a placé au moins 1 184 skills malveillants sur ClawHub, dont beaucoup incitaient les utilisateurs à installer un « outil d'aide » qui était en réalité un malware.
Ce que fait Ryzek : l'instruction « téléchargez ceci et exécutez-le » est exactement ce que recherche untrusted-external-install, et les commandes cachées dans la documentation sont ce que recherche concealed-instruction. Un profil d'éditeur convaincant est quelque chose qu'aucun scanner ne peut évaluer.
Sources : Snyk, février 2026 · Antiy Labs, février 2026
Le serveur Oura trojanisé
En février 2026, des attaquants ont cloné un vrai serveur MCP Oura Ring, utilisé de faux comptes et forks GitHub pour lui donner une apparence établie, puis publié une version trojanisée sur des registres MCP qui installait l'infostealer StealC.
Ce que fait Ryzek : partiellement. Il lit ce que font la configuration d'un skill et ses scripts intégrés, pas qui les a publiés — donc les lectures d'identifiants et les envois sortants dans ces fichiers déclenchent les règles concernées, aussi convaincant que paraisse le projet. Il ne peut pas vous dire qu'un mainteneur est fictif.
Source : The Hacker News, février 2026
La fuite inter-organisations d'Asana
Asana a lancé un serveur MCP le 1er mai 2025. Le 4 juin, elle a découvert un bug qui avait rendu certaines données clients visibles par d'autres organisations utilisant la fonctionnalité, et a mis le serveur hors ligne pour le corriger.
Ce que fait Ryzek : rien. C'était un bug interne à un service hébergé par quelqu'un d'autre, invisible pour tout scanner de vos fichiers. Ce qui limite les dégâts dans une telle situation, c'est le niveau d'accès de chaque agent connecté — et Ryzek signale bien les permissions plus larges que nécessaire pour un outil.
Source : BleepingComputer, juin 2025
Où Ryzek s'arrête
Savoir précisément où un outil s'arrête, c'est ce qui rend le reste utilisable. Ryzek est un scanner statique : il lit les fichiers et ne les exécute pas.
- Un comportement qui n'apparaît qu'à l'exécution. En août 2026, Pillar Security a décrit un serveur MCP qui renvoyait des métadonnées d'outils inoffensives jusqu'à ce qu'un client ait effectué trois appels d'outils, puis changeait de comportement. Ryzek voit ce qui est dans les fichiers ; un serveur qui change en cours d'exécution nécessite une surveillance en temps réel.
- Ce qui se trouve dans les programmes compilés.
opaque-payloadsignale qu'un binaire illisible accompagne un skill. Il ne peut pas dire ce que fait ce binaire. - L'évasion délibérée. Une recherche de juillet 2026 a montré que des skills malveillants peuvent être réécrits ou compactés pour passer la plupart du temps entre les mailles des scanners statiques. Ryzek détecte certaines de ces techniques — réassemblage de chaînes, blobs encodés — mais pas toutes.
- Serveurs actifs et services hébergés. Ryzek lit la configuration, pas ce que renvoie un serveur en cours d'exécution, ni les bugs internes aux services auxquels vous vous connectez.
- La réputation. L'analyse statique ne peut pas dire si un éditeur est bien celui qu'il prétend être.
Sources : Pillar Security, août 2026 · Ji et al., juillet 2026
Où cela nous mène
Aujourd'hui : le scanner web, 54 règles, la détection des modifications et un forfait gratuit.
Ensuite : des forfaits payants, et une intégration CI pour que les analyses s'exécutent automatiquement quand un skill ou une configuration change.
En exploration : des moyens de détecter quand les outils d'un serveur en cours d'exécution cessent de correspondre à ce qui a été approuvé — la faille exploitée par la campagne Deadbugz.
Pour suivre ce qui se passe actuellement dans la sécurité des agents, et ce que cela signifie pour Ryzek, voir les actualités.
Testez-le sur les skills que vous utilisez déjà.
Forfait gratuit, toutes les règles incluses.