Sécurité et infrastructure Hermes Agent

Cette page fait partie du référence technique francophone consacré à Hermes Agent. Elle répond à l'intention de recherche : sécuriser Hermes.

Le contenu s'appuie sur la documentation officielle Hermes Agent associée à cette page. L'objectif n'est pas de remplacer la documentation de Nous Research, mais de fournir une lecture claire en français, structurée pour aller vite, avec un maillage logique vers les pages complémentaires du même site.

À retenir

Sujet principal : hermes agent sécurité.
Type de page : hub.
Cluster : securite-infra.
Source canonique : documentation officielle Hermes Agent.
Aucun lien vers l'autre domaine n'est utilisé dans cette page.

Comment utiliser cette section

Cette section regroupe les pages du cluster securite-infra. Commencez par cette page si vous voulez comprendre le sujet dans son ensemble, puis ouvrez les guides détaillés selon votre contexte.

Chaque page interne contient des liens vers les prérequis, les pages voisines et les suites logiques. Le but est de créer un parcours utile, pas une liste brute de pages SEO.

Base officielle

Hermes Agent is designed with a defense-in-depth security model. This page covers every security boundary — from command approval to container isolation to user authorization on messaging platforms.

Overview

The security model has seven layers:

User authorization — who can talk to the agent (allowlists, DM pairing)
Dangerous command approval — human-in-the-loop for destructive operations
Container isolation — Docker/Singularity/Modal sandboxing with hardened settings
MCP credential filtering — environment variable isolation for MCP subprocesses
Context file scanning — prompt injection detection in project files
Cross-session isolation — sessions cannot access each other's data or state; cron job storage paths are hardened against path traversal attacks
Input sanitization — working directory parameters in terminal tool backends are validated against an allowlist to prevent shell injection

Dangerous Command Approval

Before executing any command, Hermes checks it against a curated list of dangerous patterns. If a match is found, the user must explicitly approve it.

Approval Modes

The approval system supports three modes, configured via approvals.mode in ~/.hermes/config.yaml:

approvals:
  mode: manual                    # manual | smart | off
  timeout: 60                     # seconds to wait for user response (default: 60)
  cron_mode: deny                 # deny | approve — what cron jobs do when they hit a dangerous command
  mcp_reload_confirm: true        # /reload-mcp asks before invalidating the MCP tool cache
  destructive_slash_confirm: true # /clear, /new, /reset, /undo prompt before discarding state

The full set of keys:

Key — Default — What it controls
mode — manual — Approval policy for dangerous shell commands — see the table below.
timeout — 60 — Seconds Hermes waits for an approval reply before timing out.
cron_mode — deny — How cron jobs behave headlessly when they trigger a dangerous-command prompt. deny blocks the command (the agent must find another path); approve auto-approves everything in cron context.
mcp_reload_confirm — true — When true, /reload-mcp asks before rebuilding the MCP tool set. Rebuilding invalidates the provider prompt cache (tool schemas live in the system prompt), so the next message re-sends full input tokens. Users who click Always Approve flip this key to false.
destructive_slash_confirm — true — When true, destructive session slash commands (/clear, /new, /reset, /undo) prompt before discarding conversation state. Three-option dialog (Approve Once / Always Approve / Cancel) routed through native yes/no buttons on Telegram, Discord, and Slack; text fallback elsewhere. Users who click Always Approve flip this key to false. TUI uses its own modal overlay (set HERMES_TUI_NO_CONFIRM=1 to opt out there).

Mode — Behavior
manual (default) — Always prompt the user for approval on dangerous commands
smart — Use an auxiliary LLM to assess risk. Low-risk commands (e.g., python -c "print('hello')") are auto-approved. Genuinely dangerous commands are auto-denied. Uncertain cases escalate to a manual prompt.
off — Disable all approval checks — equivalent to running with --yolo. All commands execute without prompts.

Setting approvals.mode: off disables all safety prompts. Use only in trusted environments (CI/CD, containers, etc.).

YOLO Mode

YOLO mode bypasses all dangerous command approval prompts for the current session. It can be activated three ways:

CLI flag: Start a session with hermes --yolo or hermes chat --yolo
Slash command: Type /yolo during a session to toggle it on/off
Environment variable: Set HERMES_YOLO_MODE=1

The /yolo command is a toggle — each use flips the mode on or off:

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

> /yolo
  ⚠ YOLO mode OFF — dangerous commands will require approval.

YOLO mode is available in both CLI and gateway sessions. Internally, it sets the HERMES_YOLO_MODE environment variable which is checked before every command execution.

