Hermes Agent, le harnais d’agent autonome de Nous Research

Hermes Agent est un harnais d’agent : la boucle, les outils, la mémoire et le contexte qu’on installe autour d’un modèle de langage pour qu’il agisse au lieu de répondre. Le modèle vient d’ailleurs, de n’importe où en réalité, et se change en une commande. Hermes fournit le reste : un terminal, un navigateur, une mémoire qui survit à la session, un planificateur de tâches, et des passerelles vers une douzaine de messageries. Autrement dit, tout ce qui transforme un assistant bavard en un programme qui écrit sur votre disque pendant que vous dormez.

→ Lire l’explication complète de la marmotte

À quoi sert Hermes Agent, et ce qu’on appelle un harnais d’agent

Un harnais d’agent répond à la question que le modèle ne sait pas traiter seul : que faire du texte qu’il vient de produire. Il tient la boucle (on envoie l’état, le modèle propose une action, le harnais l’exécute, le résultat repart dans le contexte), le catalogue d’outils, la gestion du contexte, et la mémoire qui franchit la frontière entre deux sessions. Le modèle décide ; le harnais est responsable du reste, y compris des dégâts. La distinction entre assistant et agent outillé est détaillée dans la page sur l’agentique.

Hermes Agent est un harnais généraliste : on lui confie l’administration d’un serveur, une veille quotidienne, un script à écrire, une sauvegarde nocturne. Ses auteurs le présentent comme « le seul agent doté d’une boucle d’apprentissage intégrée », qui crée ses propres compétences et fouille ses conversations passées. L’affirmation est celle du projet, dans son dépôt, qui ne publie aucun résultat de banc d’essai à l’appui.

C’est la différence qui compte avec les deux autres harnais de cette rubrique : les leurs sont nés du test d’intrusion et ne savent rien faire d’autre, alors que celui-ci est un outil d’usage courant, installé sur un poste, branché sur vos messageries et sur vos fichiers. Le danger ne vient pas de ce qu’il attaque, mais de ce qu’il habite.

Qui édite Hermes Agent, sous quelle licence, et avec quels prérequis

Le projet est publié par Nous Research, sur le dépôt NousResearch/hermes-agent, créé le 22 juillet 2025. Le code est écrit en Python et placé sous licence MIT (Massachusetts Institute of Technology), avec la mention « Copyright (c) 2025 Nous Research » en tête du fichier LICENSE : pas de double licence, pas de licence commerciale séparée, et la redistribution dans un produit propriétaire est permise à condition de conserver l’avis de droit d’auteur. Nous Research vend par ailleurs un abonnement, Nous Portal, qui regroupe l’accès à des modèles et une passerelle d’outils. C’est un service optionnel : Hermes fonctionne sans, avec vos propres clés.

La version la plus récente lue pendant la rédaction de cette fiche est la v0.22.3, publiée le 21 octobre 2026. Le rythme est soutenu : la v0.22.0 date du 14 octobre 2026, et trois correctifs ont suivi en une semaine. Un numéro inférieur à 1.0 sur un programme qui exécute des commandes chez vous s’interprète comme une invitation à la prudence plutôt qu’à la confiance.

Côté plateformes, l’installeur source couvre Linux, macOS et WSL2 (Windows Subsystem for Linux, le sous-système Linux de Windows), un installeur PowerShell couvre Windows en natif, et un dépôt APT (Advanced Package Tool) signé couvre Android sous Termux en aarch64. L’installeur ne pose pas qu’un programme : il clone les sources, amorce uv (le gestionnaire de paquets Python d’Astral), prépare Python, Node.js, npm, ripgrep et FFmpeg en versions épinglées, et ajoute par défaut les outils de navigation et le pilote de contrôle du bureau, sauf --skip-browser et --skip-computer-use. Le code atterrit dans ~/.hermes/hermes-agent/, les données dans ~/.hermes/.

Architecture de Hermes Agent : boucle, outils, backends, mémoire

La documentation décrit trois étages.

Les points d’entrée. Ligne de commande, passerelle de messagerie, adaptateur pour éditeurs de code, serveur d’API (Application Programming Interface, interface de programmation), générateur de trajectoires par lots, bibliothèque Python : six façons de déclencher la même boucle, donc six surfaces à surveiller.

