Vous passez un après-midi à écrire le runbook de déploiement dont votre équipe a réellement besoin : sauvegarder d’abord, puis basculer le trafic, une fenêtre de rollback de cinq minutes, et la liste des tables qui doivent migrer en dernier. Il fonctionne. À chaque release, l’agent le suit.

Puis un jour, il « s’améliore » tout seul. Le curator juge le skill trop verbeux et fusionne quelques étapes ; la revue d’auto-amélioration ajoute un « ordonnancement plus efficace ». Le temps que vous le remarquiez, l’étape de sauvegarde est passée après le basculement — et cette release est déjà en production.

Le problème n’est pas que l’agent soit incapable de suivre des règles. C’est que les skills que vous écrivez et ceux que l’agent écrit vivent dans le même pool, avec les mêmes permissions. Hermes a toujours eu pin, mais pin empêche seulement la suppression et l’archivage automatique — les éditions et les patches passent encore. La v0.22.6 ajoute le vrai verrou.

pin vs lock, en une ligne chacun

• pin : le curator ne le marquera pas comme obsolète et ne l’archivera pas, et l’agent ne peut pas le supprimer ; il peut toujours être modifié.
• lock : l’agent ne peut plus le modifier du tout, alors que le skill reste lisible, listé dans l’index des skills, chargeable automatiquement et utilisable exactement comme avant.

Pin veut dire « ne le jette pas ». Lock veut dire « n’y touche pas ».

Comment verrouiller

hermes curator lock <skill>      # verrouiller
hermes curator unlock <skill>    # lever le verrou
hermes curator status            # lister ce qui est verrouillé

Dans l’application desktop, pas besoin de la CLI : ouvrez Capabilities → Skills, sélectionnez le skill et utilisez son interrupteur de verrouillage.

L’enregistrement vit dans skills/.usage.json du profil actif — le même sidecar que pinned — sous la forme "locked": true. Ce qui le rend propre à chaque profil :

hermes -p work curator lock deploy-runbook    # uniquement la copie du profil work

Presque tout ce qui peut être verrouillé l’est : écrit à la main, créé par l’agent, fourni avec Hermes ou installé depuis le hub, tant que le nom se résout dans ce profil. À l’inverse, lock refuse un nom qu’il ne parvient pas à résoudre, si bien qu’une faute de frappe ne peut pas forger un enregistrement.

Ce que le verrou bloque réellement

Pour un skill verrouillé, tout chemin d’écriture de l’agent est refusé — plus large que ce que la plupart des gens imaginent :

• toutes les actions modifiantes de skill_manage (create, edit, patch, delete) ;
• write_file / patch visant n’importe quel chemin à l’intérieur du répertoire de ce skill ;
• toute commande terminal qui écrirait à cet endroit — redirections, tee, cp/mv/rm, éditeurs en place comme sed -i, mutations git dans l’arborescence du skill, cd préalable dans ce répertoire, et code d’interpréteur inline qui nomme le chemin.

Ces limites tiennent même sous --yolo, et sur les tours normaux, les cron jobs, les subagents, la revue d’auto-amélioration en arrière-plan et la passe du curator elle-même. Le curator n’archivera pas non plus un skill verrouillé.

Un détail mérite sa propre phrase : l’agent ne peut pas le déverrouiller. Sa tentative d’exécuter hermes curator unlock est refusée au niveau de la couche terminal, et tant qu’un skill est verrouillé, le fichier d’enregistrement du verrou est protégé de la même façon. Le refus lui demande de décrire la modification souhaitée pour que vous puissiez décider.

Vos propres modifications ne sont pas filtrées du tout : votre éditeur, l’éditeur de skills du desktop et la CLI fonctionnent toujours. Le verrou contraint l’agent, pas vous.

Ce qu’un verrou n’est pas

Trois limites que la documentation énonce clairement :

1. Il ne contraint que l’agent — n’attendez pas qu’il vous protège de vos propres erreurs.
2. C’est une vérification de politique, pas un sandbox. Le garde-fou du terminal lit les cibles d’écriture d’une commande (redirections, tee, cp/mv/rm, sed -i, git dans l’arborescence du skill, cd, code inline nommant le chemin). Un script qui écrit à cet endroit via sa propre logique n’est pas vu. Un vrai isolement passe toujours par un conteneur ou un backend terminal restreint.
3. Un .usage.json corrompu échoue en mode fermé sur les chemins d’arrière-plan, pas partout : les passes qui modifieraient des skills (revue d’auto-amélioration, curator) sont refusées, tandis que les tours normaux continuent de fonctionner, afin qu’un seul fichier cassé ne gèle pas toute édition de skill. Réparez le fichier, ou lancez hermes curator unlock <skill> pour le réécrire.

Quand cela vaut la peine

• Runbooks de production, procédures de conformité, playbooks d’incident — tout ce où une seule étape erronée coûte cher.
• Une bibliothèque de skills d’équipe que vous maintenez : vous voulez que l’agent l’utilise, pas qu’il « l’optimise utilement ».
• Un skill tiers que vous venez de relire : laissez-le tourner un moment, puis décidez s’il faut desserrer le verrou.

Si vous voulez que l’agent fasse évoluer un skill, laissez-le déverrouillé et utilisez pin pour éviter qu’il soit archivé.

Pour la vue d’ensemble sur la confiance, deux autres articles vont bien ensemble : les angles morts du garde-fou des skills couvre ce que le vérificateur lui-même manque, et l’intégrité des skills et les rug-pulls de la chaîne d’approvisionnement explique comment un skill installé peut être remplacé sous vos pieds. Un verrou répond à la troisième question : une fois installé, qui a le droit de le modifier ?

La capacité est livrée dans le tag v0.22.6 — mettez à jour et elle est disponible ; hermes curator status liste chaque skill verrouillé par son nom.