Securite de Hermes Agent : guide complet de protection

Introduction

Hermes Agent integre un modele de securite a defense en profondeur, structure en huit couches : autorisation des utilisateurs, approbation des commandes dangereuses, securite des ecritures fichier, isolation par conteneur, filtrage des credentials MCP, detection d'injection dans les fichiers de contexte, isolation inter-sessions et assainissement des entrees.

Cette page couvre les dix questions essentielles que tout operateur doit maitriser pour deployer Hermes Agent en production. Chaque reponse est sourcee a partir de la documentation officielle et du depot GitHub, figes au commit b4f8c491.

Questions couvertes

q-091: Comment Hermes Agent detecte-t-il les commandes dangereuses ?

Hermes Agent utilise deux mecanismes complementaires pour detecter les commandes dangereuses avant leur execution.

1. Detection par patterns (approval.py). Avant d'executer une commande shell, Hermes la confronte a une liste de patterns dangereux definis dans le fichier tools/approval.py. Les patterns couvrent notamment :

• Suppressions recursives (rm -r, rm --recursive)
• Ecritures sur peripheriques bloc (> /dev/sd*, dd if=)
• Formatage de systemes de fichiers (mkfs)
• Modifications de permissions dangereuses (chmod 777, chmod o+w)
• Commandes SQL destructrices (DROP TABLE, DELETE FROM sans WHERE, TRUNCATE)
• Arret/redemarrage de services systeme (systemctl stop/restart/disable)
• Kill de processus (kill -9 -1, pkill -9)
• Fork bombs
• Execution de shell arbitraire (bash -c, sh -c, python -c, perl -e)
• Pipe de contenu distant vers un shell (curl ... | sh, wget ... | bash)
• Ecrasement de fichiers sensibles (tee ou > vers /etc/, ~/.ssh/, ~/.hermes/.env)
• Auto-terminaison (pkill hermes, killall gateway)
• Commandes Docker/Podman distantes (docker -H, DOCKER_HOST=, podman --remote)

2. Scanner Tirith (pre-execution). En complement du pattern matching, Hermes integre le scanner Tirith (anciennement sur github.com/NousResearch/tirith, depot archive) qui detecte des menaces que les patterns seuls ne captent pas : spoofing d'URL par homoglyphes, patterns pipe-to-interpreter et attaques par injection terminal. Tirith s'auto-installe depuis les releases GitHub avec verification SHA-256. Il est active par defaut (security.tirith_enabled: true) et fonctionne en mode fail-open : si Tirith est indisponible, les commandes passent quand meme (sauf si tirith_fail_open: false).

Source : Security guide -- Dangerous Command Approval, Tirith Pre-Exec Security Scanning

q-092: Quelle difference entre les modes d'approbation smart, manual et off ?

Les trois modes d'approbation, configures via approvals.mode dans ~/.hermes/config.yaml, determinent comment Hermes Agent reagit face a une commande classee comme dangereuse :

En CLI interactive, l'invite d'approbation propose quatre choix : [o]nce (cette execution), [s]ession (pour toute la session), [a]lways (ajout a la liste blanche permanente dans config.yaml), [d]eny (bloquer, choix par defaut).

Sur les plateformes de messagerie (Telegram, Discord, etc.), l'agent envoie les details de la commande dans le chat et attend une reponse : yes/approve/ok/go pour approuver, no/deny/cancel pour refuser.

Un delai d'expiration configurable (approvals.timeout, defaut 300 secondes) s'applique : sans reponse, la commande est refusee (fail-closed). Les jobs cron ont leur propre regle (approvals.cron_mode, defaut deny).

Source : Security guide -- Approval Modes, Configuration -- Smart Approvals

q-093: Que desactive reellement le mode yolo de Hermes Agent ?

Le mode YOLO (active par hermes --yolo, /yolo en session, ou HERMES_YOLO_MODE=1) desactive tous les invites d'approbation de commandes dangereuses pour la session en cours. Concretement, il contourne la couche d'approbation (smart, manual ou off) et laisse toutes les commandes s'executer sans demande de confirmation.

Ce que YOLO ne desactive pas :