L’agent. Un assembleur de prompt système, une résolution de fournisseur qui parle trois dialectes d’API, un répartiteur d’outils, un moteur de compression qui résume la conversation quand elle s’allonge, et une base SQLite à index plein texte FTS5 qui conserve les sessions. Le registre annoncé compte plus de soixante-dix outils, en vingt-huit jeux qu’on active par plateforme avec hermes tools.

Les backends d’exécution. C’est l’étage qui décide du niveau de risque. Le terminal dispose de sept implémentations : locale, Docker, SSH (Secure Shell), Singularity, Modal, Daytona et bac à sable Vercel. Le navigateur en a cinq, les outils web quatre, et le MCP (Model Context Protocol, protocole de connexion à des serveurs d’outils tiers) ajoute les outils déclarés dynamiquement.

La mémoire persistante tient dans deux fichiers de ~/.hermes/memories/ : MEMORY.md, les notes de l’agent sur son environnement, plafonné à 2 200 caractères, et USER.md, le profil de l’utilisateur, plafonné à 1 375 caractères. Les deux sont injectés dans le prompt système au démarrage de la session, en instantané figé jusqu’à la suivante, pour préserver le cache de préfixe du fournisseur. L’agent sait par ailleurs déléguer à des sous-agents isolés, et un planificateur de type cron exécute des tâches sans personne devant l’écran. Ce que cette mémoire implique pour la confidentialité est traité dans la page sur la mémoire persistante des assistants.

Quand sortir Hermes Agent, et quand un autre outil ferait mieux

Hermes se justifie quand on veut un agent qui dure : une machine à soi, une tâche répétée, une mémoire qui s’accumule, un accès depuis un téléphone. Son argument central est de n’être pas attaché à un poste de travail.

Il se justifie moins dans trois cas. Pour écrire du code dans un dépôt, un harnais spécialisé est plus prévisible ; le guide d’usage de Claude Code décrit cette famille. Pour un travail ponctuel, un appel d’API suffit, et le harnais n’apporte que sa surface d’attaque. Pour un test d’intrusion, Hermes n’a ni l’outillage ni le périmètre. Et il ne se justifie pas du tout sur une machine qui porte des données sensibles et des accès de production, avec le backend local et sans approbation.

Ce que Hermes Agent montre et ce qu’il ne montre pas

Il montre ce qu’il a fait : sortie des outils en flux continu, historique de conversation, commandes exécutées, consommation de jetons avec /usage, tentatives d’accès non autorisées dans ~/.hermes/logs/.

Il ne montre pas pourquoi il l’a fait. Un agent qui choisit mal un outil ou se laisse convaincre par une instruction cachée produit une trace parfaitement lisible d’une décision parfaitement opaque. La compression du contexte aggrave le phénomène : le résumé qui remplace la conversation est écrit par le modèle même qu’on cherche à auditer.

Il ne montre pas non plus l’état réel de sa mémoire en cours de session, l’instantané étant figé au démarrage. La documentation consacre une section au symptôme le plus courant, « je lui ai dit de retenir, et à la session suivante il avait oublié », et la réponse tient en une ligne : « c’est noté » n’est que du texte, seul l’appel de l’outil de mémoire écrit quelque chose.

Exemple : trois usages concrets de Hermes Agent

Installer, choisir son modèle, vérifier l’installation. Les trois commandes du départ, dans cet ordre.

# Installeur source (Linux, macOS, WSL2)
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# Choisir fournisseur et modèle, puis diagnostiquer l'installation
hermes model
hermes doctor

Télécharger un script et le passer directement à un interpréteur est, notons-le, le motif même que le garde-fou de Hermes refuse quand son agent l’écrit. L’ironie ne rend pas la commande plus sûre : on récupère le script, on le lit, puis on l’exécute.

Confiner l’exécution dans un conteneur. Le réglage qui change tout, en quatre lignes de ~/.hermes/config.yaml.

terminal:
  backend: docker        # au lieu de « local », qui exécute sur l'hôte
  docker_forward_env: [] # liste blanche vide : aucun secret n'entre
  container_memory: 5120 # mégaoctets

Interdire une commande une fois pour toutes. Les règles de refus sont évaluées avant les modes permissifs : c’est le seul garde-fou qu’un enthousiasme passager ne désactive pas.

approvals:
  mode: smart            # smart | manual | off
  deny:                  # globs, évalués avant tout mode permissif
    - "git push --force*"
    - "*curl*|*sh*"

