# 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) :

```yaml
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) :
```yaml
    - "*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

```bash
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