• La redaction des secrets (security.redact_secrets). Les deux mecanismes sont independants. YOLO ne desactive pas le masquage automatique des cles API, tokens et secrets dans les sorties d'outils et les logs.
• La blocklist dure (hardline blocklist). Certaines commandes restent bloquees meme en YOLO (voir q-094).
• Les regles de refus utilisateur (approvals.deny). Les patterns glob definis par l'utilisateur restent actifs.
• Les confirmations de commandes slash destructrices (/clear, /new, /reset, /undo, /quit --delete). La CLI demande toujours confirmation avant d'ecraser l'etat de session, sauf si approvals.destructive_slash_confirm: false.
• La securite des ecritures fichier. Les chemins proteges et HERMES_WRITE_SAFE_ROOT restent appliques.

Lorsque YOLO est actif, Hermes affiche deux rappels visuels persistants : une banniere rouge au demarrage de session (⚠ YOLO mode -- all approval prompts bypassed) et un fragment ⚠ YOLO dans la barre de statut.

Source : Security guide -- YOLO Mode

q-094: Quelles commandes restent bloquees meme en mode yolo ?

La blocklist dure (hardline blocklist), definie dans tools/approval.py::UNRECOVERABLE_BLOCKLIST, est le plancher de securite absolu. Ces commandes sont refusees quelles que soient les conditions : --yolo, /yolo, approvals.mode: off, jobs cron en mode approve, ou clic utilisateur sur "allow always". Aucun override n'existe.

Si une commande atteint la blocklist, l'appel d'outil retourne une erreur explicative a l'agent et rien ne s'execute. Si un workflow legitime necessite l'une de ces commandes (ex. pipeline de reinstallation automatise), l'operateur doit l'executer en dehors de l'agent.

En complement, les regles de refus utilisateur (approvals.deny) permettent de definir ses propres patterns glob (fnmatch, insensibles a la casse) qui bloquent des commandes meme en YOLO. Exemple :

approvals:
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

Source : Security guide -- Hardline Blocklist, User-Defined Deny Rules

q-095: Comment isoler les commandes Hermes Agent dans Docker ?

Pour isoler les commandes de l'agent du systeme hote, configurez le backend terminal Docker dans ~/.hermes/config.yaml :

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_forward_env: []  # Liste blanche explicite ; vide = aucun secret dans le conteneur
  container_cpu: 1
  container_memory: 5120   # MB (defaut 5 Go)
  container_disk: 51200    # MB (defaut 50 Go)
  container_persistent: true

Chaque conteneur est lance avec des flags de securite stricts (definis dans tools/environments/docker.py) :

• --cap-drop ALL : suppression de toutes les capabilities Linux
• --cap-add DAC_OVERRIDE,CHOWN,FOWNER : uniquement les capabilities necessaires
• --security-opt no-new-privileges : blocage de l'escalade de privileges
• --pids-limit 256 : limite du nombre de processus
• --tmpfs /tmp:rw,nosuid,size=512m : /tmp en memoire, taille limitee
• --tmpfs /var/tmp:rw,noexec,nosuid,size=256m : /var/tmp sans execution

L'image Docker officielle (nousresearch/hermes-agent) execute le gateway en tant qu'utilisateur non privilegie hermes (uid 10000).

Important : Lorsque le backend est docker (ou singularity, modal, daytona, vercel_sandbox), les verifications de commandes dangereuses sont sautees car le conteneur lui-meme constitue la frontiere de securite. Une commande destructive a l'interieur du conteneur ne peut pas endommager l'hote.

Pour le deploiement gateway en production, l'image Docker officielle est la methode recommandee :

docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run

Source : Security guide -- Container Isolation, Docker guide

q-096: Comment empecher un outil d'ecrire hors d'un dossier autorise ?

Hermes Agent propose deux mecanismes pour restreindre les ecritures fichier des outils write_file et patch :

1. Chemins proteges (toujours bloques). Certaines categories de chemins sont toujours refusees, meme sans configuration supplementaire :

• Stores de credentials OS : ~/.ssh/, ~/.aws/, ~/.kube/, /etc/sudoers, ~/.netrc
• Stores de credentials Hermes : auth.json, .env, .anthropic_oauth.json, mcp-tokens/, pairing/ sous HERMES_HOME
• Fichiers de secrets projet : .env, .env.local, .env.production, .envrc n'importe ou sur le disque

2. HERMES_WRITE_SAFE_ROOT (sandbox optionnel). Cette variable d'environnement definit un ou plusieurs prefixes de repertoire autorises. Toute ecriture hors de ces prefixes est bloquee durement, sans passer par l'approbation de commandes dangereuses.

# Restreindre a un seul projet
export HERMES_WRITE_SAFE_ROOT=/home/user/mon-projet