Garde-fous d’exécution : approbation, liste noire, isolation

La documentation revendique huit couches de défense, de l’autorisation des utilisateurs au filtrage des identifiants transmis aux serveurs MCP. Trois décident de ce qui peut mal tourner.

L’approbation des commandes. Trois modes, réglés par approvals.mode. Le mode smart, par défaut, confie l’évaluation du risque à un modèle auxiliaire : il approuve seul le bénin, refuse seul le franchement dangereux, n’escalade que l’incertain. Le mode manual demande toujours, le mode off jamais (équivalent du drapeau --yolo). L’attente est de 300 secondes et l’absence de réponse vaut refus. Les sessions sans humain devant l’écran refusent par défaut, ce qui mérite d’être signalé : la mode est plutôt d’approuver pour que ça marche.

La liste noire non contournable. Un petit ensemble de motifs est refusé quoi qu’il arrive, y compris sous --yolo : effacement de la racine du système de fichiers, bombe de processus, formatage d’un périphérique bloc monté en racine, écriture directe sur un disque, redirection d’une URL (Uniform Resource Locator, adresse web) non fiable vers un interpréteur de commandes. La documentation appelle cela « le plancher sous le mode yolo » : la liste couvre l’irréversible, pas le regrettable.

L’isolation par conteneur. Avec le backend Docker, chaque conteneur démarre avec toutes les capacités Linux retirées (--cap-drop ALL), trois rendues pour les gestionnaires de paquets, l’interdiction d’élever ses privilèges (no-new-privileges), un plafond de 256 processus et deux systèmes de fichiers temporaires de taille limitée. Par défaut : un cœur, 5 Go de mémoire, 50 Go de disque. Et c’est là que le tableau de la documentation dit l’inverse de ce qu’on attend : avec les backends conteneurisés, la vérification des commandes dangereuses est sautée, le conteneur étant considéré comme la frontière de sécurité, tandis qu’avec le backend local la vérification est active mais l’isolation nulle. Aucun réglage ne cumule les deux protections. Pour une passerelle permanente, la réponse est le conteneur, et l’agent n’a aucune raison de voir l’hôte.

Clés API, coût et données envoyées au fournisseur

Hermes parle à des dizaines de fournisseurs d’inférence : Nous Portal, OpenRouter, OpenAI, Anthropic, Gemini, Vertex AI, Bedrock, Azure, DeepSeek, et des points de terminaison auto-hébergés de type Ollama ou vLLM. Les clés vivent dans ~/.hermes/.env, et la documentation recommande chmod 600 sur ce fichier, ce qui n’est pas le mode par défaut d’un fichier créé à la main. La garde de ces secrets est traitée dans la page sur les clés API des fournisseurs d’IA, leur présence dans les prompts dans celle sur les secrets dans les prompts. Un détail mérite d’être connu avant la première panne : faute d’accès propre à un fournisseur, Hermes lit et rafraîchit les identifiants déposés sur la machine par d’autres outils en ligne de commande (auth.adopt_external_logins, à true par défaut), jetons rotatifs à usage unique qui s’invalident dès que deux programmes se les partagent.

Vient le coût. Un agent qui boucle, délègue à des sous-agents, planifie des tâches nocturnes et recompresse un long contexte consomme des jetons sans témoin. La documentation lue ne décrit aucun plafond de dépense qui arrêterait la boucle avant la facture. C’est le scénario de la page sur le déni de portefeuille : la limite se pose chez le fournisseur, par clé dédiée et budget mensuel, elle ne s’espère pas du harnais.

Reste la question qui précède les autres : tout ce que l’agent lit part chez le fournisseur du modèle, fichiers ouverts, sortie des commandes, mémoire persistante et profil de l’utilisateur compris. La page sur les données envoyées aux API d’IA décrit ce qu’il faut vérifier au contrat.

Limites de Hermes Agent et conditions d’exploitation

L’injection de prompt reste le défaut structurel. Hermes analyse les fichiers de contexte de projet (AGENTS.md, .cursorrules, son propre fichier de persona) à la recherche de motifs d’injection : instructions d’ignorer les consignes précédentes, commentaires HTML dissimulés, tentatives de lire .env, exfiltration par curl, caractères Unicode invisibles. Un fichier suspect n’est pas chargé. La documentation qualifie elle-même ces motifs d’heuristiques et non de détection d’intention sémantique, ce qui plaide pour l’honnêteté du projet. Mais l’analyse ne porte que sur les fichiers de contexte : rien n’examine une page web extraite, un courriel lu dans la boîte connectée ou la sortie d’une commande. Or l’agent traite tout cela comme du texte, et le texte, pour un modèle, ressemble beaucoup à une instruction. Le mécanisme est détaillé dans la page sur la sécurité des agents autonomes outillés.

