Hermes Agent onder Docker: installatie en beveiliging getest

“Hermes agent” en “hermes vs openclaw” komen regelmatig terug in Franse zoekopdrachten, maar de naam is dubbelzinnig: meerdere projecten heten Hermes. Slechts één wordt vergeleken met OpenClaw in de bronnen uit 2026. Het wordt hier geïdentificeerd, geïnstalleerd en onder Docker beveiligd in een geïsoleerd lab, waarbij bij elke stap onderscheid wordt gemaakt tussen wat echt is uitgevoerd en wat alleen gedocumenteerd blijft.

Welke Hermes Agent precies?

Het project waarnaar deze zoekopdrachten verwijzen, is Hermes Agent, ontwikkeld door Nous Research en gepubliceerd onder MIT-licentie in de repository NousResearch/hermes-agent, . De repository telde op 7 september 2026 242.851 sterren en 49.953 forks, bij een aanmaak op 22 juli 2025. Zijn omschrijving past in één zin: “the agent that grows with you”. Een enkele agent, die zijn eigen vaardigheden opbouwt en verfijnt op basis van ervaring, het tegenovergestelde van een platform dat meerdere agents orkestreert. Die filosofische tegenstelling komt terug in de vergelijkingen die in 2026 tegenover OpenClaw zijn gepubliceerd, en bevestigt dat achter de zoekopdrachten “hermes vs openclaw” precies dit project zit.

Twee naamgevingsvalstrikken om te vermijden. hermes-webui is een externe webclient die niet door Nous Research wordt onderhouden. “HermesHub” duidt een community-index van vaardigheden aan, los van de officiële hub die in de CLI is ingebouwd. Beide worden in zoekresultaten makkelijk verward met het hoofdproject. Hermes Agent voegt zich trouwens bij de lijst die ons overzicht van command line-code-agents onderling vergelijkt.

Hermes Agent installeren met Docker

De officiële image is nousresearch/hermes-agent. De Docker-documentatie beschrijft een interactieve configuratiewizard en vervolgens een start als service:

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

Het lab verderop neemt die interactieve assistent niet over: het gaat rechtstreeks via een geharde compose die gateway run reproduceert op een ander netwerk en andere poorten. Poort 8642 dient zowel als gezondheidspunt als als OpenAI-API-compatibele gateway, poort 9119, optioneel, dient voor het webdashboard. Het volume gemonteerd op /opt/data bevat .env, config.yaml, SOUL.md, plus de mappen sessions/, memories/ en skills/. De documentatie beveelt 1 tot 4 GB geheugen en 1 tot 2 cores aan, afhankelijk van het gebruik.

Ik heb de laatste gedateerde versie vastgepind in plaats van latest. De GitHub-releases tonen v0.21.0 (tag v2026.8.31, “The Pantheon Release”), gepubliceerd op 31 augustus 2026, ongeveer 5.800 commits en 760 bijdragers na de vorige versie. Het downloaden duurde 1 min 47 s op deze machine voor 908 MB gecomprimeerd (3,93 GB na uitpakken, arm64-architectuur). De image v2026.4.30, 8,2 GB, plaatst een echte interne architectuurwissel tussen april en mei 2026. Dat controlepunt start nog op tini, terwijl de augustusversie s6-overlay als PID 1 gebruikt, met het opgeven van privileges naar een gebruiker hermes (UID 10000 standaard). Terzijde opgemerkte curiositeit: het Docker Hub-register toont dat het gewicht van de image is gedaald van ongeveer 2,5 GB in april tot minder dan 900 MB sinds juli 2026.

De configuratie beveiligen: netwerk, poorten, secrets

De officiële docker-compose.yml declareert network_mode: host voor zowel de gateway als het dashboard, praktisch, maar zonder enige netwerkisolatie. Voor het lab heb ik een geharde versie gebouwd: eigen netwerk, poorten uitsluitend gepubliceerd op de loopback, secrets buiten het compose-bestand.

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     # eventuele leverancierssleutel, buiten de 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   # zie verderop: zonder deze regel is /health
    deploy:                       #   onbereikbaar, zelfs met gepubliceerde poort
      resources:
        limits:
          memory: 1g
          cpus: "1.0"
    command: ["gateway", "run"]

networks:
  hermes_lab:
    driver: bridge

Twee instellingen van de officiële compose gedragen zich anders dan de documentatie doet verwachten. De eerste gaat over het netwerk. Het markeren als internal: true om alle internetuitgang af te sluiten, sluit ook de gepubliceerde poort af. In het lab krijgt een verzoek vanuit de container zelf een HTTP 200 op /health. Hetzelfde verzoek vanaf de hostmachine, op de gepubliceerde poort, krijgt geen enkel antwoord. Een uitgaande poging naar example.com faalt op een onmogelijke DNS-resolutie. De isolatie houdt dus stand, maar ze neemt het legitieme lokale gebruik van de poort mee. internal: true is alleen geschikt voor een volledig offline lab. Voor echt gebruik met een externe modelleverancier verloopt de isolatie via een klassiek eigen netwerk en een uitgaande firewall, niet via deze instelling.

