Hermes Agent : huit couches de sécurité, un mode qui les efface toutes
Ce qu'une PME doit vérifier avant de déployer un agent IA autonome en production
Image générée par IA (art. 50 AI Act)
Analyse 2LKATIME
Nos auditeurs certifiés OSCP/OSEP passent régulièrement au crible les agents IA autonomes avant leur déploiement en entreprise. Voici ce que révèle un examen attentif de l'architecture de sécurité de Hermes Agent, l'agent développé par Nous Research.
Un agent qui exécute du code sans supervision, c'est un stagiaire à qui vous confiez les clés du coffre
Sauf qu'il ne dort jamais, qu'il tourne sur un serveur accessible depuis Telegram ou Slack, et qu'un seul réglage mal compris peut le priver de tout garde-fou. Comprendre où se situe ce réglage, avant de déployer, évite bien des mauvaises surprises.
Hermes Agent, l'agent IA autonome développé par Nous Research, tourne sur six environnements d'exécution différents, se connecte à plus de vingt plateformes de messagerie et peut exécuter du code de façon autonome via un outil intégré. Sur le papier, de quoi inquiéter n'importe quel responsable sécurité.
Après lecture attentive de sa documentation technique, le constat est plus nuancé qu'attendu : l'architecture de sécurité est réellement bien pensée, avec huit familles de contrôles qui se complètent. Le vrai point de vigilance n'est pas l'outil, c'est un réglage précis qui peut désactiver presque tout ce dispositif d'un coup, et qu'on retrouve activé par erreur plus souvent qu'on ne le pense.
1. Qu'est-ce que Hermes Agent
Hermes Agent se présente comme un agent IA "auto-améliorant" : il crée ses propres compétences à partir de l'expérience, les perfectionne à l'usage, et conserve une mémoire persistante d'une session à l'autre. Contrairement à un simple chatbot, il agit de façon autonome sur un environnement d'exécution réel, capable d'exécuter des commandes système, de programmer des tâches automatiques et de communiquer via des dizaines de canaux différents.
8
Couches de sécurité intégrées
6
Backends d'exécution (local, Docker, SSH, cloud)
20+
Plateformes de messagerie connectables
1
Réglage capable de désactiver presque tout
Nous avions déjà comparé son positionnement face à un concurrent dans notre comparatif Hermes Agent vs OpenClaw. Cet article-ci va plus loin : il s'agit d'auditer, avec un regard de pentesteur, ce que Nous Research affirme sur sa propre sécurité.
2. Ce qui est bien fait : huit couches de sécurité qui se complètent
Avant de pointer le problème, il faut reconnaître ce qui fonctionne. Le modèle de sécurité documenté par Nous Research repose sur huit familles de contrôles distinctes, qui interviennent chacune à un niveau différent : autorisation des utilisateurs, approbation humaine des commandes dangereuses, protection des écritures fichiers, isolation conteneur, filtrage des identifiants transmis aux serveurs MCP, protection contre les attaques SSRF, scan anti-injection de prompt dans les fichiers de contexte, et isolation entre sessions.
Les huit couches officielles regroupées en six familles de contrôles. La couche 2 est la seule que le mode YOLO neutralise entièrement.
Points forts réels
- - Protection SSRF complète, y compris contre l'accès aux metadata cloud
- - Scanner "Tirith" qui détecte les commandes suspectes avant exécution
- - Filtrage strict des identifiants transmis aux sous-processus MCP
- - Détection d'injection de prompt dans les fichiers de contexte
Ce que ça ne couvre pas
- - L'outil "terminal" contourne le denylist d'écriture de fichiers
- - Les backends conteneurisés désactivent totalement la vérification des commandes dangereuses
- - Rien ne vérifie l'identité réelle derrière un compte de messagerie autorisé
3. Le mode YOLO, le vrai point de bascule
Le mode YOLO (activable via le flag --yolo, la commande /yolo en cours de session, ou la variable d'environnement HERMES_YOLO_MODE=1) désactive toutes les approbations de commandes dangereuses. Il ne reste qu'une liste "hardline" minimale et figée dans le code, réservée aux catastrophes évidentes : suppression de la racine du système, formatage d'un disque monté, bombe fork. Tout le reste, y compris une suppression SQL sans clause WHERE, un chmod 777 ou l'arrêt d'un service système, passe sans validation humaine.
Les modes smart et manual passent tous deux par une étape de vérification. Le mode YOLO exécute directement, sans aucun contrôle intermédiaire.
Le piège le plus fréquent chez une TPE sans équipe IT dédiée n'est pas d'activer YOLO consciemment, mais de régler approvals.cron_mode sur approve pour éviter que les tâches automatiques ne se bloquent en attente d'une validation humaine absente la nuit. Concrètement, cela revient à activer YOLO en permanence sur tout ce qui tourne sans surveillance, un réglage qu'on active une fois "pour que ça marche tout seul" et qu'on oublie ensuite.
Autre nuance importante : dans les backends conteneurisés (Docker, Modal, Singularity), la vérification des commandes dangereuses est purement et simplement ignorée par conception, au motif que le conteneur lui-même fait office de barrière de sécurité. C'est un choix d'architecture défendable, à condition que la configuration du conteneur (limites de ressources, variables d'environnement transmises, montages de volumes) ait elle-même été auditée. Un conteneur mal configuré n'offre pas la protection qu'on lui suppose.
4. Conformité RGPD et AI Act : ce que ça implique
Un agent IA autonome connecté à des plateformes de messagerie et capable d'exécuter des commandes soulève des questions de conformité au-delà de la seule sécurité technique. L'autorisation des utilisateurs (qui peut parler à l'agent) touche directement à la protection des données transmises dans les conversations. Un agent mal configuré, accessible sans restriction (GATEWAY_ALLOW_ALL_USERS=true), expose potentiellement des données professionnelles à n'importe qui découvrant l'adresse du bot.
Côté AI Act, un agent qui prend des décisions d'exécution de façon autonome, même encadrées, entre dans le champ des systèmes qu'il convient de documenter et de superviser humainement de façon démontrable, un principe que nous détaillons dans notre checklist de mise en conformité AI Act pour PME.
5. Comment 2LKATIME accompagne le déploiement d'un agent IA
Avant toute mise en production d'un agent autonome comme Hermes Agent, nos auditeurs vérifient systématiquement le backend d'exécution retenu, les réglages d'approbation des commandes (jamais YOLO en production, jamais cron_mode: approve sans supervision), les listes d'utilisateurs autorisés, et le comportement réel des tâches automatisées sur plusieurs jours de test. Cette vérification s'inscrit dans notre offre Bilan Express, ou dans un audit plus complet selon la complexité du déploiement envisagé. Nous intervenons aussi bien à Paris qu'à Lyon ou Bordeaux.
FAQ - Sécurité des agents IA autonomes
Hermes Agent est-il sécurisé par défaut ?
Dans sa configuration par défaut, oui : le mode d'approbation smart évalue chaque commande à risque et demande confirmation en cas de doute, les backends conteneurisés isolent l'exécution, et plusieurs couches filtrent les identifiants et détectent l'injection de prompt. Le risque apparaît quand cette configuration par défaut est modifiée, notamment avec le mode YOLO.
Qu'est-ce que le mode YOLO dans Hermes Agent ?
Le mode YOLO (activé via --yolo, /yolo ou la variable HERMES_YOLO_MODE) désactive toutes les approbations de commandes dangereuses, à l'exception d'une liste très restreinte de commandes catastrophiques toujours bloquées (suppression de la racine du système, formatage disque, bombes fork). Tout le reste s'exécute sans validation humaine.
Le mode cron peut-il activer YOLO sans qu'on s'en rende compte ?
Oui. Le paramètre approvals.cron_mode peut être mis à approve au lieu de deny par défaut, ce qui revient à activer YOLO en permanence sur toutes les tâches automatisées. C'est un réglage qu'on active une fois pour éviter les interruptions, puis qu'on oublie, sans supervision humaine ensuite.
Faut-il éviter d'utiliser des agents IA autonomes comme Hermes Agent en entreprise ?
Non, pas nécessairement. L'architecture de sécurité de Hermes Agent est plutôt bien conçue : isolation conteneur, filtrage des identifiants, protection contre les attaques SSRF, scan anti-injection de prompt. Le point de vigilance n'est pas l'outil lui-même mais sa configuration au moment du déploiement en production.
Comment vérifier la configuration de sécurité d'un agent IA avant de le déployer ?
En faisant auditer la configuration par un prestataire spécialisé en cybersécurité, capable de vérifier le backend d'exécution utilisé, les réglages d'approbation des commandes, les listes d'utilisateurs autorisés et le comportement des tâches automatisées avant toute mise en production.
Vous déployez un agent IA autonome en entreprise ?
Nos auditeurs certifiés OSCP/OSEP vérifient la configuration avant mise en production : backend d'exécution, réglages d'approbation, accès autorisés, tâches automatisées. Un diagnostic de 20 minutes suffit pour cadrer le besoin.