Hermes Agent : les erreurs de sécurité les plus bêtes et les plus coûteuses

Quand Hermes commence à toucher à de vrais fichiers, de vrais flux et de vraies intégrations, les problèmes de sécurité ne viennent presque jamais d’un scénario spectaculaire. Ils viennent d’un token laissé au mauvais endroit, d’un tool trop ouvert, d’un serveur MCP branché à l’arrache, ou d’une sortie externe oubliée dans un coin.

C’est ça, le sujet ici. Pas un grand discours de hardening. Pas une doc sécurité corporate. Juste les erreurs les plus banales, et donc les plus coûteuses, autour d’un usage réel d’Hermes Agent.

Ce que tu auras à la fin
Une grille simple pour repérer les erreurs de sécurité les plus courantes autour d’Hermes, des exemples concrets de mauvais réflexes, et une hygiène tenable pour éviter l’essentiel des ennuis sans transformer ton setup en bunker.

Pourquoi les plus gros problèmes viennent souvent d’erreurs simples

Les vrais dégâts arrivent rarement par une attaque de cinéma. Ils arrivent quand plusieurs petites négligences se croisent :

• un secret en clair dans un fichier de travail
• un accès trop large donné “pour aller plus vite”
• un tool puissant laissé actif après un test
• un serveur MCP branché sans relecture
• une sortie externe qui continue de tourner alors que le contexte a changé

Pris un par un, ces écarts paraissent bénins. Empilés, ils fabriquent une surface de risque bien plus concrète que n’importe quel fantasme de prise de contrôle totale.

La règle de fond est simple : la sécurité pratique bat la sécurité théorique. Un setup imparfait mais relu vaut mieux qu’un setup prétendument propre que plus personne ne comprend.

Le piège du “c’est local donc c’est safe”

Le local t’apporte une vraie chose : par défaut, tout ne part pas chez un provider externe. C’est important. Mais ça ne rend pas ton setup sûr tout seul.

Un agent local peut quand même :

• lire plus que prévu
• écrire au mauvais endroit
• traîner près de secrets mal rangés
• s’appuyer sur un tool ou un serveur MCP trop large
• envoyer dehors quelque chose que tu avais oublié de considérer comme une sortie externe

Le mauvais raisonnement, c’est : “ça reste chez moi, donc je peux relâcher la garde.”

C’est là que commencent les erreurs les plus bêtes : tu laisses un token dans une config parce que “personne ne voit la machine”, tu ouvres un dossier parent entier parce que “c’est plus pratique”, tu gardes un tool d’écriture actif parce que “ça peut resservir”.

Le local protège une partie du périmètre. Il ne dispense ni de cadrer les accès, ni de ranger les secrets, ni de surveiller ce qui peut sortir.

Les secrets mal stockés

C’est encore la faute la plus classique. Et elle coûte toujours plus cher qu’elle n’en a l’air.

Le vrai problème, ce n’est pas seulement qu’un secret puisse fuiter vers l’extérieur. C’est aussi qu’il devienne lisible par trop d’endroits dans ton propre setup. Un token en clair dans un fichier banal finit tôt ou tard dans le champ de vision d’un tool, d’un export, d’une sauvegarde, d’un script de test ou d’un bout de repo.

Où les secrets finissent par traîner

Les endroits typiques sont toujours les mêmes :

• un .env copié à côté du projet “temporairement”
• un script de test avec une clé en dur
• un fichier de config trop bavard
• une note locale avec un copier-coller vite fait
• un historique de commandes ou un vieux brouillon jamais nettoyé
• un dossier d’archives ou de backup relu par personne

Mauvais réflexe

“Je mets la clé ici pour aujourd’hui, je rangerai après.”

Réflexe propre

Le secret vit dans un endroit dédié, sobre, et il n’est pas recopié partout juste pour gagner trois minutes.

Quelques règles simples suffisent déjà :

• un secret n’a rien à faire dans un fichier versionné
• un secret n’a rien à faire dans un exemple partagé
• un secret qui ne sert plus doit être révoqué, pas laissé dormir
• une config visible par l’agent ne doit contenir que le strict nécessaire

Petit check utile, sobre, et sans magie, quand tu veux faire un tour rapide dans un repo :

Sous shell Unix, WSL ou Git Bash :