De tweede is verrassender. Zelfs op het eigen netwerk zonder internal-markering bleef de gepubliceerde poort onbereikbaar, TCP-verbinding geaccepteerd, leeg HTTP-antwoord. Een zoektocht in de geïnstalleerde code geeft de exacte verklaring:

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")

Standaard luistert de gateway alleen op de loopback binnen de container, onafhankelijk van het gekozen Docker-netwerk. Vandaar de regel API_SERVER_HOST=0.0.0.0 in de compose hierboven: die verandert niets aan de externe blootstelling, aangezien het voorvoegsel 127.0.0.1: van de gepubliceerde poort die al beperkt. Geverifieerd na correctie: curl http://127.0.0.1:8642/health antwoordt 200 vanaf de host, hetzelfde verzoek naar het lokale netwerkadres van de machine (192.168.x.x) krijgt geen enkel antwoord. Wat het dashboard betreft, dat weigert botweg te starten op een niet-lokale interface zonder geconfigureerde authenticatieprovider:

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.

Gezond standaardgedrag, met een neveneffect dat in de logs zichtbaar is. Zomaar gelaten, zonder geconfigureerde authenticatie, blijft de dienst niet simpelweg uitgeschakeld, hij faalt en herstart in een lus onder het toezicht van s6. Niets ernstigs, maar luidruchtig genoeg om het te weten. Laatste geverifieerd punt: de limiet deploy.resources.limits van de compose hierboven is wel degelijk van toepassing buiten Swarm-modus met Docker Compose v5.1.0. docker inspect bevestigt Memory=1073741824 en NanoCpus=1000000000 op de gestarte container. Oudere Compose-versies negeerden deploy: buiten Swarm.

Wat je bij het opstarten ziet

Zodra de configuratie is gecorrigeerd, geven docker compose up -d en vervolgens een peiling van /health elke 0,3 seconde een opstarttijd van ongeveer 18,9 seconden koud (lege datamap) en 16,6 seconden na een gewone herstart. Het verschil zit vooral in een interne opwarmfase, die de logs expliciet “turn-machinery warm-up” noemen en die de toegangspoort opent na 20 seconden, ook al loopt ze op de achtergrond door. Binnenin bevestigt ps aux dat de supervisor root blijft, maar dat het proces hermes gateway run wel degelijk draait onder de gebruiker zonder privileges hermes. De opstartbanner toont Hermes Agent v0.21.0 (2026.8.31), Python 3.13.5 en de OpenAI-SDK 2.24.0.

Verbinden met een model

Het bestand .env, gegenereerd bij de eerste start, somt, volledig als commentaar, een dertigtal leveranciers op (Fireworks, OpenRouter, NovitaAI, Gemini, z.ai, Kimi, MiniMax, OpenCode Zen…) en evenveel toolsleutels (Firecrawl, Exa, Browserbase), geen enkele is actief. “Ollama” verschijnt er alleen in de vorm OLLAMA_API_KEY, de betaalde clouddienst van Ollama, en geen enkele vermelding richt zich op een lokale instantie. De ingebouwde diagnose bevestigt de neutrale staat van de installatie:

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)

De enige waarde die na de test in .env aanwezig is: een API_SERVER_KEY, automatisch gegenereerd door de container, om zijn eigen lokale gateway te beschermen. Hij verschijnt nooit in platte tekst in de logs, niemand heeft hem ingevoerd, en hij heeft geen verband met een account bij een modelleverancier.

De vaardigheden, en hoe je er een controleert vóór installatie

De vaardigheden (“skills”) leven in /opt/data/skills/ en volgen de open standaard Agent Skills, uitgewerkt in onze gids over het SKILL.md-bestand. hermes skills list telde 53 ingebouwde vaardigheden geactiveerd in dit lab, geen enkele geïnstalleerd vanaf de hub. De installatie verloopt per register: bijvoorbeeld hermes skills install official/security/1password of hermes skills install openai/skills/k8s. Voordat je iets installeert, vermijden twee commando’s dat je blindelings moet vertrouwen:

hermes skills inspect openai/skills/k8s   # metadata, bronrepository, audit al beschikbaar
hermes skills audit                       # scant alle vanaf de hub geïnstalleerde skills opnieuw

De ingebouwde scanner classificeert elk resultaat in drie niveaus: dangerous blokkeert de installatie, warn/caution omzeil je met --force, advisory blijft informatief. Volgens de officiële documentatie verzamelde de hub op 26 augustus 2026 90.700 vaardigheden verspreid over 11 registers, niet te verwarren met “HermesHub”, de externe community-index die hierboven al werd genoemd.

MCP: tools koppelen, of Hermes als server blootstellen

hermes mcp catalog, uitgevoerd in het lab, toont een al lange catalogus van kant-en-klare servers (Airtable, Atlassian, Cloudflare, ClickUp, Buildkite…). hermes mcp list bevestigde dat er geen enkele geconfigureerd was, zoals verwacht op een nieuwe installatie. Het toevoegen gebeurt met een bekende preset of een handmatige invoer:

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

