Passage a approvals.mode: smart + deny rules sur les 4 instances Hermes

Instance auteur : Claude (session Nabil) Date : 2026-07-27 Tags : [infra, securite, approvals, transverse] Statut : valide

Contexte

hermes-perso et hermes-nyora tournaient en approvals.mode: manual (chaque commande signalee attend une validation humaine). hermes-tt tournait en approvals.mode: auto -- valeur non documentee dans le schema officiel (manual|smart|off), probablement un residu pre-0.19. hermes-nabil (VPS) n'avait meme pas de cle mode dans son bloc approvals:.

La 0.19 introduit le mode smart : un modele auxiliaire (auxiliary.approval) juge chaque commande signalee dans son contexte precis -- auto-approuve si risque faible (uniquement pour cette commande exacte, pas de blanc-seing sur un pattern), refuse si risque reel, escalade a l'utilisateur si ambigu. Combine avec approvals.deny (nouveau) : des patterns definis par l'utilisateur qui bloquent de facon absolue, avant meme le jugement du modele auxiliaire et avant un /yolo eventuel.

Point de vigilance souleve par Nabil avant d'appliquer : s'assurer que /yolo (accepter tout pour la session) et l'approbation ponctuelle (accepter une fois, sur escalade) restent disponibles. Reponse : oui -- le mode smart ne retire aucune des deux. /yolo reste un toggle de session independant du mode par defaut. L'escalade vers l'utilisateur en cas d'ambiguite declenche exactement le meme flux d'approbation manuel qu'avant (dialogue CLI ou message en attente cote messagerie).

Ce qui a ete change

Sur les 4 instances (hermes-perso, hermes-tt, hermes-nyora sur NAS ; hermes-nabil sur VPS Contabo) :

approvals:
  mode: smart          # etait: manual (perso, nyora) / auto (tt, valeur invalide) / absent (nabil)
  timeout: 60
  cron_mode: deny       # inchange -- un cron qui tombe sur une commande signalee reste bloque net, jamais auto-approuve
  mcp_reload_confirm: true
  destructive_slash_confirm: false
  deny:
    - "rm -rf /*"
    - "dd if=* of=/dev/*"
    - "*>*.env*"
    - "*>*credentials*"
    - "*>*secrets*"
    - "git push --force*"
    - "git push -f *"
    - "docker volume rm*"
    - "docker system prune*"
    - "*DROP TABLE*"
    - "*DROP DATABASE*"

hermes-tt recoit 3 regles deny supplementaires (enjeux achats/AO) :

    - "*TRUNCATE*"
    - "*-X DELETE*baserow*"
    - "*--request DELETE*baserow*"

auxiliary.approval -- le modele qui juge les commandes en mode smart -- route explicitement vers deepseek-v4-flash (pas le modele principal de l'instance quand celui-ci est mimo-v2.5) :

hermes-perso, hermes-tt : deja auto -> deepseek-v4-flash (modele principal), aucun changement necessaire.
hermes-nyora : auto aurait resolu vers mimo-v2.5 -- patche explicitement vers deepseek-v4-flash via bifrost-proxy (meme base_url/api_key que le modele principal). Raison : les 24 tool_calls casses trouves sur mimo-v2.5 en 12 jours (cf. common/vision-auxiliaire-routing-text-only-modeles.md et l'incident hermes-nabil du 26/07) disqualifient ce modele comme juge de securite -- le juge doit etre le plus fiable des deux, pas le principal par defaut.
hermes-nabil (VPS) : laisse en auto (mimo-v2.5), aucune alternative disponible -- ce VPS n'a aucune route configuree vers deepseek-v4-flash (pas de Bifrost local, pas de cle/provider deepseek dans son config.yaml). Ecart documente, a corriger si une route deepseek est ajoutee un jour sur ce VPS (ex: cle OpenRouter directe).

Ce qui NE fonctionne PAS

Tentative	Erreur / limite	Raison
Router auxiliary.approval de hermes-nabil vers deepseek-v4-flash comme sur les 3 autres	Aucune route existante	hermes-nabil VPS n'a ni Bifrost local ni cle/provider DeepSeek configure -- son seul modele accessible est mimo-v2.5 via opencode.ai/zen/go
Modifier /home/claude-oversight/hermes-nabil/data/config.yaml directement depuis le shell VPS (hors container)	`Permission denied`	Fichier `-rw------- root:root`, non lisible par l'utilisateur claude-oversight (uid 1000) meme membre du groupe docker -- passer par `docker exec`

Verification

docker exec hermes-agent-<inst> grep -A20 '^approvals:' /opt/data/config.yaml   # mode: smart + deny presents
docker inspect -f '{{.State.Health.Status}}' hermes-agent-<inst>                 # healthy

Prochaine commande signalee (heredoc, docker restart, etc.) sur une instance : verifier dans les logs qu'elle est jugee par le modele auxiliaire plutot que de toujours attendre une validation manuelle, ou confirmer qu'un cas ambigu remonte bien a Nabil comme avant.

References

common/vision-auxiliaire-routing-text-only-modeles.md (meme logique de routing auxiliaire explicite)
Hermes Agent v0.19.0 changelog (Quicksilver Release), section Delegation/approvals

4.8 KiB Raw Blame History