Tout utilisateur assidu de Hermes Agent connaît ce moment : vous regardez l’agent travailler, tout va bien, et soudain —paf— une demande d’approbation apparaît. L’avez-vous vraiment lue ? Soyons honnêtes. Après la cinquantième vérification rm de la journée, la plupart d’entre nous cliquent juste sur « approuver ». C’est la fatigue d’approbation, et c’est une faille de sécurité déguisée en commodité : plus vous tamponnez d’invites, moins chacune a de sens.

Hermes v0.19.0 (la Quicksilver Release) a attaqué ce problème à la racine. Les approbations intelligentes sont désormais activées par défaut : au lieu de vous demander d’approuver chaque commande signalée, Hermes fait évaluer chacune d’elles par un LLM réviseur indépendant, approuve automatiquement les cas à faible risque, refuse automatiquement les vraiment dangereux et ne fait remonter que les incertains. Moins d’interruptions, même contrôle humain — si ce n’est plus fort, parce que votre attention n’est dépensée que là où ça compte.

Cet article est un guide pratique : comment fonctionne réellement le nouveau flux d’approbation, les vraies clés de config.yaml (vérifiées contre le code source de v0.19, pas contre des légendes), et comment fixer des lignes rouges que même le mode yolo ne peut pas franchir.

Le problème : la fatigue d’approbation est un bug de sécurité

L’approbation manuelle fonctionnait quand les agents exécutaient une poignée de commandes par session. Les agents modernes en exécutent des dizaines ou des centaines. Chaque invite est un changement de contexte ; chaque changement de contexte épuise votre attention ; une attention épuisée approuve des choses qu’elle ne devrait pas. Les chercheurs en sécurité ont un nom pour ça —l’habituation— et c’est exactement ainsi que passe la seule commande que vous auriez dû lire attentivement.

L’ancien flux avait un second problème : vous étiez le classificateur de risque. Hermes signalait une commande, vous la jugiez, terminé. La qualité du jugement dépendait de votre vigilance à cet instant précis — le pire design possible pour un mécanisme de sécurité.

Les approbations intelligentes règlent les deux : la classification de routine est confiée à un modèle qui ne se fatigue jamais, et la décision finale reste la vôtre.

Comment ça marche : trois verdicts, une commande à la fois

Quand Hermes veut exécuter une commande qui correspond à sa liste de motifs dangereux, le flux n’est plus « demander à l’humain ». C’est :

1. Un LLM auxiliaire évalue la commande de manière indépendante — pas l’agent principal, mais un modèle réviseur séparé.
2. Le réviseur rend l’un de trois verdicts :
   • Sûr → approbation automatique, sans interruption.
   • Dangereux → refus automatique, motif consigné.
   • Incertain → remonté vers vous pour approbation/refus manuel.

Le détail important figure dans les notes de version : chaque verdict ne couvre que cette commande exacte. Une commande ultérieure correspondant au même motif reçoit sa propre évaluation fraîche. Pas de raccourci du genre « on a déjà approuvé cette classe, approuvons-la encore ». Le réviseur ne peut pas être engourdi par les motifs, et vous non plus — parce que vous ne voyez que les cas vraiment ambigus.

Vous : « déploie le serveur de staging et lance la migration »
Hermes : [kubectl apply --dry-run ...]      → évaluation : sûr, approuvé automatiquement
         [kubectl rollout restart ...]      → évaluation : sûr, approuvé automatiquement
         [kubectl delete namespace prod]    → évaluation : DANGEREUX, refusé automatiquement
         [psql -c "DROP TABLE users;"]      → incertain → remonté vers vous

Voilà le flux qui met fin au hochement de tête.

La vraie configuration : approvals.mode, pas de la légende

Si vous avez lu d’anciens articles sur les approbations de v0.19, vous avez peut-être vu des clés inventées comme smart_approvals: true ou deny_rules: avec des champs pattern:/reason:. Elles n’existent pas. Le schéma réel dans config.yaml est :

# ~/.hermes/config.yaml
approvals:
  mode: smart        # smart | manual | off  (smart est la valeur par défaut)
  timeout: 300       # secondes d'attente de votre réponse avant échec sécurisé
  cron_mode: deny    # deny | approve — comportement des jobs cron sur commande signalée
  deny: []           # vos lignes rouges : motifs glob bloqués inconditionnellement

Clé	Défaut	Rôle
mode	smart	Politique d’approbation des commandes shell signalées
timeout	300	Secondes d’attente de votre réponse avant de considérer comme un refus
cron_mode	deny	Comportement sans surveillance : deny bloque les commandes signalées en cron, approve les exécute
deny	[]	Motifs glob qui bloquent les commandes inconditionnellement — même en yolo

Vérifiez votre réglage actuel à tout moment :

hermes config | grep -A 4 approvals

Les trois modes en clair :

• smart (par défaut) — l’évaluation LLM filtre les commandes de routine ; les dangereuses sont refusées ; les incertaines vous parviennent.
• manual — chaque commande signalée vous demande, comme avant v0.19.
• off — aucune invite d’approbation ; équivalent à --yolo / HERMES_YOLO_MODE=1. Réservé aux sandboxes de confiance.

Lignes rouges : approvals.deny bat yolo

Voici la partie qui rend le mode intelligent sûr à adopter sans stress. La liste deny est un ensemble de motifs glob qui bloquent les commandes correspondantes inconditionnellement — avant tout contournement yolo, avant /yolo, avant mode: off. C’est la contrepartie modifiable par l’utilisateur de la liste noire codée en dur de Hermes, et c’est la ligne de défense la plus importante que vous puissiez configurer :

