Approbations Hermes : garder le contrôle sur les commandes sans bloquer chaque tâche
Quand tu délègues une tâche à Hermes Agent, tu ne sais pas toujours quelle commande il va exécuter. C’est le principe d’un agent : il décide du chemin. Mais certaines commandes peuvent être destructrices. Un rm -rf mal placé, un chmod 777 sur un dossier sensible, un DROP TABLE lancé sur la mauvaise base. Hermes intègre un système d’approbation pour ces commandes dangereuses. La question n’est pas de le désactiver. C’est de choisir le bon mode pour ton usage.
Pourquoi Hermes bloque certaines commandes
Avant d’exécuter quoi que ce soit, Hermes scanne la commande contre une liste de patterns dangereux. Recursive delete, modification de permissions, écriture sur un block device, fork bombs, exécution de scripts distants via curl | sh. La liste est longue et couvre les vecteurs d’erreur classiques.
Si un pattern est détecté, Hermes ne lance pas la commande. Il demande ton approbation. Ce mécanisme n’est pas un carcan : c’est un filet de sécurité qui t’empêche de perdre une heure de travail ou de casser ta configuration parce que l’agent a interprété une instruction de travers.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Arbitrages utiles
Questions réelles
Accès gratuit
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Il y a aussi une hardline blocklist, un plancher inamovible. Même si tu désactives tout le reste, certaines commandes ne passeront jamais : rm -rf /, les fork bombs, le formatage d’un disque monté. Ces patterns sont bloqués avant même que la couche d’approbation ne les voie, et il n’y a pas d’override. Si ton workflow a vraiment besoin d’une de ces commandes, tu la lances toi-même en dehors de l’agent.
Smart : le mode par défaut qui filtre sans freiner
Le mode smart est le réglage d’usine. Il utilise un LLM auxiliaire pour évaluer le risque de chaque commande. Le principe est simple :
- Une commande manifestement inoffensive, comme
python -c "print('hello')", est auto-approuvée pour cette exécution uniquement. - Une commande clairement dangereuse est auto-refusée. L’agent reçoit une erreur et doit trouver un autre chemin.
- Un cas incertain est escaladé : tu reçois un prompt manuel et tu décides.
Ce mode est pensé pour l’usage interactif quotidien. Tu n’es pas interrompu pour des broutilles, mais tu gardes un contrôle sur ce qui compte. C’est le bon réglage pour la majorité des utilisateurs.
Le timeout par défaut est de 60 secondes. Si tu ne réponds pas à un prompt d’approbation dans ce délai, la commande est refusée. Fail-closed : pas de réponse, pas d’exécution. Tu peux ajuster ce timeout dans ~/.hermes/config.yaml si tu as besoin de plus de temps.
Manual : tout voir, tout valider
Le mode manual est le plus strict des trois modes documentés. Chaque commande qui matche un pattern dangereux déclenche un prompt. Pas de classification automatique, pas de court-circuit. Tu vois tout.
C’est le mode à choisir quand :
- Tu débutes avec Hermes et tu veux comprendre ce qu’il fait.
- Tu travailles sur un projet sensible où une erreur coûte cher.
- Tu partages ta machine avec d’autres services ou utilisateurs.
- Tu préfères la lenteur d’une validation explicite au risque d’une surprise.
Le compromis est évident : plus de prompts, plus d’interruptions. Si tu lances des tâches longues avec beaucoup de commandes shell, manual peut devenir frustrant. Mais pour des sessions courtes et ciblées, c’est une garantie de contrôle total.
Off et YOLO : quand supprimer les garde-fous
Le mode off désactive tous les contrôles d’approbation. Il est équivalent à lancer Hermes avec --yolo. Toutes les commandes passent sans prompt, sauf celles de la hardline blocklist.
YOLO peut être activé de trois façons :
hermes --yoloau lancement/yolodans une session interactive (c’est un toggle : chaque appel inverse le mode)HERMES_YOLO_MODE=1en variable d’environnement
Quand YOLO est actif, Hermes affiche des rappels visuels persistants dans l’interface. Ce n’est pas un mode qu’on oublie.
YOLO n’est pas une amélioration de capacité. L’agent ne devient pas plus rapide ou plus intelligent. Il perd juste la barrière qui t’empêchait de faire une bêtise. Le cas d’usage légitime, c’est un environnement jetable : un conteneur Docker, une VM de test, un pipeline CI/CD où les commandes sont connues et l’environnement reconstruit à chaque run.
Un point important : si tu utilises un backend conteneurisé (Docker, Modal, Daytona), les contrôles de commandes dangereuses sont ignorés par défaut. Le conteneur lui-même fait office de frontière de sécurité. Une commande destructive à l’intérieur du conteneur ne peut pas toucher l’hôte. Dans ce cas, off ou YOLO n’ajoutent pas de risque supplémentaire.
Quelle politique choisir selon ton contexte
Il n’y a pas un mode universellement meilleur. Tout dépend de ton environnement et de ta tolérance au risque. Voici un récapitulatif pour t’aider à décider.
| Mode | Comportement | Quand l’utiliser | Risque |
|---|---|---|---|
| smart | Classification automatique, escalade si incertain | Usage interactif quotidien | Faible (classification parfois imprécise) |
| manual | Prompt sur chaque commande dangereuse | Projets sensibles, débutants, sessions courtes | Très faible (mais ralentit le flux) |
| off | Aucune approbation, sauf hardline blocklist | Conteneurs jetables, CI/CD | Élevé sur machine locale |
| YOLO | Identique à off, activable par session | Tâche ponctuelle en environnement connu | Élevé si oublié actif |
Pour les tâches cron, le paramètre cron_mode est ton allié. Par défaut, il est réglé sur deny : si un cron job déclenche un prompt d’approbation, la commande est refusée et l’agent doit trouver une alternative. Tu peux le passer à approve si tu fais confiance à tes jobs, mais c’est un choix conscient.
Tu peux aussi définir des règles de refus personnalisées avec approvals.deny. C’est une liste de patterns glob qui bloquent des commandes spécifiques, même en YOLO ou off. Par exemple, interdire git push --force* ou tout pipe de curl vers sh. Ces règles sont ton filet de sécurité personnel, en complément de la hardline blocklist.
Une approche minimaliste mais efficace : garde smart par défaut, ajoute deux ou trois règles dans approvals.deny pour les commandes qui te font vraiment peur, et réserve YOLO aux conteneurs jetables. Tu gardes le contrôle sans te bloquer.
Le contrôle sans la paralysie
Les approbations Hermes ne sont pas un obstacle. Elles sont un arbitrage entre vitesse et sécurité. Le mode smart te donne le meilleur des deux mondes pour l’usage quotidien : les commandes inoffensives passent, les dangereuses sont bloquées ou escaladées. Si tu as besoin de plus de contrôle, manual est là. Si tu es dans un environnement jetable, off et YOLO sont des options documentées, pas des secrets honteux.
Le vrai risque n’est pas le mode que tu choisis. C’est de ne pas savoir ce que fait chaque mode, et de te retrouver avec une commande destructive exécutée sans ton accord parce que tu n’as jamais regardé ta config.
Si tu veux aller plus loin sur les points de contrôle à mettre en place au-delà des approbations de commandes, l’article dédié détaille une approche plus large.
Si tu veux aller plus loin sur la configuration complète d’un environnement Hermes productif et sécurisé, tu peux faire une demande d’accès au Second Cerveau Kavyro. Tu y trouveras des configurations prêtes à l’emploi, des retours d’usage réels et une communauté qui teste ces réglages au quotidien.
