Hermes Agent con Docker: installazione e blindatura testate

«Hermes agent» e «hermes vs openclaw» tornano regolarmente nelle ricerche italiane, ma il nome è ambiguo: diversi progetti si chiamano Hermes. Uno solo è confrontato con OpenClaw nelle fonti datate 2026. Viene identificato qui, installato e blindato con Docker in un laboratorio isolato, distinguendo a ogni passaggio ciò che è realmente girato da ciò che resta documentato.

Quale Hermes Agent, di preciso?

Il progetto puntato da queste ricerche è Hermes Agent, sviluppato da Nous Research e pubblicato sotto licenza MIT nel repository NousResearch/hermes-agent, . Il repository mostrava 242.851 stelle e 49.953 fork il 7 settembre 2026, per una creazione il 22 luglio 2025. La sua descrizione sta in una frase: «the agent that grows with you». Un agente unico, che crea e affina le proprie competenze a partire dall’esperienza, all’opposto di una piattaforma di orchestrazione di più agenti. Questa contrapposizione di filosofia ricorre nei confronti pubblicati nel 2026 rispetto a OpenClaw, e conferma che si tratta proprio del progetto dietro le ricerche «hermes vs openclaw».

Due trappole di denominazione da evitare. hermes-webui è un client web di terze parti non mantenuto da Nous Research. «HermesHub» designa un indice della community di competenze, distinto dall’hub ufficiale integrato nella CLI. Entrambi si confondono facilmente con il progetto principale nei risultati di ricerca. Hermes Agent si unisce peraltro alla lista che il nostro panorama degli agenti di codice a riga di comando confronta tra loro.

Installare Hermes Agent con Docker

L’immagine ufficiale è nousresearch/hermes-agent. La documentazione Docker descrive un assistente di configurazione interattivo poi un avvio come servizio:

mkdir -p ~/.hermes
docker run -it --rm -v ~/.hermes:/opt/data nousresearch/hermes-agent setup

docker run -d --name hermes --restart unless-stopped \
  -v ~/.hermes:/opt/data -p 8642:8642 \
  nousresearch/hermes-agent gateway run

Il laboratorio più sotto non riprende quell’assistente interattivo: passa direttamente da un compose blindato che riproduce gateway run su una rete e porte diverse. La porta 8642 serve sia da punto di salute sia da gateway compatibile API OpenAI, la porta 9119, opzionale, serve per il pannello web. Il volume montato su /opt/data contiene .env, config.yaml, SOUL.md, oltre alle cartelle sessions/, memories/ e skills/. La documentazione raccomanda da 1 a 4 GB di memoria e 1 o 2 core a seconda dell’uso.

Ho fissato l’ultima versione datata piuttosto che latest. Le release GitHub indicano la v0.21.0 (tag v2026.8.31, «The Pantheon Release»), pubblicata il 31 agosto 2026, circa 5.800 commit e 760 contributori dopo la versione precedente. Il download ha impiegato 1 min 47 s su questa macchina per 908 MB compressi (3,93 GB una volta decompressi, architettura arm64). L’immagine v2026.4.30, 8,2 GB, colloca un vero cambio di architettura interna tra aprile e maggio 2026. Questo punto di controllo si avvia ancora su tini, mentre la versione di agosto usa s6-overlay come PID 1, con abbandono dei privilegi verso un utente hermes (UID 10000 per impostazione predefinita). Curiosità notata di passaggio: il registro Docker Hub mostra che il peso dell’immagine è passato da circa 2,5 GB ad aprile a meno di 900 MB da luglio 2026.

Blindare la configurazione: rete, porte, segreti

Il docker-compose.yml ufficiale dichiara network_mode: host sia per il gateway sia per il pannello, comodo, ma senza nessun isolamento di rete. Per il laboratorio, ho costruito una versione blindata: rete dedicata, porte pubblicate solo sul loopback, segreti fuori dal file compose.