git grep -nE 'API_KEY|TOKEN|SECRET|PASSWORD'
find . -maxdepth 3 -name ".env" -o -name "*.env*" -o -name "*secret*" | sort

Ce n’est pas un audit. C’est juste une lampe torche. Et souvent, ça suffit déjà à voir où ça déborde.

Les permissions trop larges

Deuxième classique : ouvrir trop large par confort.

Exemples typiques :

• donner accès à un dossier parent entier alors qu’un sous-dossier suffit
• laisser un tool lire toute la home alors que le travail se fait dans un seul répertoire
• embarquer un répertoire de travail avec, autour, des archives, des exports, des clés ou d’autres projets

Le souci n’est pas “l’intention” du modèle. Le souci, c’est la diffusion. Plus le périmètre est large, plus il devient facile qu’un fichier sans rapport avec la tâche se retrouve lu, résumé, déplacé, copié ou inclus dans un flux.

Périmètre trop large
“Le tool voit ~/ parce que c’est plus simple.”

Périmètre propre
“Le tool voit seulement le dossier utile à cette tâche, rien de plus.”

Périmètre trop large
“Je donne accès au dossier parent du projet, comme ça je suis tranquille.”

Périmètre propre
“Je donne accès au repo ou au sous-dossier concerné, pas au reste.”

Le bon réflexe, c’est : périmètre minimum viable, pas périmètre confortable.

Plus tu poses un cadre précis tôt, moins tu auras à réparer plus tard.

Les tools trop permissifs

Un tool actif, ce n’est pas un décor. C’est une capacité réelle donnée à l’agent.

Le mauvais réflexe, c’est d’activer large “au cas où” :

• lecture large alors qu’il faut juste un répertoire
• écriture activée alors que tu veux d’abord observer
• exécution laissée disponible après une phase de test
• sortie externe branchée alors qu’aucune tâche du jour ne l’exige

Un tool puissant n’est pas forcément mauvais. Il devient mauvais quand il reste ouvert sans besoin clair.

Avant d’activer un tool puissant

• Est-ce que j’en ai besoin maintenant, ou juste “un jour” ?
• Est-ce qu’il peut lire, écrire, exécuter ou envoyer ?
• Sur quel périmètre exact ?
• Est-ce que je suis prêt à le couper dès que la tâche est finie ?

Une règle simple tient bien dans le temps : par défaut, on lit d’abord, on brouillonne ensuite, on agit seulement quand c’est justifié.

MCP branché sans vrai cadrage

Le sujet est déjà couvert dans Hermes Agent : comprendre MCP et brancher un premier serveur proprement. Ici, on ne refait pas le cours. On regarde juste l’erreur sécurité la plus banale : brancher un serveur MCP, constater que “ça marche”, puis l’oublier.

Le cas classique :

• tu testes un serveur MCP filesystem
• tu le pointes trop large pour aller vite
• tu gardes la config telle quelle
• trois semaines plus tard, tu ne sais plus précisément ce qu’il voit ni pourquoi il est encore là

Même logique avec un connecteur externe :

• tu branches pour un besoin précis
• tu utilises un token avec plus de droits que nécessaire
• tu ne reviens jamais réduire le périmètre
• le serveur reste actif alors que le cas d’usage a disparu

Un serveur MCP oublié n’est pas neutre. C’est une couche de plus entre l’agent et quelque chose de réel.

Le minimum sain, à froid, c’est de pouvoir répondre simplement à trois questions :

• qu’est-ce qu’il voit ?
• qu’est-ce qu’il peut faire ?
• pourquoi est-il encore branché aujourd’hui ?

Si l’une des trois réponses devient floue, il faut relire ou couper.

Les sorties externes non réfléchies

Le tuto sur le local et l’externe traite déjà l’arbitrage. Ici, le problème est plus simple : une sortie externe ne devient pas dangereuse parce qu’elle existe. Elle le devient quand elle cesse d’être un choix conscient.

Les dérives typiques ressemblent à ça :

• un provider externe reste branché par habitude alors qu’il ne devrait servir que sur quelques cas
• un webhook ou une intégration de messagerie continue à recevoir des contenus qui ont changé de nature
• un export automatique pousse dehors des bouts de texte, des logs ou des métadonnées que tu n’avais pas prévu de sortir
• un token de sortie a plus de droits que nécessaire et personne ne s’en souvient

Mauvais réflexe

