Introduction
Hermes Agent dispose d'un accès complet à votre système : exécution de commandes shell, lecture et écriture de fichiers, accès réseau, requêtes SQL, manipulation de bases de données. Ce pouvoir implique une responsabilité. Si un modèle IA malveillant ou une simple hallucination génère une commande destructive, les conséquences peuvent être irréversibles.
C'est pourquoi Hermes intègre un modèle de sécurité multicouche conçu pour protéger votre système sans entraver la productivité. Cet article détaille chaque couche : approbations de commandes, scanner de sécurité avancé, dissimulation des secrets dans les logs, filtrage d'accès web, et bonnes pratiques pour un déploiement sécurisé.
Le système d'approbation des commandes
Chaque commande exécutée par Hermes via l'outil terminal passe par un système de détection et d'approbation à plusieurs niveaux. Ce système est le cœur de la sécurité opérationnelle d'Hermes.
Deux niveaux de dangerosité
Hermes distingue deux catégories de commandes, avec des traitements radicalement différents :
HARDLINE_PATTERNS — commandes définitivement bloquées, même en mode YOLO :
rm -rf /,rm -rf /home,rm -rf /etc,rm -rf /usr— suppression récursive de répertoires système ou homemkfs— formatage de système de fichiersdd of=/dev/sda,> /dev/sda— écriture brute ou redirection vers un périphérique bloc- Fork bombs (
:(){ :|:& };:) kill -1,shutdown,reboot,halt,poweroff— arrêt ou redémarrage du systèmesystemctl poweroff/reboot/halt,init 0/6,telinit 0/6
Ces commandes sont bloquées sans exception. Aucun mode de configuration ne permet de les contourner. C'est une protection absolue contre les scénarios catastrophe.
DANGEROUS_PATTERNS — commandes potentiellement dangereuses nécessitant une approbation explicite :
- Suppression :
rm -r,find -delete,find -exec rm,xargs rm - Permissions :
chmod 777,chmod 666,chmod o+w,chown -R root - Opérations SQL destructrices :
DROP TABLE,DELETE FROMsans clause WHERE,TRUNCATE - Exécution de contenu distant :
curl | sh,wget | bash, processus de substitution avec$(curl...) - Exécution de scripts :
bash -c,python -c,perl -e,node -e, heredocs (python3 << 'EOF') - Écriture dans des chemins sensibles :
/etc/, fichiers.env,.ssh/,.bashrc/.zshrc, configs système - Opérations Git destructrices :
git push --force,git reset --hard,git clean -f,git branch -D - Processus :
pkill -9,killall,kill -9 -1 - Services système :
sudo,systemctl stop/restart/disable - Exécution après
chmod +x: détecte le patternchmod +x && ./script
Ces commandes déclenchent un prompt d'approbation (en CLI) ou une notification (en gateway) avant exécution.
Protection anti-auto-terminaison
Hermes se protège lui-même contre les commandes qui le tueraient :
pkill hermes,killall hermes— terminaison du processus Hermeshermes gateway stop,hermes update— arrêt ou mise à jour qui tue les agents en courskill $(pgrep -f hermes)— expansion de PID pour contourner le pattern name-based- Lancement du gateway hors systemd (
gateway run &,nohup gateway run)
Cette protection garantit que les travaux en cours ne sont pas interrompus involontairement par une commande générée par l'agent.
Les modes d'approbation
Trois modes sont disponibles via la configuration :
# Dans ~/.hermes/config.yaml
approvals:
mode: manual # manual | smart | off
timeout: 60 # secondes avant auto-refus
cron_mode: deny # deny | approve (comportement des cron jobs)
Mode manual (défaut) : chaque commande détectée comme dangereuse déclenche un prompt interactif avec quatre choix :
- once — exécuter la commande une seule fois
- session — autoriser toutes les commandes correspondant à ce pattern pour la session en cours
- always — autoriser définitivement ce pattern (sauvegardé dans
config.yaml) - deny — refuser la commande
Les commandes longues (> 70 caractères) offrent un choix supplémentaire view pour consulter la commande complète avant de décider.
Mode smart : un modèle LLM auxiliaire évalue le risque réel de la commande. Ce mode, inspiré du système Smart Approvals d'OpenAI Codex, résout le problème des faux positifs fréquents. Par exemple, python -c "print('hello')" est détecté comme dangereux par le pattern regex (exécution via flag -c), mais le LLM comprend qu'il s'agit d'un print inoffensif et l'auto-approuve.
Le LLM reçoit la commande et la raison du flag, puis retourne :
- approve — la commande est clairement sûre
- deny — la commande est réellement dangereuse
- escalate — incertain, renvoie vers l'approbation manuelle
Mode off : les commandes DANGEROUS sont exécutées sans approbation. Les commandes HARDLINE restent bloquées. Ce mode est à réserver aux environnements jetables.
L'approbation permanente (allowlist)
Quand vous choisissez always pour une commande, le pattern est sauvegardé dans votre configuration :
approvals:
permanent_allowlist:
- "recursive delete"
- "world/other-writable permissions"
Les commandes correspondant à ces patterns sont automatiquement approuvées sans prompt. Les alias de patterns sont gérés automatiquement pour la rétrocompatibilité.
Le mode YOLO
Le mode YOLO (/yolo en session ou --yolo au lancement) désactive toutes les approbations des commandes DANGEROUS_PATTERNS :
/yolo # Toggle ON/OFF en session
hermes --yolo # Lancer directement en mode YOLO
Les commandes HARDLINE restent bloquées même en YOLO — c'est la dernière ligne de défense.
⚡ Utilisez le mode YOLO uniquement dans des environnements isolés (conteneurs Docker, VM jetables). Ne l'activez jamais sur votre machine de production ou votre VPS principal.
Approbations en mode gateway
En mode gateway (Telegram, Discord, Slack, etc.), les approbations fonctionnent via des commandes dédiées :
/approve— valider une commande en attente/deny— refuser une commande en attente- Un timeout configurable (défaut : 60 secondes) refuse automatiquement les commandes non validées
- Les warnings Tirith masquent l'option always dans le prompt (pas d'allowlist permanente pour les menaces de contenu)
Le mode smart est particulièrement recommandé en gateway pour éviter de bloquer l'agent sur des faux positifs pendant que vous n'êtes pas devant l'écran.
Comportement des cron jobs
Les tâches cron s'exécutent sans interaction humaine. Le paramètre cron_mode définit leur comportement face aux commandes dangereuses :
approvals:
cron_mode: deny # Bloquer toute commande dangereuse (défaut, recommandé)
# cron_mode: approve # Exécuter sans approbation (risqué)
En mode deny (recommandé), les commandes dangereuses sont refusées silencieusement. Conception de prompt cron : évitez les opérations à risque dans vos tâches programmées, ou utilisez les toolsets restreints pour limiter les outils disponibles au cron job.
Tirith : le scanner de sécurité avancé
Tirith est un outil de sécurité externe intégré à Hermes qui effectue une analyse sémantique des commandes, au-delà des simples patterns regex.
Qu'est-ce que Tirith ?
Tirith détecte des menaces de niveau contenu que les patterns basés sur les regex ne peuvent pas attraper :
- URLs homographes — caractères Unicode visuellement identiques à des caractères ASCII (par exemple, le « а » cyrillique au lieu du « a » latin) utilisés pour tromper les filtres
- Injections de terminal — séquences d'échappement ANSI cachées dans des commandes qui pourraient modifier l'affichage ou exécuter des actions non voulues
- Pipes vers des interpréteurs via des techniques d'obfuscation non couvertes par les patterns classiques
- Menaces structurales — commandes dont la dangerosité dépend de la combinaison de plusieurs éléments
Configuration
# Dans ~/.hermes/config.yaml
security:
tirith_enabled: true # Activé par défaut
tirith_path: tirith # Chemin vers le binaire (auto-installé si absent)
tirith_timeout: 5 # Timeout d'analyse en secondes
tirith_fail_open: true # Comportement en cas de panne
Auto-installation
Si Tirith n'est pas trouvé sur le système, Hermes le télécharge automatiquement depuis les releases GitHub (sheeki03/tirith) avec vérification SHA-256. Si l'outil cosign est disponible, la provenance est également vérifiée (signature du workflow GitHub Actions). L'installation s'effectue dans un thread d'arrière-plan pour ne pas bloquer le démarrage.
Verdicts
Tirith retourne trois codes de sortie :
- allow (0) : la commande passe sans avertissement
- warn (2) : avertissement — nécessite une approbation, mais l'option always est masquée (les menaces de contenu ne doivent pas être allowlistées en permanence)
- block (1) : bloque la commande avec une description détaillée des findings
Fail-open vs fail-closed
Le paramètre tirith_fail_open définit le comportement quand Tirith plante ou dépasse le timeout :
true(défaut) : la commande est autorisée — priorité à la disponibilitéfalse: la commande est bloquée — priorité à la sécurité
En production critique, utilisez false pour un comportement fail-closed. En développement, true évite les blocages intempestifs.
Redaction des secrets dans les logs
Hermes intègre un système de dissimulation automatique des secrets pour empêcher les clés API, tokens et credentials de fuiter dans les logs, la sortie verbose, et les logs du gateway.
Activation
# Dans ~/.hermes/config.yaml
security:
redact_secrets: true # Désactivé par défaut — à activer en gateway
L'activation se fait via security.redact_secrets: true dans le config, qui est ponté vers la variable d'environnement HERMES_REDACT_SECRETS. La vérification est snapshotée au démarrage — un LLM ne peut pas activer/désactiver la redaction en cours de session.
Patterns de détection
Le système reconnaît automatiquement les formats de tokens de plus de 30 providers :
Clés API courantes :
- sk-* — OpenAI, OpenRouter, Anthropic
- ghp_*, github_pat_*, gho_*, ghs_*, ghu_*, ghr_* — GitHub
- xox[baprs]-* — Slack
- AIza* — Google API
- AKIA* — AWS Access Key ID
- sk_live_*, sk_test_* — Stripe
- pplx-*, fal_*, fc-* — Perplexity, Fal.ai, Firecrawl
Paramètres sensibles dans les URLs et bodies :
- Query strings : ?api_key=, ?token=, ?secret=, ?password=, ?client_secret=
- Corps JSON/form : champs access_token, refresh_token, authorization, private_key
Logique de masquage
- Tokens courts (< 18 caractères) : entièrement masqués (
***) - Tokens longs : conservation des 6 premiers et 4 derniers caractères pour le debug
Exemple : sk-ant-api03-xxxxx...abcd
Website Blocklist : filtrage d'accès web
Hermes peut bloquer l'accès à certains domaines via les outils browser et web, protégeant contre les accès non désirés ou malveillants.
Configuration
# Dans ~/.hermes/config.yaml
security:
website_blocklist:
enabled: true
domains:
- evil-site.com
- phishing-example.org
- "*.suspicious-domain.net"
shared_files:
- /path/to/community-blocklist.txt
Fonctionnement
- Les domaines sont comparés avec support des wildcards (
*.example.com) - Le préfixe
www.est automatiquement retiré pour la comparaison - Les fichiers partagés contiennent un domaine par ligne (les lignes commençant par
#sont des commentaires) - La politique est mise en cache 30 secondes pour éviter de relire le fichier YAML à chaque requête
- Un fichier manquant ou illisible génère un warning mais ne bloque pas les outils web
URLs privées et accès localhost
Par défaut, Hermes bloque la navigation vers les URLs privées depuis le navigateur pour prévenir les attaques SSRF (Server-Side Request Forgery) :
# Dans ~/.hermes/config.yaml
security:
allow_private_urls: false # Bloquer localhost (défaut)
Le paramètre browser.auto_local_for_private_urls (défaut true) permet d'utiliser Chromium local automatiquement pour les URLs sur le réseau local (LAN, localhost), contournant les services de navigateur distants et évitant les latences réseau inutiles.
Bonnes pratiques de sécurité
Isolation avec Docker
Le moyen le plus efficace de sécuriser Hermes est d'utiliser le backend terminal Docker :
hermes config set terminal.backend docker
Toutes les commandes s'exécutent dans un conteneur isolé. Une commande rm -rf / ne supprime que le filesystem du conteneur, pas votre système hôte. C'est la protection la plus simple et la plus robuste.
Un VPS Hostinger avec 2 vCPU et 4 Go de RAM suffit pour faire tourner Hermes avec le backend Docker et le gateway en mode always-on.
Principe du moindre privilège
- Créez un utilisateur dédié pour Hermes au lieu de l'exécuter en root
- Limitez les toolsets activés :
hermes tools disable websi le navigateur n'est pas nécessaire - Utilisez des clés API scoped (permissions limitées) plutôt que des clés full-access
- Séparez les environnements : un profil pour le développement, un pour la production
Monitoring et audit
# Consulter les logs de sécurité
hermes logs --level warning | grep -i "approval\|dangerous\|tirith"
# Vérifier les approbations permanentes
hermes config | grep -A20 approvals
# Voir les commandes récemment approuvées
grep "approval" ~/.hermes/logs/agent.log | tail -20
Configuration recommandée pour la production
Voici une configuration sécurisée pour un gateway Hermes always-on :
# ~/.hermes/config.yaml — setup sécurisé pour un gateway
security:
tirith_enabled: true
tirith_fail_open: false # Fail-closed en production
redact_secrets: true # Toujours activer en gateway
allow_private_urls: false
website_blocklist:
enabled: true
domains: []
shared_files: []
approvals:
mode: smart # Auto-approuver les faux positifs
timeout: 60
cron_mode: deny # Bloquer les commandes dangereuses en cron
terminal:
backend: docker # Isolation des commandes
Conclusion
Hermes Agent intègre un modèle de sécurité multicouche qui protège votre système sans sacrifier la productivité. Le système d'approbation à deux niveaux (hardline indépassable + dangerous avec approbation flexible), combiné au scanner Tirith pour les menaces sémantiques et à la redaction automatique des secrets, offre une protection complète contre les commandes involontaires, les fuites de données et les accès non autorisés.
Les points essentiels à retenir :
- Ne désactivez jamais les approbations sur un système de production — utilisez le mode smart pour un équilibre optimal
- Activez
redact_secrets: truedès que vous utilisez Hermes en mode gateway - Utilisez le backend Docker pour une isolation complète des commandes shell
- Configurez
tirith_fail_open: falseen production critique pour un comportement fail-closed - Concevez vos cron jobs avec des prompts qui n'entraînent aucune commande dangereuse
Pour approfondir la gestion des outils et commandes, consultez notre article sur les outils disponibles dans Hermes Agent et découvrez comment les checkpoints permettent de revenir en arrière en cas de modification accidentelle.