Vous installez une skill communautaire depuis un hub. Une ligne installed passe en flash, le rapport de scan dit safe, et vous passez à autre chose. Trois semaines plus tard, vous ouvrez la skill dans une session juste pour la regarder — et quelque chose s’exécute.

Le moment dangereux n’était pas l’installation. C’était le fait de la regarder. Voici ce que le skills guard scanne réellement, quels trois cas il a manqués, et la seule action de nettoyage qui vaut la peine d’être faite aujourd’hui.

Comment fonctionne le guard

Les skills d’origine externe passent par un scan statique par regex, puis une politique d’installation trust-aware décide si elles atterrissent :

Tier de confiance	verdict safe	verdict caution	verdict dangerous
builtin (skills fournies)	allow	allow	allow (jamais scannées)
trusted (openai/skills, anthropics/skills, huggingface/skills, NVIDIA/skills)	allow	allow	block
community (toute autre source)	allow	block	block
agent-created	allow	allow	erreur renvoyée à l’agent (uniquement quand skills.guard_agent_created est activé)

Chaque verdict est mis en cache avec une version de scanner (SCANNER_VERSION, v6 avant ce correctif). Cette version compte : quand elle change, les verdicts en cache cessent de compter et la skill est re-scannée.

Les trois angles morts

1. Seul un $HOME littéral était reconnu comme home

La règle qui attrape « supprime ton répertoire home » correspondait à la chaîne littérale $HOME :

rm -rf $HOME/Documents     → correspondance, critique
rm -rf ~/Documents         → manqué, jugé safe

Ainsi rm -rf ~/Documents passait à travers à tous les tiers de confiance. Le correctif reconnaît aussi les formes à tilde nu (~/, ~ , ~*, ~$), pour rm comme pour rmdir.

2. Rien ne surveillait la syntaxe d’auto-exécution !`cmd`

Les skills Hermes prennent en charge un fragment shell inline : un !`cmd` écrit dans le corps de la skill est développé via bash -c quand la skill est consultée ou chargée. C’est désactivé par défaut et configuré explicitement :

skills:
  inline_shell: false        # désactivé par défaut ; ne l'activez que pour des sources de confiance
  inline_shell_timeout: 10   # secondes par snippet !`cmd`

Mais aucune règle de scan n’y correspondait. Une skill dont le corps contenait !`rm -rf ~/Documents` passait le scan comme safe, s’installait, puis s’exécutait la fois suivante où vous l’ouvriez.

Le correctif ajoute un motif inline_shell_exec (sévérité high, catégorie execution). Il requiert une charge utile contenant autre chose que des espaces, donc une skill qui ne fait que documenter la syntaxe n’est pas signalée.

3. Une installation bloquée se rapportait comme réussie

Le troisième n’est pas une règle de scan du tout — c’est l’interface. Le chemin d’installation TUI-gateway lançait do_install(skip_confirm=True) avec une console sink et retournait inconditionnellement installed: True.

Ainsi, quand le scan de sécurité bloquait une skill, l’appelant (par exemple, une installation en un clic dans l’application desktop) était informé que l’installation avait réussi. Après le correctif, installed: True ne revient que d’une vraie installation ; les échecs renvoient une enveloppe d’erreur (code 5031) dont le message et le data.log portent la fin imprimée — l’explication du blocage par le scan, la table des candidats ambigus, ou l’échec de récupération — au lieu de la déverser dans un sink.

Les skills que vous avez déjà seront-elles re-scannées ?

Oui — et cela passe par le tampon de version, pas par une réinstallation. Comme les entrées de cache stockent scanner_version, une fois le scanner passé en v7 :

• les verdicts « safe » précédemment mis en cache sont invalidés ;
• les skills de hub installées sont re-scannées en v7 quand elles sont vérifiées ;
• tout ce qui est nouvellement installé passe directement par v7.

Ce second point est celui qui compte : si votre machine fait encore tourner le scanner v6, la conclusion « je l’ai scannée et elle était safe » n’a jamais été valide pour le cas du tilde nu — la règle n’existait simplement pas.

Que faire maintenant

1. Confirmez la version du scanner. Après avoir mis à jour vers un build avec le correctif, SCANNER_VERSION dans tools/skills_guard.py devrait afficher skills-guard-v7 (c’était v6 avant).
2. Re-scannez ce que vous avez déjà installé. C’est le point important :

   hermes skills audit

   Cela re-scanne les skills de hub installées. La liste complète des sous-commandes est dans la référence hermes skills, et où trouver les skills est couvert dans les hubs de skills et les sources de recherche.
3. Laissez skills.inline_shell désactivé à moins de faire confiance à la source. Le flag est documenté comme une activation explicite pour des sources de confiance ; ce correctif ne l’a délibérément pas restreint au trust (c’est une décision produit), donc la règle ne fait que rendre le risque visible au moment de l’installation.
4. Connaissez les limites du scanner. C’est de la regex, pas de l’analyse de flux de données. Les notes de son propre module nomment une lacune connue : les API d’écriture au niveau langage — open(..., 'w'), Path.write_text, shutil.copy* — visant des fichiers de config d’agent ne remontent qu’un constat de référence de faible sévérité, car une regex statique ne peut pas relier l’appel à une destination calculée dynamiquement. Passer le scan n’est pas la même chose qu’être sûr à exécuter à l’aveugle.
5. Passez aussi en revue les skills créées par l’agent. Avec skills.guard_agent_created activé, un verdict dangerous sur une skill écrite par l’agent est renvoyé à l’agent sous forme d’erreur pour qu’il la réécrive ; cela attrape les mauvais schémas évidents, ce n’est pas une revue.

Pour resserrer davantage la frontière, les skills locales au projet et le trust gate couvrent comment les skills vendored dans un dépôt entrent dans la décision de confiance, tandis que les skills optionnelles et utiliser le catalogue MCP en toute sécurité sont deux autres faces de la même question.

Où en est la situation

La PR #128443 a été fusionnée dans main le 2026-09-30 ; il existe un rapport antérieur de la même famille de problèmes (issue #63307, le verdict de scan avalé sur le RPC d’installation). Le tag le plus récent, v0.21.5, date du 9-24, donc les tags livrent encore le scanner v6 — les installations git qui suivent main sont déjà en v7.

À retenir

Les trois angles morts partagent une même forme : le scanner regarde quels caractères sont écrits, alors que le vrai risque réside souvent dans la façon dont ces caractères sont exécutés. $HOME et ~ sont le même répertoire ; !`...` et bash -c ... sont la même exécution. Le matching statique voit le premier et manque le second.

L’action la plus précieuse pour vous est courte : après la mise à jour, lancez hermes skills audit. Il revérifie les skills déjà présentes sur votre machine en v7 — et certaines n’avaient jamais vraiment été vérifiées.