services:
  hermes:
    image: nousresearch/hermes-agent:v2026.8.31
    container_name: hermes-lab
    networks:
      - hermes_lab
    ports:
      - "127.0.0.1:8642:8642"
      - "127.0.0.1:9119:9119"
    volumes:
      - ./data:/opt/data
    env_file:
      - ./secrets/hermes.env     # eventuale chiave del fornitore, fuori dal repository
    environment:
      - HERMES_UID=501
      - HERMES_GID=20
      - HERMES_DASHBOARD=1
      - HERMES_DASHBOARD_HOST=0.0.0.0
      - API_SERVER_HOST=0.0.0.0   # vedi più sotto: senza questa riga, /health
    deploy:                       #   resta irraggiungibile anche con la porta pubblicata
      resources:
        limits:
          memory: 1g
          cpus: "1.0"
    command: ["gateway", "run"]

networks:
  hermes_lab:
    driver: bridge

Due impostazioni del compose ufficiale si comportano diversamente da quanto lascia attendere la documentazione. Il primo riguarda la rete. Segnarla internal: true per tagliare ogni uscita Internet taglia anche la porta pubblicata. Nel laboratorio, una richiesta lanciata dall’interno del container ottiene un HTTP 200 su /health. La stessa richiesta dalla macchina host, sulla porta pubblicata, non riceve nessuna risposta. Un tentativo di uscita verso example.com fallisce su una risoluzione DNS impossibile. L’isolamento tiene, dunque, ma si porta dietro anche l’uso locale legittimo della porta. internal: true è adatto solo a un laboratorio interamente offline. Per un uso reale con un fornitore di modello remoto, l’isolamento passa da una rete dedicata classica e un firewall in uscita, non da questa impostazione.

Il secondo sorprende di più. Anche sulla rete dedicata non segnata internal, la porta pubblicata restava irraggiungibile, connessione TCP accettata, risposta HTTP vuota. Una ricerca nel codice installato dà la spiegazione esatta:

docker exec hermes-lab grep -r API_SERVER_HOST /opt/hermes/hermes_cli/security_audit_startup.py

host = extra.get("host") or os.environ.get("API_SERVER_HOST", "127.0.0.1")

Per impostazione predefinita, il gateway ascolta solo sul loopback all’interno del container, indipendentemente dalla rete Docker scelta. Da qui la riga API_SERVER_HOST=0.0.0.0 nel compose sopra: non cambia nulla all’esposizione esterna, dato che è il prefisso 127.0.0.1: della porta pubblicata a restringerla già. Verificato dopo la correzione: curl http://127.0.0.1:8642/health risponde 200 dall’host, la stessa richiesta inviata verso l’indirizzo di rete locale della macchina (192.168.x.x) non riceve nessuna risposta. Quanto al pannello, rifiuta categoricamente di avviarsi su un’interfaccia non locale senza un fornitore di autenticazione configurato:

Refusing to bind dashboard to 0.0.0.0 — the auth gate engages on non-loopback
binds (0.0.0.0), but no auth providers are registered.
There is no unauthenticated public-dashboard option.

Comportamento sano per impostazione predefinita, con un effetto collaterale visibile nei log. Lasciato così com’è, senza autenticazione configurata, il servizio non resta semplicemente disattivato, fallisce poi riparte in loop sotto la supervisione s6. Nulla di grave, ma abbastanza rumoroso da valere la pena saperlo. Ultimo punto verificato: il limite deploy.resources.limits del compose sopra si applica effettivamente fuori dalla modalità Swarm con Docker Compose v5.1.0. docker inspect conferma Memory=1073741824 e NanoCpus=1000000000 sul container avviato. Vecchie versioni di Compose ignoravano deploy: fuori Swarm.

Cosa si osserva all’avvio

