Hermes Agent v0.19.0 fait de Smart Approvals le comportement par défaut. Avant, quand l’Agent voulait exécuter une commande marquée, il vous interrompait pour demander une confirmation ligne par ligne. Désormais, un réviseur LLM indépendant classe chaque commande comme sûre, dangereuse ou incertaine — et seules les incertaines vous parviennent.

Ça semble bien, mais en production, une « approbation automatique » erronée peut vous coûter une base de données, une configuration de production ou une clé API fuitée. C’est pourquoi cet article décompose Smart Approvals en trois niveaux que vous pouvez réellement déployer, pour garder l’automatisation sans perdre le contrôle. Toutes les clés de configuration ci-dessous sont vérifiées contre le code source de v0.19.0 et la documentation officielle — les clés qui circulent sur internet comme smart_approvals: true ou deny_rules: avec des champs pattern:/reason: n’existent pas. Le vrai schéma est ici.

Pour la vue d’ensemble de v0.19, consultez nos notes de publication v0.19.0 et le résumé des fonctionnalités de v0.19.

Niveau 1 : révision préalable par LLM — auto-approuver le sûr, auto-refuser le dangereux, escalader l’incertain

C’est le comportement par défaut de v0.19. Hermes ne vous lance plus chaque commande : un modèle de révision interne la juge d’abord.

Logique de décision :

• Sûre → approuvée automatiquement, sans interruption
• Dangereuse → refusée automatiquement, motif enregistré
• Incertaine → escaladée vers vous

Chaque commande est examinée individuellement : une approbation précédente ne donne pas de passe-droit à la commande similaire suivante. Cela réduit la fatigue d’approbation, mais introduit un nouveau problème : les critères du réviseur sont une boîte noire pour vous. D’où la nécessité du Niveau 2 comme filet de sécurité.

Au passage, le modèle de révision est configurable — la vraie clé se trouve sous auxiliary.approval (pas approvals.review_model, qui n’existe pas). Vous la verrez dans l’exemple complet ci-dessous.

Niveau 2 : approvals.deny — des lignes rouges que même le mode yolo ne franchit pas

La configuration de lignes rouges que v0.19 vous offre dans config.yaml est approvals.deny : une liste de motifs glob fnmatch qui bloquent inconditionnellement les commandes de terminal correspondantes. Elle prime sur --yolo, /yolo et mode: off — autrement dit, c’est la contrepartie modifiable par l’utilisateur de la liste noire intégrée de Hermes : « aussi confiant que soit l’Agent, cette commande ne doit jamais s’exécuter ».

Exemple de configuration :

# ~/.hermes/config.yaml
approvals:
  mode: smart        # smart | manual | off (smart est la valeur par défaut)
  deny:              # lignes rouges : motifs glob qui bloquent inconditionnellement
    - "git push --force*"
    - "rm -rf /"
    - "*curl*|*sh*"
    - "kubectl delete namespace*"

Conseils :

1. Listez les catégories d’opérations que vous ne voulez jamais voir exécutées automatiquement — push forcé sur les branches partagées, suppressions récursives, suppression de namespaces de production, écriture de secrets via la CLI, etc.
2. Les motifs sont des globs fnmatch insensibles à la casse, pas des regex. Mettez-les entre guillemets en YAML — un * initial nu est une erreur d’analyse.
3. En cas de correspondance, l’Agent reçoit un message BLOCKED explicite et l’instruction de ne pas réessayer ni reformuler la commande. Il n’y a pas de champ reason dans la liste deny ; pour documenter l’intention, utilisez un commentaire YAML à côté du motif.
4. Notez : approvals.deny correspond aux commandes de terminal (après normalisation et désobfuscation, donc des astuces comme r\m ou git st""atus ne l’esquivent pas), pas aux chaînes d’appels d’outils — browser_*, file_* et similaires sont hors de son champ.

Niveau 3 : intervention humaine avec feedback apprenable — /deny est plus qu’un non

Quand la révision LLM ne peut pas trancher et que la commande vous parvient, vous avez normalement deux options : approuver ou refuser. v0.19 ajoute le refus motivé : /deny <motif> (/deny all <motif> refuse d’un coup toutes les approbations en attente). Le motif est transmis à l’Agent et inscrit dans le contexte, si bien qu’à la prochaine tentative il corrige sa trajectoire au lieu de réessayer la même commande.

Exemple CLI / TUI :

# Hermes veut exécuter : docker system prune -a -f
# Vous décidez que ce n’est pas le moment et refusez avec motif
/deny cela supprimera toutes les images et pourrait casser d’autres conteneurs

# Le motif reste dans le contexte ; les tentatives suivantes éviteront des commandes similaires

Si vous voulez juste bloquer une fois, un refus sans motif suffit. Mais pour un apprentissage à long terme, prenez l’habitude de refuser avec motif — un refus motivé est du feedback ; un refus sec est un mur.

Et si l’Agent part complètement en vrille en pleine séquence, /stop met fin à l’exécution en cours instantanément. La commande existe depuis v0.3, mais elle se marie particulièrement bien avec le nouveau flux d’approbation de v0.19.

Exemple complet de configuration à trois niveaux

