Hermes WebUI: een briljante cockpit met een architecturale tijdbom onder de motorkap
AIIk heb een zwak voor tools die met minimale middelen maximaal resultaat leveren. Hermes WebUI is precies dat: een browserinterface voor Hermes Agent, gebouwd in twee maanden, zonder build step, zonder framework, zonder bundler. Python backend, zeven vanilla JavaScript modules, 5.303 tests. Het voelt als vakwerk.
En vakwerk heeft soms een haar scheur die je pas ziet als je er met een zaklamp in schijnt.
Wat het wél is — en waarom dat indrukwekkend is
Hermes WebUI is een communityproject (niet van Nous Research zelf) dat je bestaande Hermes Agent een driepanels browserinterface geeft: sessies links, chat midden, workspace file browser rechts. Alles wat je in de CLI kunt doen, kan hier ook — plus dingen die in een terminal gewoon niet werken: token usage ring, Mermaid rendering, file preview met syntax highlighting, tool call cards met subagent nesting.
De featurelijst is opvallend compleet:
- Streaming via SSE met cancellatie en retry
- Meerdere modelproviders per profiel, te wisselen zonder restart
- Workspace file browser met edit/create/delete/rename en Git-detectie
- Tasks, Skills, Memory, Profiles, Todos en Spaces — allemaal via de UI beheerbaar
- SSH tunnel of Tailscale voor veilige externe toegang
- Optionele password auth met PBKDF2 key separation en HMAC-SHA256 session signatures
- Optionele passkeys/WebAuthn
De cijfers liegen er niet om: 9.500 stars, 1.300 forks, 508 releases in twee maanden. De releasecadans is meerdere keren per dag — v0.51.183, .184, en .185 kwamen alledrie op 31 mei 2026 uit.
Dit is geen langzaam groeiend project. Dit is een project in een dead sprint.
De architecturale zwakte die niemand in de README ziet
En hier begint het interessant te worden. De server draait op Python's ThreadingHTTPServer — een stdlib HTTP server die per request een nieuwe thread spawnt. Prima voor single-user localhost. Maar de documentatie vermeldt ergens halverwege de architectuurbeschrijving, bijna terloops:
Per-request environment variables zoals
TERMINAL_CWD,HERMES_EXEC_ASK,HERMES_SESSION_KEYenHERMES_HOMEzijn process-global. Twee gelijktijdige chat requests kunnen elkaar overschrijven.
Dit is geen bug. Dit is een architectuurkeuze. En het betekent dat Hermes WebUI fundamenteel ongeschikt is voor alles wat op multi-user lijkt. Eén gebruiker die twee tabbladen open heeft? De tweede request overschrijft de eerste. Twee teamleden op dezelfde agent? Race condition op HERMES_SESSION_KEY.
De eigen documentatie noemt het "alleen veilig voor single-user, single-concurrent-request gebruik." Dat is eerlijk. Maar het had op regel één van de README moeten staan, niet in de architectuurdocumentatie.
De source coupling: een compatibility bridge die nog een brug nodig heeft
De tweede architecturale zwakte is de afhankelijkheid van Hermes Agent Python source. De WebUI moet de agent source kunnen importeren — in multi-container Docker setups deelt de WebUI een read-only volume met de agent container. De RFC in de repo noemt dit expliciet een "compatibility bridge, niet het gewenste langetermijncontract."
Het gewenste einddoel is een expliciete Agent API voor run lifecycle, events, approvals, profile management, provider catalogus, en session bridge. Tot die tijd is de WebUI intern gekoppeld aan Hermes Agent modules en SQLite schema's.
Voor een persoonlijke installatie is dit acceptabel. Voor een gedeelde teamserver is het een upgrade-nachtmerrie: elke Hermes Agent update kan de WebUI breken, en vice versa.
De security-aandacht die er wél is
Dit is geen onveilig project. Integendeel — de security-aandacht is bovengemiddeld voor een communityproject van twee maanden oud:
| Maatregel | Aanwezig? | Opmerking |
|---|---|---|
| Password auth (opt-in) | ✓ | PBKDF2 + HMAC-SHA256, 24h TTL |
| Passkeys/WebAuthn | ✓ | Optioneel, cryptography package |
| CSP + Permissions-Policy headers | ✓ | Inclusief SRI hashes voor CDN resources |
| CSRF/SSRF/XSS audit | ✓ | Uitgevoerd en gedocumenteerd |
| Bandit (Python SAST) fixes | ✓ | Doorgevoerd |
| Secret isolation per profile | ✓ | Expliciet in architectuur |
| Session-import workspace validation | ✓ | Path traversal bescherming via safe_resolve |
| 20MB POST body limit | ✓ | DOS-mitigatie |
| Slow-client timeout | ✓ | Resource bescherming |
| Docker hardening | ✓ | Geen sudo, geen NOPASSWD, entrypoint re-exec als non-root |
| Concurrency isolation | ✗ | Process-global env vars |
Dat ene kruisje in die tabel is het enige dat telt voor elke serieuze deployment.
De hardening baseline die ik eis
Voor wie Hermes WebUI wél wil gebruiken — en ik raad het aan als persoonlijke cockpit — is dit mijn minimale hardening:
Network. Alleen 127.0.0.1 of Tailscale. Nooit 0.0.0.0 zonder expliciete auth. De Docker compose zet standaard 127.0.0.1:8787 — dat is de juiste default en blijf daar vanaf.
Auth. HERMES_WEBUI_PASSWORD staat standaard uit — een bewuste keuze voor localhost-only deployments. Zodra je de WebUI buiten localhost benadert: password verplicht, passkey waar mogelijk.
Workspace segmentatie. Zet aparte workspaces op voor lab, sites, security-scans en client-demo's. Mount nooit je home directory of een directory met .env-bestanden. De WebUI kan files lezen, schrijven en verwijderen — dat is de bedoeling, maar binnen grenzen.
Agent tools. Shell-approval altijd aan. Geen "always allow" voor destructieve commando's. De WebUI is een bedieningspaneel voor command execution — behandel het als een privileged interface.
Audit. Bewaar command approvals, tool calls, modelkeuze, prompt, output en timestamps. Niet vertrouwen op de ingebouwde session history — die is er voor UX, niet voor forensics.
De vijf fasen naar een veilige cockpit
Voor mijn eigen setup heb ik een gefaseerde aanpak ontworpen die ook als blauwdruk voor klanten kan dienen:
| Fase | Wat | Waarom |
|---|---|---|
| 1. Isolated personal | Docker single-container, 127.0.0.1, SSH tunnel | Basis: alles lokaal, niets exposed |
| 2. Tailscale mobile | Password + passkey, dedicated mobile profile | Vanaf telefoon/tablet, beperkte tools |
| 3. Provider profiles | Lokaal (Ollama), cloud (Claude/Gemini), restricted (low-risk), coding (approval) | Context-afhankelijke modelkeuze |
| 4. Workspace segmentatie | /lab, /sites, /security-scans, /client-demo-sanitized | Nooit productie-secrets in workspace |
| 5. Governance wrapper | MCP/tool allowlists, audit logging, filesystem snapshots, secret scanning | Pas daarna klantdemo's |
De commerciële propositie die hieruit volgt
Hermes WebUI is geen product om te verkopen. Het is een referentie-implementatie voor een patroon dat wél verkoopbaar is: de Agentic Cockpit.
Drie proposities tekenen zich af:
1. Agentic Workstation Assessment. "Wij brengen uw lokale, cloud en agentic tooling onder controle: models, workspaces, credentials, MCP servers, skills, cron, audit en secure access." Dit is een concrete dienst die elke organisatie met AI agents nodig heeft — en die bijna niemand aanbiedt.
2. Secure Agent Cockpit for Regulated Teams. Een gecontroleerde browserlaag voor agentic workflows, met Zero Trust toegang, policy-bound tools, audit evidence en duidelijke scheiding tussen experiment en productie. Gebouwd op het patroon van Hermes WebUI, maar met de governance-wrapper die de communityrepo (terecht) niet levert.
3. AI Operations Runbook Factory. Gebruik Hermes tasks/skills/memory om terugkerende operationele analyses te automatiseren: website security scans, dependency checks, repo assessments, policy diffing, content backlog generatie. Dit is de operationele laag bovenop de agent — en de WebUI maakt het beheerbaar.
Eindoordeel
| Aspect | Score |
|---|---|
| Functionele rijkdom | 8.5/10 |
| Snel inzetbaar persoonlijk | 8/10 |
| Architecturale volwassenheid | 6.5/10 |
| Security-bewustzijn | 7/10 |
| Enterprise readiness | 4.5/10 |
| Strategische waarde voor lab | 8.5/10 |
| Commerciële demo-waarde | 8/10 |
Wel testen, wel opnemen in het agentic lab, niet rechtstreeks productiseren zonder extra boundary, policy gateway en auditlaag.
De beste analogie: Hermes WebUI is een straaljagercockpit — briljant ontworpen voor één piloot, met alle instrumenten binnen handbereik. Maar zet er twee piloten in en ze grijpen naar dezelfde stuurknuppel. De architectuur is niet fout — hij is eerlijk over zijn beperkingen. De kunst is weten wannéér die beperkingen relevant worden.
Voor een persoonlijke agent cockpit op een Mac mini of Ubuntu workstation, achter Tailscale, met gesegmenteerde workspaces: absoluut doen. Voor een gedeelde teamserver: niet voordat je de governance-wrapper hebt gebouwd die de communityrepo (terecht) aan jou overlaat.
DjimIT helpt organisaties bij het ontwerpen van veilige agentic cockpits, MCP proxy architecturen en AI governance frameworks. Neem contact op voor een vrijblijvend gesprek.
AI & Security Intelligence
Wekelijkse nieuwsbrief met AI updates, security alerts en compliance inzichten — direct in uw inbox.
Doorlopend Advies
Wilt u structurele begeleiding op AI, security & compliance?
Met een Advisory Subscription heeft u een externe sparringpartner die meedenkt op strategisch en technisch niveau — zonder de overhead van een fulltime dienstverband. Vanaf €1.500 per maand, maandelijks opzegbaar.
Ontdek Advisory Subscription →