Una volta corretta la configurazione, docker compose up -d poi un sondaggio di /health ogni 0,3 secondi danno un tempo di avvio di circa 18,9 secondi a freddo (cartella dati vuota) e 16,6 secondi dopo un semplice riavvio. Lo scarto dipende soprattutto da una fase di preriscaldamento interno, che i log chiamano esplicitamente «turn-machinery warm-up» e che apre la porta d’ingresso dopo 20 secondi anche se continua in background. All’interno, ps aux conferma che il supervisore resta root ma che il processo hermes gateway run gira effettivamente sotto l’utente non privilegiato hermes. Il banner di avvio mostra Hermes Agent v0.21.0 (2026.8.31), Python 3.13.5 e l’SDK OpenAI 2.24.0.

Collegarsi a un modello

Il file .env generato al primo avvio elenca, interamente come commenti, una trentina di fornitori (Fireworks, OpenRouter, NovitaAI, Gemini, z.ai, Kimi, MiniMax, OpenCode Zen…) e altrettante chiavi di strumenti (Firecrawl, Exa, Browserbase), nessuna è attiva. «Ollama» vi appare solo nella forma OLLAMA_API_KEY, il servizio cloud a pagamento di Ollama, e nessuna voce punta a un’istanza locale. La diagnostica integrata conferma lo stato neutro dell’installazione:

docker exec hermes-lab hermes doctor

✓ No active security advisories
✓ No suspicious MCP stdio commands
✓ Version files consistent (0.21.0)
◆ API Connectivity
  ⚠ OpenRouter API (not configured)
◆ Memory Provider
  ✓ Built-in memory active (no external provider configured — this is fine)

Unico valore presente in .env al termine del test: una API_SERVER_KEY generata automaticamente dal container, per proteggere il proprio gateway locale. Non compare mai in chiaro nei log, nessuno l’ha inserita, e non ha alcun rapporto con un account presso un fornitore di modello.

Le competenze, e come verificarne una prima di installarla

Le competenze («skill») vivono in /opt/data/skills/ e seguono lo standard aperto Agent Skills dettagliato nella nostra guida al SKILL.md. hermes skills list contava 53 competenze integrate attivate in questo laboratorio, nessuna installata dall’hub. L’installazione avviene per registro: hermes skills install official/security/1password oppure hermes skills install openai/skills/k8s, per esempio. Prima di installare qualsiasi cosa, due comandi evitano di doversi fidare alla cieca:

hermes skills inspect openai/skills/k8s   # metadati, repository sorgente, audit già disponibile
hermes skills audit                       # riscansiona tutte le skill installate dall'hub

Lo scanner integrato classifica ogni risultato in tre livelli: dangerous blocca l’installazione, warn/caution si aggira con --force, advisory resta informativo. Secondo la documentazione ufficiale, l’hub aggregava 90.700 competenze distribuite su 11 registri al 26 agosto 2026, da non confondere con «HermesHub», l’indice della community di terze parti evocato più sopra.

MCP: collegare strumenti, o esporre Hermes come server

hermes mcp catalog, eseguito nel laboratorio, mostra un catalogo già lungo di server pronti all’uso (Airtable, Atlassian, Cloudflare, ClickUp, Buildkite…). hermes mcp list confermava che nessuno era configurato, come atteso su un’installazione nuova. L’aggiunta si fa con un preset noto o una voce manuale:

hermes mcp add codex --preset codex
hermes mcp add filesystem --command npx --args "-y @modelcontextprotocol/server-filesystem /projet"

Nell’altro senso, hermes mcp serve espone una sessione Hermes come server MCP a un client esterno, Claude Code, per esempio, puntando la sua configurazione verso il comando hermes mcp serve. Sul fronte sicurezza, la documentazione precisa tre cose. I token OAuth remoti sono messi in cache con permessi 0600. Il rinnovo passa da PKCE. Per i server in stdio, solo le variabili d’ambiente esplicitamente dichiarate, più una base minima, sono trasmesse al sottoprocesso. Quanto basta per limitare le fughe di segreti verso un server MCP di terze parti mal verificato, un rischio già documentato nel nostro articolo sugli agenti di codice, sandbox e permessi.

