Déployer Hermès Agent en environnement maîtrisé : backends sandboxés et persistance serverless

Hermès Agent propose six backends d'exécution (local, Docker, SSH, Singularity, Modal, Daytona) qui déterminent où les commandes de l'agent s'exécutent réellement, et donc quel est le rayon d'explosion en cas de dérapage. Le backend par défaut (local) n'isole rien.

Quels backends d'exécution Hermès Agent propose-t-il ?

Depuis la version v0.15.0 (qui a « pluginifié » les adaptateurs et retiré le backend Vercel Sandbox), Hermès supporte six backends. La configuration se fait dans ~/.hermes/config.yaml (terminal.backend) ou à la volée (hermes --sandbox modal).

Backend	Isolation	Latence	Coût	Cas d'usage entreprise
local	Aucune (host direct)	Nulle	Gratuit	À éviter en production ; démo/POC isolé uniquement
Docker	Conteneur (root read-only, capabilities droppées, limites CPU/mémoire/disque)	Faible	Gratuit	Défaut recommandé pour la plupart des déploiements
SSH	Host distant	Réseau	Coût du serveur	Déléguer les traitements lourds sur une machine dédiée
Singularity/Apptainer	Conteneur SIF (--containall --no-home)	Faible	Coût cluster	Environnements HPC / recherche
Modal	Sandbox cloud serverless (isolation gVisor)	Cold start ~200 ms	Paiement à la seconde	Charges GPU, calcul intensif ponctuel
Daytona	Workspace managé, stop/resume	Quelques centaines de ms au réveil	Quasi nul à l'idle (hibernation)	Agent « toujours là » à coût minimal entre les sessions

Daytona et Modal offrent une persistance serverless : l'environnement hiberne quand il est inactif et se réveille à la demande. Sur Modal, la persistance snapshote le système de fichiers (suivi dans ~/.hermes/modal_snapshots.json) et ne préserve pas les processus vivants, l'espace PID ni les jobs en arrière-plan. Sur Daytona, les sandboxes sont stoppées (non supprimées) au nettoyage et reprises à la session suivante, avec une limite de disque de 10 Gio.

Pourquoi le backend local est-il dangereux par défaut ?

La politique de sécurité officielle de Hermès (SECURITY.md, réécrite par Jeffrey Quesnelle dans la PR #20317) est d'une honnêteté rare : « The only security boundary against an adversarial LLM is the operating system. Nothing inside the agent process constitutes containment — not the approval gate, not output redaction, not any pattern scanner, not any tool allowlist. »

Autrement dit, l'approval gate de Hermès (qui détecte les commandes shell destructrices courantes comme rm -rf ou curl | sh et demande confirmation) est qualifié d'heuristique : « the gate catches cooperative-mode mistakes, not adversarial output ». C'est un garde-fou contre les accidents, pas une défense contre un agent compromis. En backend local, le rayon d'explosion d'une commande malveillante est le host entier, avec les droits de l'utilisateur qui exécute Hermès.

Comment configurer Docker, Modal et Daytona pour la production ?

Docker en backend d'exécution (terminal.backend: docker) : Hermès réutilise un conteneur unique et durable pour tous les appels d'outils, monte le répertoire des skills et les fichiers de credentials déclarés en volumes read-only. L'image officielle (nousresearch/hermes-agent:latest) embarque un jeu d'utilitaires curatés ; s6-overlay v3 supervise les gateways avec redémarrage automatique. Les clés fournisseur (OPENAI_API_KEY, etc.) sont exclues de l'environnement via _HERMES_PROVIDER_ENV_BLOCKLIST pour éviter les fuites.

Modal / Daytona : renseigner les credentials (MODAL_TOKEN_ID, DAYTONA_API_KEY) via hermes setup ou hermes config set. Activer container_persistent: true pour préserver l'état filesystem entre les recréations. Vérifier la configuration avec hermes doctor.

Terminal-backend isolation ou whole-process wrapping : quelle stratégie ?

La communauté technique (DEV Community, node9) distingue deux stratégies de sandboxing :

• Terminal-backend isolation : ne sandboxe que le shell (outils terminal, read_file, write_file, patch). Ne confine pas l'outil d'exécution de code (subprocess host), les serveurs MCP, plugins, hooks et le chargement des skills, qui restent dans le process Python de l'agent.
• Whole-process wrapping : sandboxe tout l'arbre de processus de l'agent. Deux options : l'image Docker/Compose du projet (léger), ou NVIDIA OpenShell (sandboxes par session avec politique déclarative filesystem/réseau L7/syscall + routage d'inférence). Pour un déploiement d'entreprise contraint, visez le whole-process wrapping, voir Souveraineté et Déploiements durcis.

FAQ

Combien de backends Hermès supporte-t-il aujourd'hui ? Six, depuis v0.15.0 (Vercel Sandbox a été retiré). Attention aux articles anciens qui en mentionnent sept.

Le backend Docker suffit-il pour un usage entreprise ? Il isole le shell et constitue un bon défaut, mais ne confine ni le code-execution tool ni les MCP/plugins. Pour une isolation forte, combiner whole-process wrapping (OpenShell) et host dédié.

Peut-on désactiver totalement le sandboxing ? Oui (local), mais l'approval gate reste alors la seule barrière, ce qui est insuffisant face à un LLM adverse.

---

Sources

• hermes-agent.nousresearch.com/docs/user-guide/configuration
• hermes-agent.nousresearch.com/docs/user-guide/docker
• github.com/NousResearch/hermes-agent (SECURITY.md, README)
• modal.com/resources/best-code-execution-sandbox-hermes
• deepwiki.com/NousResearch/hermes-agent
• dev.to/node9_ai