Vous avez donné à un agent votre terminal, vos clés SSH, votre répertoire home et la possibilité d’installer des paquets — et ça marche, jusqu’au moment où vous voulez le faire tourner sur une machine qui compte. Un agent toujours actif sur une machine partagée, un poste de travail avec des identifiants de production à proximité, ou une machine qu’un collègue utilise aussi : chaque « exécute juste ça » devient alors une décision sur le rayon d’impact. La réponse de NVIDIA consiste à arrêter de débattre des permissions et à mettre tout l’agent dans un conteneur doté d’une liste blanche réseau, puis à garder les clés API sur l’hôte, là où l’agent ne peut pas les lire.

Ce qu’est NemoClaw

NVIDIA NemoClaw est une stack de référence open source (Apache-2.0) pour exécuter des agents IA toujours actifs de façon plus sûre dans des sandboxes NVIDIA OpenShell. Sa propre description cite trois agents pris en charge, et Hermes en fait partie :

Exécutez des agents comme Hermes, LangChain Deep Agents et OpenClaw de manière plus sécurisée dans NVIDIA OpenShell, avec une inférence gérée

Ce n’est pas un fork de Hermes et cela ne change pas votre façon d’utiliser Hermes. C’est l’emballage qui va autour : un CLI hôte (nemohermes est le CLI NemoClaw avec Hermes présélectionné), un blueprint de conteneur versionné, un assistant d’onboarding et une couche d’intégration propre à l’agent. La formulation du dépôt lui-même mérite d’être reprise avant d’y consacrer une soirée :

NemoClaw est une stack de référence en aperçu précoce destinée à un opérateur de confiance sur un seul hôte. Ce n’est pas un service hébergé, ni un plan de contrôle multi-tenant d’entreprise, ni un système d’identité d’entreprise.

Ce que le sandbox applique réellement

Capacité	Ce que cela signifie en pratique
Exécution en sandbox	L’agent tourne dans OpenShell avec des contrôles de système de fichiers, de processus et de réseau appliqués dès le premier démarrage
Inférence routée	L’agent appelle inference.local à l’intérieur du sandbox ; OpenShell transmet au provider que vous avez choisi. Les identifiants d’inférence restent sur l’hôte
Egress contrôlé par l’opérateur	Politique réseau YAML plus presets. Les destinations non approuvées sont bloquées et remontées sous forme de requêtes à examiner
Serveurs MCP gérés	Serveurs MCP HTTPS Streamable HTTP authentifiés pour l’agent, avec les placeholders d’identifiants remplacés par OpenShell aux frontières d’egress approuvées
Cycle de vie	Blueprints versionnés et vérifiés par digest ; statut, logs, rebuild, récupération, snapshot et restauration
Migration d’état	Déplacement de l’état de l’agent entre machines avec suppression des identifiants et vérification de l’intégrité

Le choix de conception qui compte le plus pour un utilisateur de Hermes est le chemin de l’inférence. Votre clé de provider n’est jamais à l’intérieur du sandbox. L’agent parle à un endpoint local, OpenShell décide où cela va réellement, et la clé reste chez l’opérateur — ainsi un agent détourné par injection de prompt qui vide son environnement ne trouve qu’un nom d’endpoint, pas un secret.

Mettre Hermes dans un sandbox

Sur un hôte pris en charge, l’installeur tient en une commande, et il vous demande quel agent vous voulez. L’installation Express sélectionne OpenClaw par défaut : répondez n à l’invite de preset pour choisir Hermes, puis un nom de sandbox, un provider et un modèle de façon interactive :

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

Pour une installation scriptée, renseignez les réponses à l’avance plutôt que de répondre aux invites :

export NEMOCLAW_AGENT=hermes
export NEMOCLAW_NON_INTERACTIVE=1
export NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1
export NEMOCLAW_SANDBOX_NAME=my-hermes
export NVIDIA_INFERENCE_API_KEY=<your-key>
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

Ensuite, nemohermes onboard relance l’assistant, ce qui est aussi le moyen le plus rapide de voir les options disponibles sur votre machine avant de valider une config.

La liste de providers est large, et une entrée est spécifique à Hermes : à côté de NVIDIA Endpoints (NEMOCLAW_PROVIDER=build), OpenRouter, OpenAI, Anthropic, Gemini, le Model Router (routed), les endpoints compatibles OpenAI et Anthropic et un serveur vLLM local prêt à l’emploi, il y a NEMOCLAW_PROVIDER=hermes-provider, documenté comme réservé à Hermes. Ollama local est proposé pour OpenClaw et Hermes lorsqu’il est installé, en cours d’exécution ou installable.