# ~/.hermes/config.yaml
approvals:
  mode: smart                   # smart | manual | off (smart est la valeur par défaut)
  timeout: 300                  # secondes d’attente de votre décision ; délai dépassé = refus
  cron_mode: deny               # deny | approve — politique pour les exécutions cron non supervisées
  deny:                         # lignes rouges : blocage inconditionnel, même sous yolo
    - "rm -rf /"
    - "git push --force*"
    - "kubectl delete namespace*"
    - "*curl*|*sh*"
  denial_breaker_threshold: 3   # arrêt dur après N refus consécutifs (0 désactive)
  smart_policy: |               # optionnel : ajoutez vos règles au LLM réviseur
    Always ESCALATE commands that modify anything under /etc.

# Modèle de révision (optionnel) : auto par défaut ; un modèle rapide et économique est recommandé
auxiliary:
  approval:
    provider: auto              # auto | openrouter | nous | codex | custom
    model: ""                   # vide = défaut du provider ; p. ex. gemini-flash, classe haiku

Des points faciles à manquer :

• denial_breaker_threshold (défaut 3) : à chaque variante reformulée du même commande refusée par le réviseur, un autre appel de révision est consommé. Une fois le seuil de refus consécutifs atteint, le message de refus devient une instruction d’arrêt dur — l’Agent doit s’arrêter, signaler l’opération bloquée et vous laisser l’exécuter manuellement ou via /approve. Toute approbation réinitialise le compteur ; mettez 0 pour désactiver.
• smart_policy : ajoute vos propres règles au system prompt du LLM réviseur (le canal de confiance, jamais mélangé au texte non fiable de la commande), pour affiner son jugement à votre environnement sans toucher au code.
• Le chemin de configuration est ~/.hermes/config.yaml (ou le config.yaml de votre Profile actuel), pas un .hermes/config.yaml au niveau du projet.

Redémarrez Hermes après avoir enregistré, puis vérifiez :

hermes config get approvals.mode
hermes config get approvals.deny

Quand les trois niveaux travaillent-ils ensemble ?

Scénario	Niveau 1 : révision LLM	Niveau 2 : approvals.deny	Niveau 3 : Humain
ls -la pour inspecter un répertoire	approuvé automatiquement	aucune correspondance	aucune interruption
rm -rf /	correspond à deny	bloqué immédiatement, même sous yolo	aucun humain requis
docker system prune -a	jugé incertain	aucune correspondance	escaladé vers vous
Variantes répétées d’une commande refusée	seuil du breaker atteint	—	arrêt dur ; vous l’exécutez

L’essentiel : les niveaux se complètent — la révision LLM absorbe la charge routinière, approvals.deny impose des contraintes dures et le jugement humain couvre les zones grises. Ils ne se remplacent pas.

Avancé : une rigueur d’approbation différente par Profile

Chaque Profile de Hermes possède son propre répertoire de configuration (Profile par défaut : ~/.hermes/config.yaml ; Profiles nommés : ~/.hermes/profiles/<name>/config.yaml), donc pas besoin d’une clé profiles: imbriquée dans votre configuration — modifiez simplement le fichier du Profile concerné. Par exemple : gardez les trois niveaux sur le Profile travail ; utilisez mode: off plus deny sur un Profile personnel ; ne laissez que les lignes rouges deny sur un Profile CI/CD. Au changement de Profile, Hermes charge automatiquement le jeu de règles correspondant.

Pièges courants et dépannage

1. Les règles deny ne prennent pas effet : vérifiez le chemin — la configuration utilisateur est ~/.hermes/config.yaml (ou le config.yaml de votre Profile actuel), pas un .hermes/config.yaml au niveau du projet. De plus, les changements ne sont chargés qu’après redémarrage de Hermes/gateway — il n’existe pas de commande hermes config reload.
2. La révision LLM est trop lente : pointez auxiliary.approval.model vers un modèle léger (p. ex. gemini-flash, classe haiku) plutôt que le réviseur par défaut.
3. Des confirmations apparaissent encore en mode yolo : la commande a été jugée incertaine et ne correspondait à aucun motif approvals.deny. Ajoutez un motif pour elle, ou resserrez le réviseur avec smart_policy.
4. Erreurs d’analyse YAML : les globs commençant par * doivent être entre guillemets (p. ex. "*curl*|*sh*") ; sinon tout le bloc approvals échoue à l’analyse et la configuration est ignorée.

Résumé

Smart Approvals dans Hermes v0.19 ne confie pas l’autorité au LLM — il laisse le LLM pré-filtrer pendant que la décision finale reste entre vos mains. Trois niveaux :

• Niveau 1 : révision préalable par LLM (approvals.mode: smart) pour la routine
• Niveau 2 : approvals.deny comme lignes rouges dures, efficaces même en mode yolo
• Niveau 3 : /deny <motif> et confirmation humaine pour les zones grises

Ainsi configuré, votre Agent n’est ni un raseur qui demande tout, ni un déchaîné qui peut tout faire.

# Les changements s’appliquent après redémarrage de Hermes (pas de commande reload)
hermes config get approvals.mode    # vérifier le mode
hermes config get approvals.deny    # vérifier les lignes rouges

D’autres guides sur la sécurité et l’efficacité de Hermes ? Consultez notre guide de gestion des erreurs et de récupération et celui sur les tâches longues sans blocage. Pour comprendre pourquoi Smart Approvals est le comportement par défaut, lisez fatigue d’approbation : plus besoin d’acquiescer à chaque étape.