Dans la communauté Hermes, on entend souvent dire : plus de la moitié des utilisateurs ont activé YOLO au moins une fois. Mais YOLO n’est pas toute l’histoire — c’est seulement un point extrême du spectre de sécurité d’Hermes. Ceux qui tirent vraiment le meilleur parti d’Hermes alternent entre sept modes courants, au lieu de se rabattre sur /yolo dès que les choses ralentissent.

Hermes Agent repose sur un principe fort par défaut : si vous laissez exécuter une commande, l’agent doit en assumer les conséquences. C’est pourquoi, avant d’exécuter quoi que ce soit de potentiellement destructeur, il s’arrête et demande. Cela s’appelle l’Approbation des Commandes Dangereuses (Dangerous Command Approval), et YOLO n’est qu’une façon de l’outrepasser.

Cet article couvre les sept modes de sécurité et d’autonomie dans Hermes. Après la lecture, vous saurez dire à votre agent :

• « Le mode smart suffit pour le développement normal. »
• « Je lance ce script souvent, approuve-le pour la session. »
• « Je fais un refactoring en masse, active YOLO, mais n’autorise jamais git push --force. »
• « Exécute cela dans Docker, ainsi aucune approbation n’est nécessaire et l’hôte reste en sécurité. »

---

1. Mode smart : laissez l’IA évaluer le risque (recommandé par défaut)

approvals:
  mode: smart

smart est le mode par défaut d’Hermes. Lorsqu’une commande correspond à un motif dangereux, Hermes demande à un modèle auxiliaire d’évaluer le risque réel.

• Les commandes évidemment sûres (par exemple, python -c "print('hello')") sont approuvées automatiquement.
• Les commandes évidemment dangereuses (par exemple, rm -rf /) sont refusées automatiquement.
• Les cas incertains sont escaladés vers vous.

Cela réduit considérablement la « fatigue d’approbation ». Vous n’avez pas à confirmer chaque bash -c, tout en restant protégé contre les actions réellement destructrices.

Idéal pour : le développement quotidien, les tâches exploratoires et les environnements dans lesquels vous faites déjà confiance à l’agent.

---

2. Mode manual : chaque commande dangereuse passe par vous

approvals:
  mode: manual

Si vous préférez ne pas déléguer l’évaluation des risques à un modèle auxiliaire, utilisez le mode manual. Chaque commande correspondant à un motif dangereux est mise en pause et attend votre approbation.

Dans la CLI, l’invite ressemble à ceci :

⚠️  DANGEROUS COMMAND: recursive delete
    rm -rf /tmp/old-project

    [o]nce  |  [s]ession  |  [a]lways  |  [d]eny

    Choice [o/s/a/D]:

Quatre choix :

• once : autorise seulement cette exécution.
• session : autorise ce motif pour le reste de la session.
• always : ajoute le motif à votre liste blanche permanente dans ~/.hermes/config.yaml.
• deny (par défaut) : bloque la commande.

Idéal pour : les tâches à haute sécurité, les débutants ou l’exécution de commandes inhabituelles.

---

3. Mode YOLO : sautez toutes les demandes d’approbation

Le mode YOLO contourne toutes les approbations de commandes dangereuses. Vous pouvez l’activer de trois façons :

# Au démarrage
hermes --yolo
hermes chat --yolo

# Pendant une session
/yolo

# Variable d'environnement
HERMES_YOLO_MODE=1

Une fois activé, Hermes affiche une bannière rouge et un indicateur dans la barre d’état, pour que vous n’oubliiez pas que le filet de sécurité est désactivé.

> /yolo
  ⚡ YOLO mode ON — all commands auto-approved. Use with caution.

YOLO convient aux scénarios où vous êtes sûr que les commandes sont sûres, par exemple :

• Des scripts d’automatisation répétés ;
• Du travail dans des conteneurs ou des environnements jetables ;
• Des tâches où vous surveillez attentivement et pouvez appuyer sur Ctrl+C à tout moment.

Mais souvenez-vous : YOLO n’est pas 100 % illimité — la liste noire hardline que nous allons voir s’applique toujours.

---

4. Liste noire hardline : le plancher que même YOLO ne franchit pas

Même avec approvals.mode: off ou /yolo activé, Hermes refuse certaines commandes irréversibles et catastrophiques. C’est la liste noire hardline.

Exemples :

Commande	Pourquoi elle est bloquée
rm -rf /	Efface le système de fichiers racine
:(){ :|:& };:	Bombe fork de bash
mkfs.* contre un périphérique racine monté	Formate le système en cours d’exécution
dd if=/dev/zero of=/dev/sd*	Remplit un disque physique de zéros
Pipeliner des URLs non fiables vers sh	Surface d’attaque d’exécution de code à distance trop grande

Ces motifs sont définis dans tools/approval.py::UNRECOVERABLE_BLOCKLIST et ne peuvent être outrepassés par aucun drapeau.

Philosophie de conception : YOLO signifie « Je fais confiance à l’IA pour ne pas se tromper », tandis que la liste hardline signifie « Même si l’IA — ou l’utilisateur — se trompe, la machine ne doit pas être détruite ».

---

5. Règles deny personnalisées : YOLO avec des exceptions

Si YOLO vous semble trop permissif et manual trop bruyant, utilisez approvals.deny pour tracer vos propres lignes rouges :