Les protections réseau sont réelles mais partielles. Les outils capables de récupérer une URL refusent les réseaux privés, la boucle locale et les adresses de lien local, dont le service de métadonnées des fournisseurs de nuage à l’adresse 169.254.169.254 ; chaque redirection est revalidée. Rien de cela ne protège d’un agent qui obtient un terminal et sort avec curl.

La passerelle de messagerie est une porte d’entrée. Tout utilisateur non listé est refusé par défaut. L’appariement par code tient la route : huit caractères sans caractères ambigus, tirage cryptographique, validité d’une heure, une demande par utilisateur et par dix minutes, verrouillage d’une heure après cinq échecs, fichiers en mode 0600. Le réglage à ne jamais toucher est l’autorisation globale de tous les utilisateurs, qui transforme un agent outillé en service public.

Les conditions d’exploitation tiennent en cinq points, les quatre premiers tirés de la liste de contrôle de la documentation :

une liste blanche d’utilisateurs explicite sur chaque plateforme de messagerie ;
le backend conteneurisé pour toute passerelle permanente, avec ses limites de ressources ;
les secrets en mode 600, un répertoire de travail défini, un compte dédié non privilégié ;
une machine qui n’a rien d’autre à perdre : un agent installé à côté de vos clés SSH de production les atteindra.

D’autres fiches de la même famille sont regroupées dans la rubrique Outils.

Côté défense : ce qu’un agent apprend sur son propre système

Pour une équipe de sécurité, Hermes a deux usages, et aucun n’est celui que vend la page d’accueil.

Le premier est pédagogique. Installer ce harnais sur une machine jetable et le laisser travailler une journée enseigne, mieux que n’importe quelle note, ce qu’un agent outillé fait d’un accès : combien de fichiers il ouvre sans qu’on le lui demande, à quelle vitesse il accumule des secrets dans son contexte, et ce que donne une instruction cachée dans un fichier. La validation des appels d’outil est traitée dans la page sur la sécurité du function calling.

Le second est la détection. Une installation standard laisse des traces nettes : un répertoire ~/.hermes/, un processus Python de longue durée qui n’appartient à aucun service connu, une unité systemd créée par un lanceur généré, des connexions sortantes régulières vers les API des fournisseurs de modèles, et des connexions permanentes vers les serveurs de Telegram, Discord ou Slack depuis une machine qui n’avait aucune raison d’en ouvrir. L’installeur réclame en outre Node.js, un Chromium épinglé et un pilote de contrôle du bureau, ce qui se voit dans un inventaire logiciel.

Ces signaux attrapent l’agent installé de bonne foi par un collègue pressé, soit le cas de très loin le plus fréquent, et aucun ne résiste à qui renomme le répertoire. La détection durable porte ailleurs : sur l’observabilité des appels de modèles en production, sur la consommation anormale d’une clé API, et sur le contrôle de ce qu’un poste a le droit d’atteindre. Le sujet relève de la politique d’usage plus que de l’antivirus, dérive que décrit la page sur l’IA fantôme.

Cadre légal : un agent qui agit avec vos droits

Hermes Agent n’est pas un outil d’attaque, et la question juridique qu’il pose n’est pas celle du test d’intrusion. Elle est plus banale : un agent agit avec les droits du compte qui le lance, et le droit ne connaît pas l’action commise par un programme en roue libre. Ce que l’agent fait, c’est vous qui l’avez fait.

Les accès. Si l’agent dispose de vos identifiants professionnels, de votre messagerie ou d’un accès de production, il peut les utiliser, et une instruction mal interprétée suffit. Un accès obtenu pour un usage et employé pour un autre est ce que la charte informatique de l’employeur interdit, et selon le système atteint, ce que les articles 323-1 et suivants du code pénal répriment : accès ou maintien frauduleux dans un système de traitement automatisé de données (323-1), entrave à son fonctionnement (323-2), modification ou suppression frauduleuse de données (323-3). L’autonomie d’un agent n’a jamais constitué une excuse. Les textes en vigueur se lisent sur Légifrance, et la qualification d’un cas relève d’un avocat, pas d’une fiche d’outil.

