Guide complet 2026 — Configuration sécurité Hermes Agent sur Mac : permissions, clés et limites de fichiers

En 2026, beaucoup d’installations Mac échouent dès le premier jour : le modèle se connecte, la Gateway démarre, et on confie toute la machine à l’agent. La documentation officielle Hermes est claire — la seule barrière dure face à un LLM malveillant, c’est le système d’exploitation. Les approbations de commandes, l’isolation par conteneur et les listes blanches Gateway sont des défenses en profondeur au-dessus des limites OS ; elles ne remplacent pas les périmètres fichiers et secrets que vous définissez vous-même.

Conclusion dès le début : Hermes Agent ne doit pas avoir par défaut tout votre répertoire personnel et toutes les commandes shell. Commencez avec un espace minimal, un minimum de clés API et approvals.mode: manual, validez une vraie tâche, puis élargissez les droits délibérément. Les sections suivantes correspondent à ce que vous devriez terminer dans les 30 minutes après l’installation.

1. La baseline sécurité avant les vraies tâches

Hermes utilise par défaut terminal.backend: local : les commandes s’exécutent sous l’utilisateur macOS courant. Si la Gateway n’a pas de liste blanche, le démarrage rejette tous les utilisateurs externes — un défaut sain en mode fail-closed. Activer GATEWAY_ALLOW_ALL_USERS=true juste pour « que ça marche » signifie que quiconque atteint le bot peut déclencher des appels d’outils.

Les risques réalistes ne sont pas une « IA rebelle » de science-fiction, mais trois modes d’échec prévisibles :

• Suppression ou écrasement accidentel : rm récursif, écrasement de ~/.ssh ou ~/.hermes/.env ;
• Fuite de secrets : clés API dans les journaux, processus enfants MCP ou variables d’environnement transmises au conteneur ;
• Déclenchements non autorisés : utilisateurs Telegram/Discord/Slack non approuvés lançant déploiement, envoi groupé ou scripts de paiement.

Une configuration sécurisée ne consiste pas à « tout couper ». L’agent doit agir uniquement là où le travail a lieu. Utilisez ce tableau de couches comme fil conducteur du reste de l’article :

2. Utiliser un espace de travail dédié

2.1 Utilisateur macOS principal vs compte dédié

Évitez de faire tourner une Gateway en permanence sous votre compte macOS quotidien si vous le pouvez. Les comptes du quotidien ont souvent déjà accordé Photos, Mail, mots de passe du navigateur, etc. — le backend local hérite de toute la surface TCC.

Trois niveaux pratiques :

• Essai local (faible risque) : gardez le compte principal mais CLI seule, backend local, cwd verrouillé sur un dossier dédié ;
• Utilisateur macOS dédié (recommandé) : Réglages système → Utilisateurs et groupes, créez un utilisateur standard hermes, montez uniquement l’espace de travail et les clés SSH nécessaires ;
• Machine / VM séparée (Gateway production) : terminal.backend: ssh vers un Mac mini ou un worker Linux ; la Gateway ne route que les messages.

SECURITY.md de Hermes insiste : l’isolation multi-utilisateur doit se faire au niveau OS/hôte. Les clés de session in-app routent le trafic ; ce ne sont pas une frontière d’autorisation.

2.2 Arborescence et MESSAGING_CWD

Sur le compte dédié, créez un espace isolé — ne mettez jamais le cwd par défaut sur ~ :

mkdir -p ~/hermes-workspace/{inbox,outbox,scratch,backups}
chmod 700 ~/hermes-workspace

Dans ~/.hermes/.env :

MESSAGING_CWD=/Users/hermes/hermes-workspace

Zones suggérées :

• inbox : entrées en lecture seule ou semi-lecture pour l’agent ;
• scratch : scripts temporaires et artefacts de build en écriture ;
• outbox : sorties de l’agent à relire avant partage externe ;
• backups : pas d’écriture agent — Time Machine ou rsync uniquement.

Si un dépôt doit être attaché, liez un seul sous-dossier de projet — pas tout ~/Projects. Avec la persistance Docker, /workspace du conteneur se mappe sous ~/.hermes/sandboxes/docker/ ; purgez les anciens sandboxes pour que des fichiers sensibles ne traînent pas.

3. Secrets et clés API

3.1 Où stocker les identifiants

Hermes attend toutes les clés API et jetons dans ~/.hermes/.env uniquement — pas dans config.yaml ni dans git. Juste après l’installation :

chmod 600 ~/.hermes/.env
chmod 700 ~/.hermes

Options de stockage et limites :