“Je branche maintenant, on verra plus tard ce qui passe dedans.”

Réflexe propre

“Je sais ce qui sort, vers qui, pourquoi, et dans quelles situations.”

Avant de brancher une sortie externe

• Qu’est-ce qui peut sortir exactement ?
• Est-ce que ce flux peut contenir des secrets, du privé ou des fichiers de travail ?
• Est-ce que cette sortie doit être permanente, ou seulement ponctuelle ?
• Si le contenu change demain, est-ce que la sortie reste acceptable ?

Si tu ne peux pas répondre proprement, la sortie n’est pas mûre.

L’automatisation trop confiante

C’est souvent là que le setup commence vraiment à coûter cher.

Un flux automatisé qui lit seulement n’a pas le même risque qu’un flux qui écrit, envoie, publie, commit ou déclenche une action. Le problème, ce n’est pas l’automatisation en soi. Le problème, c’est l’automatisation à qui on ne demande plus jamais de comptes.

Exemples banals :

• un flux qui génère des brouillons et finit par écrire ailleurs que prévu
• une routine qui transmet des extraits vers l’extérieur alors que l’entrée a changé
• une automatisation qui continue à tourner sur un périmètre devenu trop large
• une action laissée en pilote quasi automatique parce que “jusqu’ici ça allait”

Fiable ne veut pas dire inoffensif. Un flux peut avoir bien tourné cinquante fois et faire n’importe quoi à la cinquante-et-unième si l’entrée, le contexte ou le périmètre ont dérivé.

Le bon réflexe, ici, est très simple :

• plus une couche agit réellement, plus elle mérite une relecture régulière
• plus une couche peut sortir ou écrire, plus son périmètre doit être serré
• plus une automatisation devient “normale”, plus il faut la relire à froid de temps en temps

Une hygiène simple qui évite déjà beaucoup de dégâts

Tu n’as pas besoin d’une usine à procédures. Tu as besoin d’une hygiène tenable.

Les gestes qui paient vraiment sont peu nombreux :

• réduire les accès au lieu de les élargir
• ranger les secrets au lieu de les disperser
• couper les tools inutiles au lieu de les laisser actifs
• retirer les couches oubliées au lieu de les garder “au cas où”
• traiter toute sortie externe comme une décision, pas comme un décor
• relire à froid les automatisations qui écrivent, envoient ou déclenchent

Ce qu’il faut relire à froid toutes les quelques semaines

• les tools qui peuvent écrire, exécuter ou sortir quelque chose
• les dossiers réellement visibles par ces tools
• les serveurs MCP encore branchés et leur utilité réelle
• les endroits où des secrets ont pu traîner
• les flux automatiques qui ont un effet réel sur des fichiers ou des sorties

Si tu tiens déjà ça, tu évites une grosse partie des ennuis ordinaires.

Les erreurs les plus fréquentes

Celles qui reviennent le plus souvent sont rarement exotiques :

• croire que local veut dire tranquille
• laisser un secret en clair “pour aujourd’hui”
• ouvrir un dossier trop large parce que c’est plus pratique
• garder actif un tool puissant après un simple test
• laisser un serveur MCP branché sans plus savoir pourquoi
• oublier qu’un provider, un webhook ou une messagerie restent des sorties externes
• ne plus jamais relire un flux automatique parce qu’il a déjà bien marché

Aucune n’a l’air impressionnante. C’est justement pour ça qu’elles font mal : on les banalise.

Ce que tu ne dois pas faire

Tu ne dois pas :

• tomber dans la parano spectacle et tout verrouiller au point de ne plus utiliser ton setup
• tomber dans l’excuse inverse du “c’est local, donc peu importe”
• garder des accès larges par flemme
• confondre setup agréable et setup ouvert à tout
• laisser des couches survivre uniquement parce qu’elles ont demandé du travail
• traiter la sécurité comme un grand ménage annuel au lieu d’une petite routine tenable

Le bon niveau d’effort n’est ni militaire, ni négligent. C’est celui que tu appliques vraiment.

La suite logique

Une fois cette hygiène en place, le sujet suivant devient naturellement celui des mises à jour propres. Parce qu’un setup ne dérive pas seulement quand il est trop ouvert. Il dérive aussi quand on change des couches sans méthode, qu’on empile des correctifs, ou qu’on garde des restes de versions précédentes.