When YOLO is active, Hermes shows two persistent visual reminders so it's hard to forget that approval prompts are bypassed:

A red banner line at session start when YOLO is already active: ⚠ YOLO mode — all approval prompts bypassed. Hidden when YOLO is off so the default banner stays uncluttered.
A ⚠ YOLO fragment in the status bar across all width tiers, updated live as you toggle YOLO on or off (rich-text renderer and plain-text fallback).

danger

YOLO mode disables all dangerous command safety checks for the session — except the hardline blocklist (see below). Use only when you fully trust the commands being generated (e.g., well-tested automation scripts in disposable environments).

For destructive session slash commands (/clear, /new / /reset, /undo, /quit --delete — /exit --delete is an alias), the CLI also prompts for confirmation before running them. See Slash Commands — Confirmation prompts for destructive commands.

Hardline Blocklist (Always-On Floor)

Some commands are so catastrophic — irreversible filesystem wipes, fork bombs, direct block-device writes — that Hermes refuses to run them regardless of:

--yolo / /yolo toggled on
approvals.mode: off
Cron jobs running in headless approve mode
User explicitly clicking "allow always"

The blocklist is the floor below --yolo. It trips before the approval layer even sees the command, and there's no override flag. Patterns currently covered (not exhaustive; kept in sync with tools/approval.py::UNRECOVERABLE_BLOCKLIST):

Pattern — Why it's hardline
rm -rf / and obvious variants — Wipes the filesystem root
rm -rf --no-preserve-root / — The explicit "yes I mean root" variant
:(){ :\ — :& };: (bash fork bomb) — Pegs the host until reboot
mkfs.* on a mounted root device — Formats the live system
dd if=/dev/zero of=/dev/sd* — Zeroes a physical disk
Piping untrusted URLs to sh at the rootfs top level — Remote-code-execution attack vector too broad to approve

