Sécurité Hermes Agent : permissions et bonnes pratiques
Quand on branche Hermes Agent à un vrai système, la question n’est pas « est-ce que ça marche ? ». C’est « qu’est-ce que ce worker a le droit de casser ? ».
Le sujet des permissions n’est pas un détail d’admin. C’est ce qui sépare un agent utile d’un agent trop autonome, qui peut modifier un fichier sensible, appeler une API de prod ou exécuter une commande au mauvais endroit.
La bonne approche est simple : donner le minimum utile, séparer les rôles, et faire évoluer les droits par usage réel, pas par confort.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Le risque numéro 1 : un worker avec trop de permissions
Le premier risque n’est pas le bug spectaculaire. C’est la dérive silencieuse : un worker qui commence en lecture seule, puis récupère une écriture « temporaire », puis finit avec accès API, puis shell, parce que c’est plus pratique.
Le problème est connu dans tous les systèmes à agents : quand un seul worker couvre trop de cas, il finit par concentrer trop de pouvoir. Si ce worker se trompe, ou s’il est détourné par une instruction mal formulée, l’impact est plus large.
Si tu veux une base de réflexion plus large sur la mise en sécurité d’un système d’agents, la checklist pré-prod des agents IA est un bon point de départ. Pour la partie contrôle en conditions réelles, les points de contrôle en production aident à cadrer ce qui doit être vérifié avant de laisser tourner un worker en autonomie.
Permissions fichiers : lecture seule vs écriture
Lecture seule
La lecture seule convient à la plupart des workers d’analyse, de synthèse, de classement ou de préparation de contenu. Ils peuvent ouvrir des documents, extraire des informations, proposer des modifications, mais pas changer le source de vérité.
C’est le mode le plus sûr pour un worker de veille, de résumé, d’audit ou de suggestion éditoriale. Un bug peut produire une mauvaise recommandation, mais il ne peut pas écraser un fichier.
Écriture
L’écriture doit être réservée aux workers qui ont une raison claire de modifier un contenu : génération de brouillon, mise à jour d’une fiche, création d’un artefact intermédiaire.
Le bon réflexe : séparer l’espace de travail de l’espace source. Le worker écrit dans un dossier de travail, puis un humain ou un autre contrôle valide avant publication ou synchronisation.
Pour éviter les accidents, vérifie ces quatre points :
- le worker sait-il exactement quels dossiers il peut écrire ?
- peut-il écraser un fichier existant ?
- peut-il modifier des fichiers de configuration ou des secrets ?
- écrit-il dans un espace temporaire ou dans la source principale ?
Si la réponse n’est pas nette, les droits sont trop larges.
Permissions API : ce que chaque worker peut appeler
Les appels API sont souvent plus dangereux qu’on le croit, parce qu’ils donnent accès à des actions distantes, parfois irréversibles : envoyer un message, créer un ticket, modifier un objet, déclencher une synchronisation, ou appeler un service tiers.
API de lecture
Un worker qui lit des données externes a besoin d’accès restreint à quelques endpoints ou scopes précis. Il ne doit pas pouvoir créer, supprimer ou éditer. C’est le bon cadre pour la récupération d’informations, l’enrichissement de contexte et la synchronisation en lecture.
API d’écriture
Dès qu’un worker peut écrire dans un système externe, le risque monte d’un cran. Il faut alors limiter trois choses : le périmètre des objets modifiables, le type d’action autorisée, et le volume d’actions possibles.
Un worker de support ne doit pas avoir les mêmes droits qu’un worker de publication. Un worker de collecte ne doit pas pouvoir envoyer des messages à des tiers. Si tu dois trancher, pars du principe suivant : un worker qui appelle une API doit être autorisé par usage, pas par commodité.
Permissions exécution : commandes shell et scripts
C’est souvent là que la casse arrive. Dès qu’un worker peut lancer des commandes shell ou exécuter des scripts, il faut considérer qu’il a un pouvoir élevé. Même sans intention malveillante, une commande trop large peut supprimer un dossier, lancer un traitement sur le mauvais répertoire ou exposer des données.
Ce qu’il faut éviter : l’exécution shell générale, les commandes arbitraires passées librement, les scripts qui peuvent lire et écrire partout, les droits d’installation ou de mise à jour système.
Ce qui est préférable : des commandes autorisées, connues à l’avance, avec paramètres limités. Un worker appelle un script précis, qui fait une tâche précise, avec des entrées bornées et des sorties prévisibles.
C’est moins « flexible », mais beaucoup plus sain.
Matrice des risques par type de worker
Voici une grille simple pour raisonner sans se raconter d’histoire. Chaque type de worker a un profil de risque différent :
- Lecture / synthèse : fichiers en lecture seule, API en lecture seule, aucune exécution. Risque principal : fuite d’info ou mauvaise interprétation. Droits minimaux.
- Rédaction / brouillon : écriture dans dossier de travail, API limitée, script borné ou aucun. Risque : écrasement de contenu. Séparer travail et source.
- Intégration métier : lecture et écriture ciblées, API ciblée, scripts précis. Risque : modification d’objets sensibles. Scopes restreints, validation des actions.
- Ops / automatisation : fichiers très bornés, API d’action, shell limité. Risque : action irréversible, cascade d’erreurs. Rôle dédié, supervision forte.
- Admin technique : accès large mais traçable, API large mais tracée, shell contrôlé. Risque : impact maximal en cas d’erreur. Compte séparé, journalisation renforcée.
Le point clé n’est pas d’interdire tout pouvoir. C’est de faire correspondre le pouvoir au rôle.
Configuration recommandée pour un usage solopreneur
Pour un solopreneur, la configuration la plus saine est souvent la plus simple :
- un worker de lecture, sans écriture
- un worker de brouillon, qui écrit dans un espace séparé
- un worker d’action, limité à quelques opérations précises
- un compte humain qui valide les étapes sensibles
Ce découpage évite le piège du « tout-en-un ». Tu perds un peu de vitesse brute, mais tu gagnes en lisibilité et en contrôle.
Concrètement, je recommande ce schéma : les sources restent en lecture seule, les brouillons vont dans un dossier de travail, les intégrations API sont limitées à des scopes précis, et les commandes shell passent par des scripts dédiés, jamais par du libre arbitre total.
Si tu construis ton système autour du second cerveau, garde la même logique : la donnée brute peut rester complète, mais les actions automatiques doivent passer par des chemins contrôlés. L’article sur OpenClaw et la sécurité solopreneur montre comment cette logique se traduit dans une architecture de travail plus large.
Auditer les permissions existantes
Auditer les permissions, ce n’est pas relire une config une fois par an. C’est vérifier régulièrement qui peut faire quoi, et si ce droit est encore justifié.
Questions à poser :
- ce worker a-t-il encore besoin d’écrire ?
- a-t-il besoin de cette API entière, ou d’un seul scope ?
- a-t-il vraiment besoin d’exécuter des scripts ?
- un autre worker plus limité pourrait-il faire le job ?
- existe-t-il des secrets ou des chemins sensibles accessibles par erreur ?
Signaux d’alerte : un worker « généraliste » qui fait tout, des permissions accordées « pour tester » et jamais retirées, un accès shell laissé actif sans nécessité claire, des droits de prod copiés d’un environnement à l’autre, des exceptions devenues la norme.
Le bon audit répond à une question simple : si ce worker se trompe aujourd’hui, qu’est-ce qu’il peut réellement toucher ?
Ce qu’il faut retenir
La sécurité des permissions Hermes Agent tient en une phrase : réduire le rayon d’action de chaque worker au strict nécessaire.
Lecture seule quand c’est possible. Écriture séparée quand c’est utile. API bornées. Exécution contrôlée. Et audit régulier.
Ce n’est pas une couche de parano, c’est une façon propre de travailler avec des agents qui ont, par nature, plus d’autonomie qu’un simple script.
Action suivante : prends la config de ton worker le plus utilisé et vérifie ses droits un par un. Si un seul point est trop large, réduis-le maintenant, pas après le premier incident.