# Plusieurs racines (separes par : sur Unix, ; sur Windows)
export HERMES_WRITE_SAFE_ROOT=/home/user/projet:/home/user/.hermes

Cette variable est automatiquement positionnee a HERMES_WRITE_SAFE_ROOT=/opt/data dans l'image Docker officielle. Les chemins sensibles restent bloques meme a l'interieur de la racine autorisee : pointer HERMES_WRITE_SAFE_ROOT vers $HOME ne permet pas d'ecrire dans ~/.ssh/id_rsa.

Limite importante : Ces garde-fous s'appliquent uniquement aux outils write_file et patch. L'outil terminal s'execute avec les memes droits que l'utilisateur OS et peut toujours ecrire ou ecraser des chemins refuses via des commandes shell (cat, >, tee). La denylist reduit les degats accidentels et donne un signal d'arret clair au modele ; elle ne constitue pas un sandbox contre un agent hostile.

Source : Security guide -- File Write Safety

q-097: Comment proteger les secrets transmis aux outils et conteneurs ?

Hermes Agent applique une protection multicouche des secrets :

1. Redaction automatique des secrets. Activee par defaut (security.redact_secrets: true), elle scanne les sorties d'outils (stdout terminal, read_file, contenu web, resumes de sous-agents) pour y detecter les motifs de cles API, tokens et secrets avant leur entrees dans le contexte de conversation et les logs. Cette redaction est independante du mode YOLO et necessite un redemarrage de session pour etre modifiee.

2. Filtrage des variables d'environnement par sandbox.

3. Passthrough des variables d'environnement. Les skills qui declarent required_environment_variables dans leur frontmatter voient ces variables automatiquement transmises aux sandboxes execute_code, terminal (local et Docker/Modal). Pour les variables non declarees par un skill, utilisez terminal.env_passthrough dans config.yaml.

4. Fichiers de credentials. Les skills peuvent declarer required_credential_files dans leur frontmatter. Ces fichiers sont montes en lecture seule (-v host:container:ro) dans les conteneurs Docker et synchronises dans les sandboxes Modal.

5. Filtrage MCP. Les sous-processus MCP recoivent un environnement filtre : seuls PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR et les variables XDG_* sont transmis. Les messages d'erreur des outils MCP sont assainis (GitHub PATs, cles OpenAI, bearer tokens, parametres token=, key=, password=, secret= sont remplaces par [REDACTED]).

6. Secrets dans .env, configuration dans config.yaml. Les cles API, tokens de bot et mots de passe doivent etre stockes dans ~/.hermes/.env (permissions chmod 600), jamais dans config.yaml. La commande hermes config set CLE_API valeur route automatiquement les cles API vers .env.

Source : Security guide -- Environment Variable Passthrough, MCP Credential Handling, Skill security-privacy reference

q-098: Comment controler qui peut parler au gateway Hermes Agent ?

Le gateway Hermes Agent utilise un systeme d'autorisation en couches, verifie dans cet ordre :

1. Flag allow-all par plateforme (ex. DISCORD_ALLOW_ALL_USERS=true)
2. Liste des utilisateurs approuves par pairing DM
3. Allowlist specifique a la plateforme (ex. TELEGRAM_ALLOWED_USERS=12345,67890)
4. Allowlist globale (GATEWAY_ALLOWED_USERS=12345,67890)
5. Flag allow-all global (GATEWAY_ALLOW_ALL_USERS=true)
6. Defaut : refuser

Les allowlists se configurent dans ~/.hermes/.env :

# Allowlists par plateforme
TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=111222333444555666
WHATSAPP_ALLOWED_USERS=15551234567

# Allowlist globale (verifiee pour toutes les plateformes)
GATEWAY_ALLOWED_USERS=123456789

Si aucune allowlist n'est configuree et que GATEWAY_ALLOW_ALL_USERS n'est pas active, tous les utilisateurs sont refuses. Le gateway logue un avertissement au demarrage.

Systeme de pairing DM. Pour une autorisation plus flexible, Hermes propose un systeme de pairing par code :

1. Un utilisateur inconnu envoie un DM au bot
2. Le bot repond avec un code de pairing de 8 caracteres (alphabet non ambigu de 32 caracteres, sans 0/O/1/I)
3. L'operateur approuve avec hermes pairing approve telegram ABC12DEF
4. L'utilisateur est approuve de maniere permanente pour cette plateforme