3.2 Ne pas transmettre les clés fournisseur aux conteneurs

terminal.docker_forward_env et terminal.env_passthrough injectent des variables dans Docker ou les processus enfants locaux. Ne transmettez jamais les clés principales OpenAI/Anthropic via passthrough — le code dans le conteneur peut les lire et les exfiltrer. Ne transmettez que des jetons à portée de tâche (ex. GITHUB_TOKEN limité).

Les sous-processus MCP reçoivent des valeurs sûres par défaut (PATH, HOME, etc.) sauf si vous listez explicitement des vars dans le bloc env: MCP — c’est voulu.

3.3 Checklist de rotation des clés

En cas de fuite suspectée ou de maintenance planifiée, exécutez dans l’ordre :

1. Arrêter la Gateway : launchctl unload ou quitter le processus gateway ;
2. Dans les consoles cloud, révoquer et réémettre chaque clé possiblement exposée (fournisseur LLM, bot Telegram, PAT GitHub) ;
3. Mettre à jour ~/.hermes/.env et confirmer que les anciennes valeurs ont disparu ;
4. Scanner ~/.hermes/logs/ et l’historique shell pour des secrets en clair ;
5. Si des jetons Gateway ont fuité, faire tourner l’appairage : hermes pairing list / revoke ;
6. Redémarrer la Gateway ; valider avec une tâche minimale avant de réactiver l’automatisation.

4. Permissions commandes et fichiers

Hermes intègre une détection de commandes dangereuses (tools/approval.py). Dans ~/.hermes/config.yaml, conservez :

approvals:
  mode: manual    # manual | smart | off
  timeout: 60     # à expiration, refus (fail-closed)

smart utilise un modèle auxiliaire pour scorer le risque — adapté aux opérateurs expérimentés. off ou /yolo désactive les approbations — uniquement dans des conteneurs jetables ou en CI. Les entrées de liste noire dure (ex. rm -rf /, bombes fork) restent rejetées même en mode YOLO.

4.1 Modèle autoriser / demander / interdire

Choix d’approbation CLI : once / session / always / deny. En production, n’utilisez jamais always pour rm ou systemctl — cela écrit durablement dans command_allowlist. Auditez régulièrement avec hermes config edit.

4.2 Préférer l’isolation Docker en production

Avec terminal.backend: docker (ou modal/daytona/vercel_sandbox), les contrôles de commandes dangereuses sont ignorés — le conteneur est la frontière. Docker retire des capacités par défaut, limite les PID et isole /tmp en tmpfs. Exemple :

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_forward_env: []          # vide = pas de secrets hôte dans le conteneur
  container_cpu: 1
  container_memory: 5120
  container_disk: 51200
  container_persistent: true

Les conteneurs peuvent encore atteindre Internet par défaut. Si un Skill n’a pas besoin du réseau, restreignez la sortie au niveau Docker ou utilisez --network=none le cas échéant.

5. Invites de confidentialité macOS

Le CLI/Gateway Hermes peut déclencher des dialogues TCC pour les fichiers, le contrôle du navigateur ou les captures d’écran. Les chemins de menu varient selon la version macOS ; la règle, non : accorder le minimum nécessaire, de préférence sur le compte utilisateur dédié.

• Fichiers et dossiers : ajoutez uniquement hermes-workspace, pas « disque entier » ni Documents ;
• Automatisation (Apple Events) : refuser si vous ne pilotez pas Mail/Notes via Hermes ;
• Accessibilité / Enregistrement de l’écran : activer seulement si les outils navigateur l’exigent ;
• Accès complet au disque : éviter sauf besoin concret — contourne TCC.

Réglages système → Confidentialité et sécurité → catégorie concernée ; révoquez à tout moment. Après une mise à jour majeure de macOS, réauditez la liste.

6. Autorisation Gateway et journaux d’audit

6.1 Qui peut parler au bot

Configurez les listes blanches dans ~/.hermes/.env. N’utilisez pas GATEWAY_ALLOW_ALL_USERS=true en production :

TELEGRAM_ALLOWED_USERS=your_numeric_id
GATEWAY_ALLOWED_USERS=your_numeric_id
# Ou appairage DM : code à 8 chiffres ; approuver via hermes pairing approve

Ordre de vérification : drapeau allow-all plateforme → liste d’appairage approuvée → liste blanche plateforme → liste blanche globale → refus par défaut. Les codes d’appairage expirent en une heure, limite de débit à dix minutes, verrouillage une heure après cinq échecs — plus souple que des ID codés en dur seuls.

6.2 Que conserver dans les journaux