If you hit the blocklist, the tool call returns an explanatory error to the agent and nothing runs. If a legitimate workflow needs one of these commands (you're the operator of a wipe-and-reinstall pipeline, for example), run it outside the agent.

Approval Timeout

When a dangerous command prompt appears, the user has a configurable amount of time to respond. If no response is given within the timeout, the command is denied by default (fail-closed).

Configure the timeout in ~/.hermes/config.yaml:

approvals:
  timeout: 60  # seconds (default: 60)

What Triggers Approval

The following patterns trigger approval prompts (defined in tools/approval.py):

Pattern — Description
rm -r / rm --recursive — Recursive delete
rm ... / — Delete in root path
chmod 777/666 / o+w / a+w — World/other-writable permissions
chmod --recursive with unsafe perms — Recursive world/other-writable (long flag)
chown -R root / chown --recursive root — Recursive chown to root
mkfs — Format filesystem
dd if= — Disk copy
> /dev/sd — Write to block device
DROP TABLE/DATABASE — SQL DROP
DELETE FROM (without WHERE) — SQL DELETE without WHERE
TRUNCATE TABLE — SQL TRUNCATE
> /etc/ — Overwrite system config
systemctl stop/restart/disable/mask — Stop/restart/disable system services
kill -9 -1 — Kill all processes
pkill -9 — Force kill processes
Fork bomb patterns — Fork bombs
bash -c / sh -c / zsh -c / ksh -c — Shell command execution via -c flag (including combined flags like -lc)
python -e / perl -e / ruby -e / node -c — Script execution via -e/-c flag
curl ... \ — sh / wget ... \ — sh — Pipe remote content to shell
bash <(curl ...) / sh <(wget ...) — Execute remote script via process substitution
tee to /etc/, ~/.ssh/, ~/.hermes/.env — Overwrite sensitive file via tee
> / >> to /etc/, ~/.ssh/, ~/.hermes/.env — Overwrite sensitive file via redirection
xargs rm — xargs with rm
find -exec rm / find -delete — Find with destructive actions
cp/mv/install to /etc/ — Copy/move file into system config
sed -i / sed --in-place on /etc/ — In-place edit of system config
pkill/killall hermes/gateway — Self-termination prevention
gateway run with &/disown/nohup/setsid — Prevents starting gateway outside service manager

Container bypass: When running in docker, singularity, modal, or daytona backends, dangerous command checks are skipped because the container itself is the security boundary. Des

Points de vigilance

Vérifiez toujours la version active de Hermes Agent avant d'appliquer une commande ou une configuration.
Ne collez pas de clé API dans un chat public ou dans une page visible.
Gardez les secrets dans les fichiers ou gestionnaires prévus pour cela.
Si une fonctionnalité dépend d'un provider, d'un plugin ou d'une plateforme de messagerie, vérifiez que le composant est bien activé dans votre profil.
Pour une installation de production, testez d'abord le flux complet sur une machine ou un profil isolé.

Exemple de parcours logique

Lire la page courante pour comprendre hermes agent sécurité.
Ouvrir le hub parent du cluster securite-infra.
Passer ensuite aux pages complémentaires proposées dans « À lire ensuite ».
Revenir à la documentation officielle si vous avez besoin du détail exact ou d'une commande récemment modifiée.

FAQ rapide

Cette page remplace-t-elle la documentation officielle ?

Non. Elle sert de guide francophone structuré. Le lien vers la source officielle est disponible en bas de page.

Les commandes sont-elles garanties à jour ?

Elles sont basées sur la documentation officielle récupérée au moment de la génération. Pour un usage critique, vérifiez toujours la page officielle liée en bas.

Pourquoi autant de liens internes ?

Hermes Agent est un système modulaire. L'installation, les providers, les outils, la mémoire, les skills, la sécurité et les plateformes se répondent. Le maillage interne aide à suivre ce chemin sans tomber sur des pages orphelines.

Comment lire cette page efficacement

Commencez par identifier votre situation : installation locale, usage serveur, configuration d'un provider, connexion à une plateforme, automatisation ou usage développeur. Hermes Agent est modulaire : une fonctionnalité dépend souvent d'un autre bloc. Par exemple, une automatisation cron devient réellement utile quand le modèle, les outils et le canal de livraison sont déjà configurés.

Pour éviter les erreurs, avancez toujours dans cet ordre : vérifier le prérequis, appliquer la commande ou la configuration, relancer une session si nécessaire, puis tester avec une action simple. Si le résultat ne correspond pas à ce qui est attendu, revenez à la page officielle liée en bas et comparez la version de votre installation avec la documentation actuelle.

Bonnes pratiques

Garder une configuration minimale tant que le premier test n'est pas validé.
Ajouter les outils et plateformes progressivement.
Séparer les profils si plusieurs usages doivent cohabiter.
Documenter les procédures répétées dans des skills plutôt que dans de longs prompts.
Vérifier les droits, tokens et scopes avant d'accuser le modèle ou Hermes Agent.
Relancer la session après un changement de configuration important.

Erreurs fréquentes

La première erreur consiste à activer trop de choses trop tôt. Plus la configuration initiale est large, plus le diagnostic devient difficile. La deuxième erreur consiste à confondre un problème de provider avec un problème Hermes : si le modèle ne répond pas, vérifiez d'abord l'authentification, la clé API, le nom du modèle et le provider sélectionné. La troisième erreur consiste à oublier que certains changements ne s'appliquent qu'à une nouvelle session ou après redémarrage du gateway.

Suite recommandée

Après cette page, ouvrez les liens internes proposés dans la section « À lire ensuite ». Ils ont été choisis pour suivre une progression logique dans le même site, sans envoyer vers l'autre domaine.

Approfondissement (1)

Hermes Agent est conçu pour évoluer. Les commandes et configurations présentées ici peuvent changer avec les versions. Pour rester à jour, consultez régulièrement la documentation officielle liée en bas de page, et testez chaque mise à jour dans un environnement isolé avant de la déployer en production.

Les compétences avancées — orchestration multi-agents, skills personnalisées, intégrations MCP, automatisation cron — s'ajoutent progressivement. Ne tentez pas de tout configurer en une seule session. Construisez votre configuration brique par brique, en validant chaque étape.

Si vous rencontrez un comportement inattendu, vérifiez d'abord les points les plus simples : version installée, provider sélectionné, clés API valides, profil actif. La majorité des problèmes viennent d'un de ces quatre points. Seulement après les avoir éliminés, explorez les logs, les skills et la configuration avancée.

Pour aller plus loin, explorez les sections voisines du site. Chaque page est conçue pour répondre à une intention précise, et le maillage interne permet de construire une compréhension complète sans sauter d'étape. La documentation officielle reste la référence pour les détails techniques exacts, les signatures de commande et les valeurs de configuration.

Bonnes pratiques complémentaires : gardez un profil de test distinct du profil de production, sauvegardez vos configurations avant chaque changement majeur, et notez les commandes qui fonctionnent dans un fichier de référence local. Ces réflexes simples évitent la plupart des situations de blocage.

Sécurité et infrastructure Hermes Agent