approvals:
  mode: smart
  deny:
    - "git push --force*"
    - "rm -rf /"
    - "*curl*|*sh*"
    - "kubectl delete namespace*"

Les motifs sont des globs fnmatch insensibles à la casse. Mettez-les entre guillemets en YAML — un * initial nu est une erreur de syntaxe. Une commande correspondante est bloquée avec motif consigné, sans discussion. Même en mode yolo. C’est votre liste « peu importe la confiance de l’agent, ça n’arrive jamais », et elle doit contenir les quelques opérations dont les modes de défaillance sont inacceptables : force-push vers des branches partagées, suppressions récursives, suppression de namespaces de production, secrets écrits via CLI.

L’échappatoire pour une exécution vraiment délibérée ? Aucune dans la configuration — et c’est le but. Si vous devez vraiment faire un force-push, vous retirez le motif, exécutez la commande, puis le remettez. La friction est intentionnelle et minuscule.

/deny <reason> : faites de la refus une leçon

Les approbations intelligentes ne réduisent pas seulement les invites — elles rendent celles que vous répondez réellement plus précieuses. Quand le réviseur vous fait remonter une commande et que vous la refusez, vous pouvez maintenant dire à l’agent pourquoi :

Hermes veut exécuter : docker system prune -a -f

> /deny trop agressif — d'autres conteneurs partagent ce cache d'images

Le motif est réécrit dans le contexte, et l’agent corrige sa trajectoire — il cherche une commande plus ciblée au lieu de réessayer la même en espérant que vous cédiez. Un refus motivé est un retour ; un refus sec est un mur. Prenez l’habitude de donner une phrase de raison, et la prochaine tentative de l’agent sera nettement meilleure.

À noter : si l’agent part complètement dans la mauvaise direction, /stop tue toujours l’exécution instantanément. Le flux d’approbation et le bouton d’arrêt sont complémentaires — l’un filtre les commandes, l’autre coupe toute la séquence.

Jobs cron : personne n’est là pour hocher la tête

Les approbations intelligentes brillent en sessions interactives — mais qu’en est-il des sessions sans surveillance ? Quand un job cron programmé rencontre une commande signalée, il n’y a aucun utilisateur à qui remonter. La valeur par défaut cron_mode: deny gère cela de manière conservatrice : la commande est bloquée, et l’agent doit trouver un autre chemin. Si vous avez confiance en un job précis (par exemple, une sauvegarde nocturne qui nettoie légitimement de vieux fichiers), vous pouvez changer sa politique :

approvals:
  cron_mode: approve   # approuve automatiquement les commandes signalées en contexte cron

Réfléchissez bien avant d’activer cela. deny ne coûte rien quand l’agent trouve une voie alternative ; approve transforme chaque invite cron en exécution silencieuse. Pour la plupart des jobs, deny plus une liste d’exceptions étroite dans approvals.deny est la bonne forme.

Quel mode devriez-vous utiliser ?

Situation	Recommandation
Travail interactif quotidien	smart (par défaut) — vous gardez le veto, vous perdez le bruit
Chirurgie de dépôt / opérations destructrices	smart + règles deny — lignes rouges pour l’irréversible
Sandbox totalement fiable / conteneur CI	off ou --yolo, mais gardez deny comme filet de sécurité
Nostalgie	manual — si vous voulez vraiment revoir chaque invite

Pour la plupart des gens, la réponse est : laissez mode: smart, passez dix minutes à écrire des règles deny, et utilisez /deny <reason> à chaque refus. C’est toute la mise à niveau.

Au-delà des approbations : défense en profondeur

Les approbations intelligentes sont une couche du modèle de défense en profondeur de Hermes, pas toute l’histoire. Les autres couches à connaître : les checkpoints prennent des instantanés automatiques du système de fichiers avant les opérations destructives (une erreur devient un rollback, pas un désastre), la rédaction de secrets nettoie les chaînes ressemblant à des clés API dans les sorties d’outils avant qu’elles n’atteignent le contexte ou les logs, et l’isolation par conteneur (backends Docker/Singularity/Modal) peut enfermer complètement l’outil terminal. Les approbations décident si une commande s’exécute ; les checkpoints décident ce qui se passe après. Ils se composent.

Résumé

Les approbations intelligentes de Hermes v0.19 ne signifient pas « l’agent peut tout faire maintenant ». C’est l’inverse : un humain fatigué qui tamponne chaque invite est remplacé par un réviseur infatigable qui filtre la routine, bloque le dangereux et ne fait remonter que l’ambigu. La vraie configuration tient en trois clés et une habitude :

• approvals.mode: smart — la valeur par défaut qui met fin à la fatigue d’approbation.
• approvals.deny: [...] — vos lignes rouges, actives même en mode yolo.
• approvals.cron_mode: deny — les jobs sans surveillance restent conservateurs.
• L’habitude : /deny <reason> — chaque refus enseigne.

Votre agent gagne en autonomie ; vous gardez chaque gramme de contrôle. Fini de hocher la tête.

Envie d’autres guides Hermes sur la sécurité et les workflows ? Découvrez l’analyse approfondie de la v0.19.0, la configuration des approbations à trois portes, notre explication du mode yolo et le guide de gestion des erreurs et de récupération. Nouveau sur Hermes ? Commencez par le guide d’installation.