Répertoire de journaux par défaut : ~/.hermes/logs/. Conserver et faire tourner :

• Avertissements au démarrage Gateway (ex. liste blanche manquante) ;
• Résultats d’approbation de commandes dangereuses (approuvé / refusé / expiré) ;
• Tentatives d’accès non autorisées ;
• Installation de Skills et événements lazy-install ;
• Avis chaîne d’approvisionnement de hermes doctor.

Les journaux peuvent contenir chemins, arguments de commande et fragments de prompt — traitez-les comme sensibles ; ne les synchronisez pas vers des dossiers cloud publics. Les erreurs MCP masquent des motifs comme ghp_ et sk-, mais cela ne remplace pas le fait de logger moins de secrets dès le départ.

Activez security.website_blocklist pour bloquer les URL d’admin internes. La protection SSRF bloque par défaut RFC1918 et les IP de métadonnées — gardez allow_private_urls: false sauf besoin réel d’Ollama LAN, etc.

7. Élargir les permissions par étapes

Ne commencez pas avec local + yolo + allow all users. Une échelle raisonnable :

1. Semaine 1 : CLI + approbations manual + répertoire dédié + une clé fournisseur ;
2. Semaine 2 : ajouter Gateway, appairage DM, votre ID seulement ;
3. Semaine 3 : passer au backend docker, lier un dépôt ;
4. Production : Mac mini/VM dédié + backend ssh + limites de ressources + alertes sur journaux.

À chaque montée de niveau, consacrez 15 minutes à des tests d’approbation délibérés : supprimer un fichier temporaire, curl une IP interne, tenter un push — confirmez que les blocages tiennent.

8. Réponse aux incidents

Suppression accidentelle : restaurer depuis backups ou Time Machine dans l’espace de travail ; si versionné, git checkout. Mettre l’agent en pause et retracer le prompt déclencheur dans les journaux.

Fuite de clé : suivre la checklist de rotation section 3.3 ; réinitialiser les jetons bot dans @BotFather si Telegram a été exposé.

Appel non autorisé : hermes pairing revoke <platform> <user_id> ; vérifier si les URL webhook Gateway ont fuité ; restreindre l’accès avec pare-feu ou Tailscale.

Dépenses API anormales : définir d’abord les plafonds côté fournisseur, puis inspecter les journaux pour des boucles d’outils ou des tâches cron incontrôlées.

Note : Hermes ne garantit pas que « les données ne quittent jamais la machine » — les API de modèles, les outils navigateur et la recherche web sortent toutes. Pour un fonctionnement local uniquement, routez vers des modèles sur appareil et désactivez vous-même les outils concernés.

9. Checklist sécurité post-installation (30 minutes)

• ☐ Créer ~/hermes-workspace et définir MESSAGING_CWD
• ☐ chmod 600 ~/.hermes/.env ; confirmer l’absence de secrets dans config.yaml
• ☐ approvals.mode: manual ; YOLO désactivé
• ☐ Auditer command_allowlist — vide ou minimal
• ☐ Liste blanche Gateway ou appairage DM ; GATEWAY_ALLOW_ALL_USERS désactivé
• ☐ Gateway production sur backend docker ou ssh, pas local
• ☐ docker_forward_env: [] ; clés fournisseur non transmises
• ☐ Accords confidentialité macOS limités à l’espace de travail
• ☐ Lancer hermes doctor ; traiter les avis chaîne d’approvisionnement
• ☐ Confirmer que ~/.hermes/logs/ est inscriptible et hors dossier cloud synchronisé

Faire tourner Hermes sur un Mac mini pour des frontières plus nettes

Héberger la Gateway Hermes sur un Mac mini dédié vaut mieux que « tous les droits sur le MacBook du quotidien » : votre machine principale garde le code et la messagerie ; le mini exécute l’agent, les sandboxes Docker et les journaux — physiquement séparé des photos personnelles et des cookies du navigateur. La mémoire unifiée Apple Silicon aide si vous faites tourner des modèles auxiliaires locaux (ex. Ollama) ; Gatekeeper, SIP et FileVault ajoutent l’intégrité système, et TCC peut être minimisé sur un compte dédié.

Le Mac mini M4 consomme environ 4 W au repos, reste silencieux sans ventilateur pour une Gateway 24 h/24, et s’accorde bien avec terminal.backend: ssh pour que l’exécution des commandes reste sur un worker pendant que le nœud Gateway gère messages et approbations. Si vous construisez un hôte agent durable, le Mac mini M4 est l’un des points de départ au meilleur rapport qualité-prix — passez à l’action et gardez Hermes dans les limites que vous définissez.