Guardrails flotte Hermes (NAS + VPS) — hard_stop, tirith, verificateur croise

Contexte

Suite au succes du RAG hermes-tt (rapports d'evaluation, Excel, DCO livres sans retouche), demande explicite d'un Hermes avec garde-fous auto-actives + auto-contre independant, sur les 4 instances (hermes-tt, hermes-nyora, hermes-perso sur NAS + hermes-nabil sur VPS Contabo).

Failles confirmees (lecture directe des config.yaml, pas une supposition)

tool_loop_guardrails.hard_stop_enabled: false sur les 3 instances NAS et absent (donc false par defaut) sur hermes-nabil : l'agent ne fait qu'avertir sur boucle d'echec repetee, ne s'arrete jamais reellement. Recommandation officielle Nous Research pour deploiement gateway/non-surveille : l'activer.
security.tirith_enabled: false explicitement sur les 3 instances NAS (le binaire tirith — scanner anti-prompt-injection, homograph URL, exfiltration credentials — n'etait pas actif) alors qu'il est actif par defaut (et le binaire present) sur hermes-nabil.
Lecture code nyora-notes-tt/pipeline_processor.py + mcp_server.py : aucun marquage provenance/confiance sur le contenu mail avant ingestion RAG. Risque "sleeper channel" (cf. litterature academique sur les agents always-on) confirme reel, PAS corrige ce tour — chantier a part entiere (schema + formatage contexte), voir section "reste a faire".

Changements appliques (12/08/2026, backups config.yaml.bak-guardrails- avant chaque edit)

Instance	hard_stop_enabled	tirith_enabled	delegation (verificateur)
hermes-tt	false -> true	false -> true	deepseek-v4-pro -> mimo-v2.5 (opencode-go, cle deja en place)
hermes-nyora	false -> true	false -> true	deja mimo-v2.5 (personne ne s'en souvenait)
hermes-perso	false -> true	false -> true	'' -> mimo-v2.5 (opencode-go)
hermes-nabil (VPS)	absent -> true (bloc ajoute)	deja true par defaut, explicite maintenant	absent -> deepseek/deepseek-v4-flash via openrouter (cle OPENROUTER_API_KEY deja en .env)

Principe retenu

Le sous-agent verificateur (delegate_task) ne doit jamais tourner sur le meme modele que le generateur principal, pour eviter les angles morts partages (doc officielle Hermes : "the agent that does the work should not be its sole verifier"). NAS = generateur DeepSeek V4 Flash -> verificateur Mimo V2.5. hermes-nabil = generateur Mimo V2.5 (modele principal) -> verificateur DeepSeek V4 Flash. C'est l'inverse exact entre NAS et VPS, deliberement.

Piege / a savoir

docker compose up -d ne recharge PAS un config.yaml modifie si le container tourne deja (le fichier est un bind-mount, pas une image) — il faut un docker restart <container> explicite. up -d seul affiche "Running" sans rien faire.
data/ est gitignore sur les repos par-instance (hermes-tt, hermes-nyora, hermes-perso, hermes-nabil) — ne jamais force-add config.yaml, il contient des cles API en clair (Bifrost, OpenCode Zen). C'est un choix delibere du .gitignore existant, pas un oubli. Capitalisation via runbook + NyoraNotes uniquement pour ce type de fichier, pas de commit.
Clone Gitea depuis le NAS : gitea.bolbol.tn (domaine externe) a timeout HTTP 504 en cours de session ; 192.168.100.33:3232 (LAN direct) fonctionne. A garder en tete si un futur clone echoue bizarrement.

Incidents decouverts en cours de route (non lies au chantier, decouverts par effet de bord)

hermes-agent-tt etait down depuis 8h avant intervention (Exited(0) cote Docker mais lifecycle_ledger interne Hermes indique mort non-propre, SIGKILL/VM death, vers 12/08 14h13, suspected_oom=False). Cause non identifiee. Relance faite, healthy.
hermes-workspace-perso : Exited(128) depuis 24h, blocage au restart par un binding orphelin sur le port 3030 (host-level, PID invisible sans sudo — non resolu, necessite intervention avec privileges eleves ou redemarrage du daemon Docker).

Reste a faire (session dediee)

Provenance/tag "non fiable" sur le contenu mail avant ecriture RAG (nyora-notes-tt)
Debloquer port 3030 (hermes-workspace-perso)
Investiguer la cause de la mort hermes-agent-tt du 12/08 14h13
Envisager tirith_fail_open: false une fois confirme en usage reel que tirith tourne correctement (actuellement true = mode conservateur partout)

4.2 KiB Raw Blame History