In de andere richting stelt hermes mcp serve een Hermes-sessie bloot als MCP-server aan een externe client, Claude Code bijvoorbeeld, door zijn configuratie naar het commando hermes mcp serve te laten wijzen. Op het vlak van beveiliging preciseert de documentatie drie dingen. Externe OAuth-tokens worden in cache gezet met permissies 0600. De vernieuwing verloopt via PKCE. Voor servers in stdio worden alleen de expliciet gedeclareerde omgevingsvariabelen, plus een minimale basis, aan het subproces doorgegeven. Genoeg om de lekken van secrets naar een slecht geauditeerde externe MCP-server beperkt, een risico dat al is gedocumenteerd in ons artikel over code-agents, sandbox en permissies.

Hermes Agent tegenover OpenClaw: een eerlijke vergelijking

Beide projecten zijn open source, worden onder Docker geïnstalleerd en ondersteunen skills en MCP, het is hun filosofie die verschilt. OpenClaw structureert een gateway die meerdere agents, connectoren en kanalen routeert en bewaakt. Hermes Agent zet in op een enkele agent die zijn eigen vaardigheden opbouwt naarmate hij wordt gebruikt. Ons artikel over de geharde installatie van OpenClaw werkt dezelfde oefening uit aan de kant van OpenClaw, de twee lezen als spiegelbeelden.

Op het vlak van beveiliging telt een onderzoeksnota van de Cloud Security Alliance, gedateerd 4 mei 2026, over dezelfde periode negen CVE’s voor OpenClaw, waaronder één kritieke met score 9,9, tegenover twee voor de kern van Hermes Agent. CVE-2026-7396 gaat over een path traversal in de WeCom-adapter (CVSS 4,0), CVE-2026-7397 over symlink-following in de bestandstools (CVSS 4,8), beide op versie 0.8.0 en al vanaf 0.9.0 gecorrigeerd. Een derde vermelde CVE raakt niet de agent maar hermes-webui, de externe client die hierboven al werd gesignaleerd. De pagina GitHub Security Advisories van de repository vermeldt op 7 september 2026 geen enkel gepubliceerd advies: deze CVE’s zijn via externe kanalen ingediend, niet door Nous Research zelf. Tot vandaag is er geen enkele telling van blootgestelde Hermes-instanties gepubliceerd die vergelijkbaar is met het geverifieerde cijfer voor OpenClaw (42.900 instanties, 93% zonder authenticatie, SecurityScorecard 2026), wat hun afwezigheid niet bewijst.

Een gedateerd incident illustreert waarom netwerkafscherming en het ontbreken van een automatische modus net zo zwaar wegen als de keuze van het project. The Hacker News documenteerde op 24 juli 2026 een geval waarin een aanvaller die al eerste toegang had tot het netwerk van het Thaise ministerie van Financiën, Hermes Agent installeerde op een gehuurde server en vervolgens zijn “YOLO”-modus activeerde, die bevestigingen overslaat vóór risicovolle commando’s. De agent verkende daarna zonder toezicht het netwerk, vond Hadoop-diensten met standaardgegevens en installeerde een implant. Punt dat de bron zelf benadrukt: Hermes veroorzaakte de inbraak niet, hij automatiseerde de volgende fase ervan. Het eigen netwerk, de poorten op de loopback en het ontbreken van een ingevoerde sleutel in dit lab willen precies die fase verhinderen.

Wat je moet onthouden

• De “Hermes Agent” die in 2026 met OpenClaw wordt vergeleken, is die van Nous Research (NousResearch/hermes-agent, MIT-licentie), niet hermes-webui of “HermesHub”, twee externe projecten met een gelijkende naam.
• Laatst geteste gedateerde versie: v0.21.0 (tag v2026.8.31, 31 augustus 2026), geïnstalleerd via Docker in 1 min 47 s (908 MB gecomprimeerd, 3,93 GB uitgepakt).
• Een netwerk gemarkeerd als internal: true sluit ook de gepubliceerde poort af, niet alleen de internetuitgang. Standaard luistert de gateway alleen op zijn eigen loopback (API_SERVER_HOST=127.0.0.1), expliciet te corrigeren, zelfs achter een poort die aan hostkant al beperkt is tot 127.0.0.1.
• Het dashboard weigert zich buiten de loopback bloot te stellen zonder geconfigureerde authenticatie. Gezond standaardgedrag, maar zo gelaten loopt het vast in een foutlus in plaats van gewoon inactief te blijven.
• Opstarttijd gemeten op ongeveer 17 tot 19 seconden tot een werkelijk positieve /health, zonder enige sleutel of identifier ingevoerd van begin tot eind.
• Over dezelfde periode telt de Cloud Security Alliance twee kleine CVE’s voor de kern van Hermes Agent tegenover negen voor OpenClaw, waarvan één kritieke. Het verschil lees je met voorzichtigheid: voor Hermes is geen gelijkwaardige blootstellingstelling gepubliceerd.