Securite du pairing : codes cryptographiques (secrets.choice()), TTL de 1 heure, rate limiting (1 requete par utilisateur par 10 minutes), maximum 3 codes en attente par plateforme, verrouillage d'1 heure apres 5 echecs, permissions chmod 0600 sur les fichiers de pairing, codes jamais loggues.

Comportement des DMs non autorises (configurable dans config.yaml) : pair (defaut, envoie un code de pairing), ignore (silence). L'email a ignore par defaut.

Attention Docker : L'image officielle execute le gateway en tant qu'utilisateur hermes (uid 10000). Les commandes de pairing doivent etre lancees avec docker exec -u hermes.

Source : Security guide -- User Authorization, DM Pairing System

q-099: Comment auditer les dependances, plugins et MCP avec hermes security ?

La commande hermes security audit effectue un scan de vulnerabilites a la demande contre la base OSV.dev. Elle couvre trois cibles :

Options de la commande :

hermes security audit                  # Scan complet, sortie lisible
hermes security audit --json           # Sortie JSON pour integration CI
hermes security audit --fail-on high   # Exit non-zero si une vulnerabilite haute ou critique
hermes security audit --skip-venv      # Ignorer le venv Python
hermes security audit --skip-plugins   # Ignorer les plugins
hermes security audit --skip-mcp       # Ignorer les serveurs MCP

Le scan ne couvre pas les packages installes globalement ni les extensions d'editeur/navigateur.

Verification des advisories de supply-chain. Au demarrage, Hermes scanne les packages Python du venv actif contre un catalogue d'advisories connus (ex. versions compromises comme mistralai 2.4.6). Une alerte est affichee dans la banniere de demarrage CLI, dans hermes doctor et dans gateway.log. Chaque advisory a un identifiant stable ; une fois traitee, elle peut etre acquittee de maniere permanente :

hermes doctor --ack <advisory-id>

Securite des installations lazy. Les dependances optionnelles (Mistral TTS, ElevenLabs, Slack, Matrix, etc.) sont installees a la demande (security.allow_lazy_installs: true par defaut). Garanties de securite : installation scope au venv uniquement, PyPI par nom seulement (pas de --index-url, git+https:// ou file:), allowlist stricte (LAZY_DEPS in-tree), pas de retry silencieux. Pour desactiver : security.allow_lazy_installs: false.

Source : CLI Commands Reference -- hermes security, Security guide -- Supply-chain advisory checking

q-100: Quelles donnees de telemetrie Hermes Agent envoie-t-il ?

Hermes Agent est un logiciel open source (licence MIT) concu pour un fonctionnement local-first. Selon la FAQ officielle, les conversations, la memoire et les skills sont stockes localement dans ~/.hermes/.

Aucune telemetrie n'est envoyee a Nous Research par defaut. Le projet ne comporte pas de mecanisme de collecte de donnees d'usage, de tracking ou de telemetrie integre. Les seules donnees qui quittent votre machine sont :

• Les appels aux providers IA (OpenRouter, Anthropic, OpenAI, etc.) que vous avez configures : vos prompts et l'historique de conversation sont transmis au provider que vous avez choisi, selon ses propres conditions d'utilisation et de confidentialite.
• Les appels aux API externes que l'agent effectue dans le cadre de ses taches (recherche web, extraction de contenu, appels MCP, etc.).
• Les telechargements de mises a jour (hermes update) et d'installation de dependances (pip install).

Donnees stockees localement : Toutes les sessions de conversation, la memoire persistante, les skills, la configuration et les logs sont stockes dans ~/.hermes/. Les logs (~/.hermes/logs/) beneficient de la redaction automatique des secrets.

PII redaction (gateway). Sur les plateformes de messagerie, l'option privacy.redact_pii: true hache les identifiants utilisateur et les numeros de telephone avant leur transmission au LLM. Les hashs sont deterministes (un meme utilisateur produit toujours le meme hash), ce qui permet au modele de distinguer les utilisateurs dans les chats de groupe sans connaitre leur identite reelle.

Source : FAQ officielle -- Is my data sent anywhere?, Configuration -- Privacy

Sources

• Documentation officielle Hermes Agent
• Guide de securite officiel
• Reference des commandes CLI
• FAQ officielle
• Depot GitHub NousResearch/hermes-agent, commit b4f8c491
• Guide Docker officiel
• Guide de configuration officiel

Liens internes proposes

• Configurer Hermes Agent
• Confidentialite
• Outils et MCP
• Installer Hermes Agent
• Sources
• Methodologie