Les données. Sur des données personnelles, ce que l’agent envoie au fournisseur est un transfert à prévoir : base légale, information des personnes, contrat de sous-traitance, localisation. Un agent branché sur une boîte aux lettres professionnelle expédie la correspondance de tiers qui n’ont rien signé ; la page sur le contrat avec un fournisseur d’IA décrit ce qui doit figurer au dossier.

La règle tient en une phrase : un agent ne reçoit que les droits de la tâche du jour, sur une machine qu’on peut détruire, et jamais ceux qu’on ne voudrait pas voir employés par erreur.

🐝 Ce qui arrive si on s’en passe

Une équipe qui ignore ce qu’est un harnais d’agent n’en est pas protégée pour autant : elle en héberge probablement déjà, ces outils s’installant par une commande, en espace utilisateur, sans droits d’administration et sans que personne les déclare. Faute de les connaître, l’équipe ne sait ni les reconnaître dans un inventaire, ni expliquer pourquoi une clé API consomme la nuit, ni poser les bonnes questions après un incident : quel compte, quels droits, quel contexte envoyé, quels fichiers lus. La leçon qu’une journée d’observation sur une machine jetable suffit à donner lui manque : la frontière entre « il m’a rendu service » et « il a fait une bêtise irréversible » ne tient qu’à la configuration du bac à sable.

🦫 Explication de la marmotte 🍫

Un modèle d’intelligence artificielle sait produire du texte, et rien d’autre. Pour qu’il agisse sur un ordinateur, il faut un second programme autour de lui, qu’on appelle un harnais. Ce programme fait tourner une boucle : il décrit la situation au modèle, lit la réponse, exécute l’action demandée (lancer une commande, ouvrir un fichier, consulter une page web), raconte le résultat au modèle, et recommence jusqu’à ce que la tâche soit finie. Hermes Agent est un harnais de ce type, publié gratuitement et librement par une société nommée Nous Research, et il fonctionne avec presque n’importe quel modèle.

Ce qu’il ajoute par rapport à une simple conversation : un terminal, un navigateur, deux petits fichiers de mémoire qui conservent ce qu’il a appris sur toi et sur ta machine, un agenda pour travailler tout seul à heure fixe, et des liaisons vers des applications de messagerie.

Vient le danger. Par défaut, l’agent exécute les commandes sur ta machine, avec tes droits : il peut lire tes documents, modifier tes fichiers, utiliser tes accès enregistrés. Il demande ton accord avant les commandes qu’il juge dangereuses, et refuse toujours une poignée de commandes catastrophiques, même si tu as désactivé les vérifications. La meilleure protection reste de le faire travailler dans un ordinateur simulé et séparé, qu’on appelle un conteneur : s’il casse quelque chose, il ne casse que le conteneur.

Deux pièges, enfin. Tout ce que l’agent lit est envoyé à l’entreprise qui fabrique le modèle : si tu lui montres un document confidentiel, il le transmet. Et un agent obéit au texte qu’il rencontre, pas seulement au tien ; quelqu’un qui cache une instruction dans une page web peut tenter de le détourner. Un agent se traite donc comme un collègue très rapide, très obéissant et un peu crédule, à qui l’on ne confie que les clés dont il a besoin.

Sources

NousResearch/hermes-agent, README, Nous Research, consulté le 21 octobre 2026
NousResearch/hermes-agent, fichier LICENSE (MIT), Nous Research, 2025
NousResearch/hermes-agent, versions publiées, Nous Research, v0.22.3 du 21 octobre 2026
Hermes Agent, Security, Nous Research, consulté le 21 octobre 2026
Hermes Agent, Architecture, Nous Research, consulté le 21 octobre 2026
Hermes Agent, Persistent Memory, Nous Research, consulté le 21 octobre 2026
Hermes Agent, LLM and Model Providers, Nous Research, consulté le 21 octobre 2026
Hermes Agent, Installation, Nous Research, consulté le 21 octobre 2026

Pages voisines

La citent

Cairn : panneaux d'opérations offensives par agents IA exposés sur Internet

Hermes Agent, le harnais d'agent autonome de Nous Research

Elle cite