Quand l’onboarding se termine, l’assistant affiche les deux adresses que vous utiliserez réellement :

NemoHermes is ready

Sandbox:  my-hermes
Model:    nvidia/nemotron-3-super-120b-a12b (NVIDIA Endpoints)

  Hermes Agent Dashboard
  Port 18789 must be forwarded before opening this URL.
  http://127.0.0.1:18789/

  Hermes Agent OpenAI-compatible API
  Port 8642 must be forwarded before connecting.
  http://127.0.0.1:8642/v1

Les deux ports sont redirigés depuis l’hôte, et non publiés par le sandbox — atteindre le dashboard depuis une autre machine est donc une étape explicite, pas un comportement par défaut.

Deux détails propres à Hermes à connaître

La politique réseau de base est écrite pour Hermes, pas pour un agent générique. NemoClaw fournit une politique propre à l’agent qui permet au binaire Hermes et à son runtime Python d’atteindre les endpoints dont ils ont besoin : les endpoints de service Nous Research, PyPI, les endpoints d’inférence NVIDIA et certaines API de messagerie. Si vous activez les canaux de messagerie, lisez la politique avant de basculer l’interrupteur — la doc vous renvoie précisément vers les pages sur les canaux de messagerie et la politique réseau pour cette raison.

Les terminaux peu contrastés ont droit à un skin géré. Lorsque vous vous connectez à un sandbox Hermes depuis un terminal qui gère mal le contraste, NemoClaw peut installer un skin Hermes géré nemoclaw-light pour que le texte de l’assistant reste lisible. Il retire cet état géré dès que le terminal n’en a plus besoin, et préserve un skin que vous avez choisi vous-même.

Où l’aperçu s’arrête

Être clair là-dessus vous évite un mauvais après-midi :

• Plateformes : Linux et DGX Spark sont les principales plateformes testées. macOS, WSL, DGX Station et les serveurs Linux headless sont documentés avec leurs propres limitations plutôt que promis.
• Échelle : un opérateur de confiance, un hôte. Pas de multi-tenant, pas d’identité d’entreprise.
• L’application dépend de l’hôte. La doc précise que les limites d’application varient selon l’hôte ; un sandbox ne vaut que ce que valent les fonctionnalités du kernel en dessous.
• C’est un aperçu. Des blueprints vérifiés par digest et un cycle de vie documenté, c’est bien réel, mais la stack est jeune et la doc elle-même parle d’aperçu précoce.

Une note honnête de plus : si votre problème réel est « l’agent n’arrête pas de lancer des commandes que je n’ai pas approuvées », Hermes possède déjà une porte d’approbation et une deny list pour cela, et un sandbox est un autre outil qui vise une autre menace. Les deux se composent bien — le sandbox décide ce que l’agent peut toucher, les approbations décident ce qu’il a le droit de faire.

Faut-il l’utiliser ?

Si vous faites tourner Hermes sur un portable où vous surveillez chaque tour, NemoClaw représente plus de machinerie que nécessaire. Il commence à se rentabiliser dès l’instant où l’agent tourne sans surveillance : un gateway de longue durée sur un poste de travail, un serveur à la maison, ou une machine sur laquelle d’autres personnes se connectent aussi. Les éléments qui valent d’être repris, même si vous ne l’installez jamais, sont les idées de conception — une inférence routée via un endpoint local pour que la clé n’entre jamais dans l’univers de l’agent, l’egress comme liste blanche examinée plutôt que comme note de bas de page d’un firewall, et des secrets remplacés à la frontière au lieu d’être remis au processus.

La documentation NemoClaw détaille la préparation de l’hôte, les choix de provider et la politique réseau. Plus proche de chez nous : le sandbox est orthogonal à ce que Hermes fait lui-même en matière d’approbations, et si vous voulez faire tourner Hermes quelque part de permanent, les articles sur l’auto-réparation du gateway et le watchdog de boucle couvrent les parties qui maintiennent une installation sans surveillance en vie.

---

Sources : le README du dépôt NemoClaw et la documentation NVIDIA NemoClaw (pages quickstart et overview dédiées à Hermes) ; les métadonnées du dépôt (Apache-2.0, ~22,7 k étoiles, poussées actives au 16 octobre 2026) ; la politique réseau de base Hermes et les détails du CLI nemohermes proviennent du quickstart Hermes de NemoClaw.