Hermes Agent contro OpenClaw: un confronto onesto

I due progetti sono open source, si installano con Docker e supportano skill e MCP, è la loro filosofia a divergere. OpenClaw struttura un gateway che instrada e sorveglia più agenti, connettori e canali. Hermes Agent punta su un agente unico che accumula le proprie competenze con l’uso. Il nostro articolo sull’installazione blindata di OpenClaw dettaglia lo stesso esercizio dal lato OpenClaw, i due si leggono in modo speculare.

Sulla sicurezza, una nota di ricerca della Cloud Security Alliance datata 4 maggio 2026 censisce, nello stesso periodo, nove CVE per OpenClaw di cui una critica con punteggio 9,9, contro due per il nucleo di Hermes Agent. CVE-2026-7396 riguarda un path traversal nell’adattatore WeCom (CVSS 4,0), CVE-2026-7397 un symlink following negli strumenti file (CVSS 4,8), entrambe sulla versione 0.8.0 e corrette già nella 0.9.0. Una terza CVE elencata riguarda non l’agente ma hermes-webui, il client di terze parti già segnalato più sopra. La pagina GitHub Security Advisories del repository non fa invece riferimento a nessun avviso pubblicato al 7 settembre 2026: queste CVE sono state depositate tramite canali esterni, non da Nous Research stessa. A oggi non è stato pubblicato nessun censimento di istanze Hermes esposte paragonabile alla cifra verificata per OpenClaw (42.900 istanze, 93% senza autenticazione, SecurityScorecard 2026), il che non prova la loro assenza.

Un incidente datato illustra perché la segmentazione di rete e l’assenza di modalità automatica contano tanto quanto la scelta del progetto. The Hacker News ha documentato, il 24 luglio 2026, un caso in cui un attaccante che disponeva già di un accesso iniziale alla rete del ministero delle Finanze thailandese ha installato Hermes Agent su un server noleggiato, poi ha attivato la sua modalità «YOLO», che salta le conferme prima dei comandi rischiosi. L’agente ha poi esplorato la rete senza supervisione, trovato servizi Hadoop con credenziali predefinite e distribuito un impianto. Punto sottolineato dalla fonte stessa: Hermes non ha provocato l’intrusione, ne ha automatizzato la fase successiva. La rete dedicata, le porte sul loopback e l’assenza di chiave inserita in questo laboratorio mirano a impedire esattamente quella fase.

Cosa ricordare

• Il «Hermes Agent» confrontato con OpenClaw nel 2026 è quello di Nous Research (NousResearch/hermes-agent, licenza MIT), non hermes-webui né «HermesHub», due progetti di terze parti dal nome simile.
• Ultima versione datata testata: v0.21.0 (tag v2026.8.31, 31 agosto 2026), installata via Docker in 1 min 47 s (908 MB compressi, 3,93 GB decompressi).
• Una rete segnata internal: true taglia anche la porta pubblicata, non solo l’uscita Internet. Per impostazione predefinita, il gateway ascolta solo sul proprio loopback (API_SERVER_HOST=127.0.0.1), da correggere esplicitamente anche dietro una porta già ristretta a 127.0.0.1 lato host.
• Il pannello rifiuta di esporsi fuori dal loopback senza autenticazione configurata. Sano per impostazione predefinita, ma lasciato così va in loop di errore invece di restare semplicemente inattivo.
• Avvio misurato a circa 17-19 secondi fino a un /health realmente positivo, senza nessuna chiave né credenziale inserita dall’inizio alla fine.
• Nello stesso periodo, la Cloud Security Alliance censisce due CVE minori per il nucleo di Hermes Agent contro nove per OpenClaw, di cui una critica. Lo scarto va letto con prudenza: per Hermes non è stato pubblicato alcun censimento di esposizione equivalente.