approvals:
  mode: off           # effectivement YOLO
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

Les règles sont des globales fnmatch insensibles à la casse, comparées au texte complet normalisé de la commande. Même sous YOLO, une commande correspondante est bloquée strictement.

C’est parfait pour les scénarios de type « Je fais confiance à la plupart des opérations, mais certaines actions ne sont jamais autorisées » :

• Laissez l’agent modifier du code et exécuter des tests librement, mais interdisez git push --force ;
• Autorisez-le à télécharger des dépendances, mais bloquez curl ... | sh ;
• Autorisez-le à manipuler Docker, mais jamais à écrire directement sur des périphériques de bloc.

---

6. Mode write approval : maîtriser les écritures en mémoire et en skills

Au-delà des commandes de terminal, Hermes écrit aussi des choses de lui-même : il enregistre des faits importants en memory et des workflows appris comme skills. Si vous craignez qu’il « apprenne de mauvaises choses », activez le write approval.

memory:
  write_approval: true

skills:
  write_approval: true

Lorsque cette fonction est activée, chaque écriture de mémoire ou de skill est mise en attente dans ~/.hermes/pending/ jusqu’à ce que vous la révisiez et l’approuviez :

# Voir les écritures de skills en attente
/skills pending
/skills diff <id>
/skills approve <id>
/skills reject <id>

# Même chose pour la mémoire
/memory pending
/memory approve <id>
/memory reject <id>

Idéal pour :

• Empêcher l’agent de mémoriser automatiquement des informations sensibles ou incorrectes ;
• Les instances Hermes partagées où les skills appris nécessitent une revue humaine ;
• Déboguer la boucle d’apprentissage avant de permettre toute persistance.

---

7. Isolation par conteneurs : remplacer les approbations par des frontières

Le dernier mode ne concerne pas la façon d’approuver, mais la façon de rendre les approbations inutiles. Hermes prend en charge plusieurs backends de terminal :

Backend	Isolation	Vérification des commandes dangereuses
local	Aucune, s’exécute sur l’hôte	✅ Oui
ssh	Machine distante	✅ Oui
docker	Conteneur	❌ Ignorée (le conteneur est la frontière)
singularity	Conteneur	❌ Ignorée
modal	Bac à sable cloud	❌ Ignorée
daytona	Bac à sable cloud	❌ Ignorée

Avec Docker, Modal ou Daytona, les vérifications de commandes dangereuses sont ignorées car, même si le conteneur est détruit, l’hôte reste intact. Les gateways Hermes en production sont généralement configurées ainsi.

Les conteneurs Docker s’exécutent également avec des paramètres de sécurité renforcés par défaut :

_BASE_SECURITY_ARGS = [
    "--cap-drop", "ALL",
    "--security-opt", "no-new-privileges",
    "--pids-limit", "256",
    "--tmpfs", "/tmp:rw,nosuid,size=512m",
]

Idéal pour : les déploiements en production, le CI/CD, les environnements multi-locataires et tout bac à sable où la destruction est acceptable.

---

Tableau rapide pour choisir le bon mode

Mode	Approbation des commandes	Approbation des écritures	Quand l’utiliser
smart	Pré-vérification par IA + vérification humaine pour les cas limites	Optionnelle	Défaut pour le développement quotidien
manual	Toutes les commandes dangereuses nécessitent une approbation humaine	Optionnelle	Tâches à haut risque ou débutants
YOLO	Toutes les commandes dangereuses ignorées	Optionnelle	Automatisation temporaire, scripts de confiance
hardline	Commandes catastrophiques bloquées en permanence	Non applicable	Plancher de sécurité toujours actif
deny rules	Motifs de blocage personnalisés	Non applicable	YOLO avec exceptions
write approval	Optionnelle	Requise pour les écritures memory/skill	Empêcher l’agent d’apprendre de travers
container isolation	Aucune vérification	Limitée par le conteneur	Production ou bac à sable

---

Recommandations pratiques

1. Restez sur le mode par défaut : le mode smart gère la plupart du travail quotidien sans interruptions constantes.
2. Utilisez l’approbation par session pour les tâches par lots : plus sûr que YOLO, mais évite de confirmer chaque commande.
3. Associez YOLO à des règles deny : si vous passez en YOLO, conservez au moins quelques lignes rouges personnalisées.
4. Faites tourner la production dans Docker : l’isolation est plus fiable que les approbations et élimine totalement la fatigue d’approbation.
5. Auditez régulièrement votre liste blanche : command_allowlist grossit avec le temps. Nettoyez-la périodiquement avec hermes config edit.
6. Activez write approval pour Hermes partagé : particulièrement important lors de l’exécution d’un gateway de longue durée en équipe.

---

Conclusion

Le système d’approbation d’Hermes n’est pas là pour vous ralentir. Il est là pour vous aider à concilier délégation de confiance et freinage à temps. YOLO est amusant, mais ce n’est qu’un des sept modes. Les utilisateurs avancés savent quand rester en smart, quand passer en manual, quand désactiver YOLO et quand laisser Docker faire le travail de sécurité pour eux.

La prochaine fois que vous tendrez la main vers /yolo, demandez-vous : Ai-je vraiment besoin de sauter toutes les approbations, ou une approbation par session plus une règle deny suffiraient-elles ?