OpenClaw vs. Hermes Agent: Der ehrliche Vergleich der zwei dominierenden KI-Agent-Frameworks 2026

OpenClaw und Hermes Agent zählen zu den meistdiskutierten Open-Source-KI-Agent-Frameworks des Jahres 2026. Beide haben sich innerhalb kurzer Zeit als ernstzunehmende Optionen für selbst gehostete Agent-Systeme etabliert, beide werden in technischen Communities intensiv beobachtet, und beide bringen sehr unterschiedliche Vorstellungen davon mit, wie ein KI-Agent strukturiert sein sollte. Genau diese Unterschiede machen einen Vergleich lohnenswert.

Dieser Beitrag ist bewusst neutral angelegt. Er ruft keinen Gewinner aus, sondern liefert Entscheidern und erfahrenen Entwicklerinnen und Entwicklern die Informationen, die nötig sind, um eine eigene fundierte Wahl zu treffen. Wir betrachten die Herkunftsgeschichte beider Projekte, vergleichen ihre Architekturen, gehen die Release-Geschichten beider Frameworks durch, analysieren die Sicherheitsmodelle und die in OpenClaw dokumentierten CVEs, dokumentieren die Supply-Chain-Vorfälle rund um ClawHub, listen Chancen und Risiken auf und schließen mit einer Vergleichstabelle, die alle wesentlichen Dimensionen auf einen Blick verfügbar macht.

Zur Einordnung verweisen wir an den passenden Stellen auf bestehende Vertiefungen im innfactory.ai-Blog, insbesondere auf die Architektur-Erklärung zu OpenClaw, die Sicherheitsbetrachtung des Agenten und den Leitfaden zum OpenClaw-Ökosystem mit ClawHub, NemoClaw und NanoClaw.

OpenClaw, ein Projekt mit vielen Namen

OpenClaw ist unter mehreren Namen aufgetaucht. Ursprünglich hieß das Projekt Moltbot und war eine persönliche Entwicklung von Peter Steinberger. Mit dem Wechsel Steinbergers zu OpenAI am 14. Februar 2026 wurde das Projekt in ein Stiftungsmodell überführt und gleichzeitig in OpenClaw umbenannt. Die GitHub-Organisation läuft unter openclaw, das kommerzielle SaaS-Frontend unter openclawai.io.

Wichtig für die Einordnung der Versionsnummern, denen Leserinnen und Leser in Issue-Trackern und CVE-Datenbanken begegnen, ist die Tatsache, dass das Projekt schon vor dem offiziellen Launch existierte. Die Frühphase verlief in einer v0.x-Serie, die bis v0.4.2 reichte. In dieser Frühphase wurden die kritischen Sicherheitsschwächen, die später als CVE-2026-25253, CVE-2026-25891 und CVE-2026-26102 dokumentiert wurden, eingeführt und schließlich behoben.

Die Versionssprünge von v0.x auf v3.x sind Teil der Branding-Geschichte. Im November 2025 erschien v3.0 mit Multi-Model-Support und einem Workspace-System. Am 10. Januar 2026 folgte v3.5 mit Voice-Anbindung (ElevenLabs, Edge TTS, Whisper STT) und Browser-Automation auf Playwright-Basis. Der eigentliche öffentliche Rollout der kommerziellen Plattform Ende Januar 2026 markierte den Punkt, ab dem OpenClaw breiter wahrgenommen wurde. Am 20. Februar 2026 wurde mit v4.0 eine vollständige Architektur-Neufassung veröffentlicht. v4.0 trägt die Bezeichnung „The Agent OS" und führte den Gateway-Daemon, das Canvas-System, Unterstützung für über fünfzehn Messaging-Plattformen und Cron-Scheduling ein. Damit war OpenClaw architektonisch nicht mehr identisch mit dem, was zuvor als Moltbot bekannt war.

Hermes Agent, ein Projekt aus dem Research-Lab

Hermes Agent ist das Agent-Framework des Open-Source-Labors Nous Research, das in der KI-Community vor allem für die Hermes-Modellreihe bekannt geworden ist. Das GitHub-Repository wurde am 22. Juli 2025 angelegt und über etwa acht Monate hinweg intern weiterentwickelt, bevor der erste öffentliche Release-Tag gesetzt wurde. Der öffentliche Launch erfolgte am 12. März 2026 mit Version 0.2.0. Die Lizenz ist MIT.

Die Commit-Verteilung zeigt eine relativ klare Kernautorenschaft mit breiter Community-Beteiligung. Lead-Contributor ist teknium1 mit 2.549 Commits, gefolgt von 0xbyt4 mit 180 Commits. Darüber hinaus haben über 300 weitere Personen aus der Community beigetragen. Damit folgt das Projekt einem Modell, das im akademischen Open-Source-Umfeld verbreitet ist, also klare Maintainer plus eine breite Beitragsbasis.

Anders als OpenClaw verfolgt Hermes Agent kein kommerzielles SaaS-Modell. Es gibt keine offizielle Hosting-Plattform, kein Abomodell und keinen Marketplace im Stil von ClawHub. Stattdessen stellt Nous Research über das Nous Portal Modelle zur Verfügung, darunter MiMo v2 Pro, das im Rahmen des Portals kostenfrei nutzbar ist.

Architektur-Vergleich

OpenClaw und Hermes Agent beantworten dieselbe Frage, wie sich ein Agent mit der Außenwelt verbindet, ganz unterschiedlich. OpenClaw setzt auf ein Hub-and-Spoke-Modell mit einem zentralen Gateway-Daemon. Hermes Agent setzt auf einen modularen Ansatz, dessen primäre Einstiegsfläche ein Command Line Interface ist und der Messaging-Anbindungen nur optional als Gateway-Modus aktiviert.

OpenClaw, Hub-and-Spoke mit Gateway-Daemon

Im Zentrum von OpenClaw steht ein langlebiger Daemon, das Gateway. Es bindet alle Messaging-Adapter direkt im eigenen Prozess ein, darunter WhatsApp über Baileys und Telegram über grammY. Eingehende Frames werden gegen JSON-Schemas validiert, und die gesamte Kommunikation zwischen Clients und dem Daemon läuft über eine typisierte WebSocket-API auf ws://127.0.0.1:18789. Pro Host läuft genau ein Gateway.

WhatsApp / Telegram / Slack / Discord / Signal / iMessage / ...
               │
               ▼
┌───────────────────────────────┐
│         Gateway (Daemon)      │
│       (Control Plane)         │
│     ws://127.0.0.1:18789      │
└──────────────┬────────────────┘
               │
               ├─ Agent Runtime (RPC)
               ├─ CLI (openclaw ...)
               ├─ WebChat UI
               ├─ macOS App
               └─ iOS / Android Nodes

Das Wire Protocol kennt drei Frame-Typen. Ein req-Frame ist eine Client-Anfrage an das Gateway. Ein res-Frame ist die zugehörige Antwort vom Gateway. Ein event-Frame ist eine Server-seitige Push-Nachricht. Der erste Frame nach Verbindungsaufbau muss immer ein connect-Frame sein, der bei nicht-lokalen Verbindungen einen Token mitliefert. Als Single Source of Truth dienen TypeBox-Schemas. Es gibt sechs Event-Typen, darunter agent, chat, presence, health, heartbeat und cron.

Das Session-Management läuft in der Default-Konfiguration über eine gemeinsame DM-Session pro Agent (main). Für Multi-User-Setups existiert ein opt-in aktivierbarer Secure DM Mode, der DMs pro Absender isoliert. Sessions werden als JSONL unter ~/.openclaw/agents/<agent-id>/sessions/ persistiert. Skills sind hot-reloadable, und der Marketplace ClawHub steht seit v4.1 bereit.

OpenClaw unterstützt OpenAI, Anthropic, Google, Ollama und OpenRouter als Modellanbieter, sowohl lokal als auch remote.

Hermes Agent, modular und CLI-first

Hermes Agent kehrt das Verhältnis um. Der primäre Einstiegspunkt ist die Command Line, nicht ein Daemon mit eingebauten Messaging-Adaptern. Der Gateway-Modus ist eine optionale Erweiterung, die Telegram, Discord, WhatsApp, Slack, Feishu, Lark und WeCom anbindet. Container-Backends sind dagegen erste Wahl: Hermes Agent unterstützt Docker, Singularity, Modal, Daytona und Vercel Sandbox.

Das Skill-System ähnelt dem von OpenClaw, weicht aber in einem entscheidenden Punkt ab. Ab v0.12 läuft ein autonomer Curator-Hintergrundprozess, der die Skill-Library selbstständig bewertet, nicht mehr genutzte Skills entfernt und redundante Skills konsolidiert. Das Memory-System ist pluggable und unterstützt unter anderem Honcho als Provider. Auch Browser-Automation ist anders gelöst. Statt eines Standard-Playwright-Setups bringt Hermes Agent ab v0.7.0 den Camofox Anti-Detection Browser mit, der explizit für Sites mit Bot-Detection optimiert ist.

Bei der MCP-Integration geht Hermes Agent einen architektonisch ungewöhnlichen Weg. Das Framework kann selbst als MCP-Server fungieren und damit Dienste für andere Agenten bereitstellen. Ab v0.8.0 wird zudem MCP OAuth 2.1 unterstützt. Beides zusammen erlaubt es, mehrere Hermes-Instanzen oder andere Agent-Frameworks als föderiertes Mesh zu betreiben.

Release-Geschichte

Die folgenden Tabellen fassen die wichtigsten Releases beider Frameworks zusammen, soweit sie für eine sicherheits- und architekturgetriebene Bewertung relevant sind.

Releases von OpenClaw

Releases von Hermes Agent

Bemerkenswert ist die Release-Kadenz von Hermes Agent in den ersten 50 Tagen nach Launch. Zwischen 12. März und 30. April 2026 lagen sechs nummerierte Releases. Auch der Sprung von 95 zu 168 zu 209 zu über 550 gemergten Pull Requests pro Release zeigt eine sehr aktive Community-Beteiligung. OpenClaw zeigt im selben Zeitraum eine andere Charakteristik. Die Releases sind seltener, die Schritte sind dafür größer und enthalten in jedem Fall strukturelle Architekturänderungen.

Sicherheitskonzepte im Vergleich

Bei den Sicherheitsmodellen beider Frameworks zeigt sich der vielleicht deutlichste Unterschied. OpenClaw hat in der Frühphase ein eher permissives Modell vorgesehen und sich nach öffentlich bekannt gewordenen Vorfällen reaktiv weiterentwickelt. Hermes Agent hat ein Sicherheitsmodell mit sieben dokumentierten Schichten von Anfang an als Designprinzip verankert.

Sicherheitsphilosophie von OpenClaw

Das ursprüngliche Sicherheitsmodell von OpenClaw war stark Skill-zentriert. Skills, die über das Plugin-System geladen wurden, konnten in einer Sandbox laufen, die jedoch in der Frühphase deutliche Lücken aufwies. Microsoft hat in einem öffentlichen Advisory vom 6. Februar 2026 das Default-Permission-Modell von OpenClaw als „overly permissive for enterprise environments" beschrieben. Im selben Advisory wurden Sandboxed Environments, Network Segmentation und Approval-Workflows für Skill-Installation als Mindestmaßnahmen empfohlen.

Mit den Releases v0.3.3, v0.4.1 und v0.4.2 wurden die in den nächsten Abschnitten beschriebenen CVEs adressiert. Mit v4.0 wurde die Architektur grundlegend überarbeitet. Mit v4.1 wurde ClawHub um eine Skill-Scan-Partnerschaft erweitert. Die Entwicklung verläuft also reaktiv, aber sichtbar.

Sicherheitsphilosophie von Hermes Agent

Hermes Agent unterscheidet sich grundlegend, weil die Sicherheitsschichten Teil der initial dokumentierten Architektur sind. Konkret sind das sieben Schichten, die jeweils einen klar abgegrenzten Bedrohungsvektor adressieren.

Die erste Schicht ist die User Authorization am Gateway. Die Reihenfolge der Checks läuft über Per-Plattform Allow-All Flag, DM-Pairing Approved List, plattform-spezifische Allowlists, globale Allowlist, globale Allow-All und endet im Default mit einem Deny. Das DM-Pairing-System folgt OWASP-Empfehlungen und NIST SP 800-63-4. Es verwendet einen achtstelligen Code aus einem 32-stelligen unzweideutigen Alphabet ohne 0, O, 1 und I, generiert über secrets.choice(). Die Code-TTL beträgt eine Stunde, das Rate-Limit liegt bei einer Anfrage pro Nutzer pro zehn Minuten. Es sind maximal drei ausstehende Codes pro Plattform zulässig, und nach fünf fehlgeschlagenen Approvals wird der Nutzer eine Stunde gesperrt. Pairing-Dateien werden mit chmod 0600 gespeichert, Codes erscheinen nie in stdout.

Die zweite Schicht ist Dangerous Command Approval. Hermes Agent prüft jede Befehlsausführung gegen eine kuratierte Liste gefährlicher Muster. Drei Approval-Modi sind konfigurierbar. Im Modus manual (Standard) wird jede Ausführung manuell bestätigt. Im Modus smart bewertet ein auxiliäres LLM das Risiko und entscheidet, ob automatisch genehmigt, automatisch abgelehnt oder manuell gefragt wird. Im Modus off sind alle Checks deaktiviert, was funktional dem YOLO-Modus entspricht. Der YOLO-Modus selbst lässt sich per Flag --yolo, per Slash-Command /yolo oder per Umgebungsvariable HERMES_YOLO_MODE=1 aktivieren. Bei Timeout greift Fail-Closed.

Unabhängig vom Approval-Modus existiert eine Hardline Blocklist, die nicht umgehbar ist. Sie greift vor allen anderen Approval-Layern und kennt kein Override-Flag. Die folgende Tabelle listet die wichtigsten Einträge.

Die dritte Schicht ist Container Isolation. Hermes Agent unterstützt Docker mit gehärteten Security-Flags, ohne Privileged Mode und ohne sensitive Mounts im Default. Daneben werden Singularity für HPC-Umgebungen, Modal für serverlose Ausführung sowie Daytona und Vercel Sandbox unterstützt. Innerhalb eines Containers werden Dangerous-Command-Checks automatisch übersprungen, da der Container selbst die Sicherheitsgrenze darstellt.

Die vierte Schicht ist MCP Credential Filtering. MCP-Subprozesse erhalten nur die explizit für sie freigegebenen Umgebungsvariablen. Credential Redaction ist implementiert, SSRF-Schutz ist vorhanden, und vor jeder Ausführung läuft ein Tirith Pre-Exec Security Scan über die MCP-Konfiguration.

Die fünfte Schicht ist Context File Scanning. Projektdateien werden vor der Verarbeitung auf Prompt-Injection-Muster geprüft. Das ist eine direkte Antwort auf die Art von Angriff, die im OpenClaw-Ökosystem als CVE-2026-35650 dokumentiert wurde.

Die sechste Schicht ist Cross-Session Isolation. Sessions können nicht auf Daten oder State anderer Sessions zugreifen. Cron-Job-Storage-Paths sind gegen Path-Traversal-Angriffe gehärtet, also gegen die Art von Angriff, die im OpenClaw-Ökosystem als CVE-2026-25253 dokumentiert wurde.

Die siebte Schicht ist Input Sanitization. Working-Directory-Parameter in Terminal-Tool-Backends werden gegen Allowlists validiert. Shell-Injection wird damit auf Infrastruktur-Ebene unterbunden.

Hinzu kommt MCP OAuth 2.1, das ab v0.8.0 implementiert ist. Es löst architektonisch genau das Problem, das im OpenClaw-Ökosystem als CVE-2026-25891 bekannt geworden ist, also leere Authorization-Header, die als gültig akzeptiert wurden.

CVE-Liste für OpenClaw

OpenClaw hat in der Frühphase mehrere CVEs aufgesammelt, die jeweils einen eigenen Angriffsvektor adressieren. Die folgende Übersicht orientiert sich an den öffentlich dokumentierten Einträgen und greift Stand Mai 2026.

CVE-2026-25253, Skill Sandbox Escape

Diese Schwachstelle ist mit CVSS 9,1 als Critical eingestuft. Betroffen sind Versionen v0.1.0 bis v0.3.2, behoben wurde sie in v0.3.3. Disclosed am 8. Februar 2026. Die Ursache ist ein Path-Traversal-Bug im Skill Loader. Skills konnten Pfade wie ./data/../../../.ssh/id_rsa deklarieren. Das Sandbox-System wertete den Pfad als „innerhalb des Skill-Verzeichnisses" aus, bevor die Traversal-Sequenz aufgelöst wurde. Die Folge war Leseberechtigung auf beliebige Dateien im Hostsystem, darunter SSH-Keys, AWS Credentials, die OpenClaw-eigene ~/.openclaw/identity.json und Browser-Credential-Stores. Diese Schwachstelle wurde im Rahmen der ClawHavoc-Kampagne aktiv ausgenutzt. Mindestens 47 bösartige Skills haben den Bug verwendet.

CVE-2026-25891, MCP Server Authentication Bypass

Diese Schwachstelle ist mit CVSS 8,4 als High eingestuft. Betroffen sind Versionen v0.2.0 bis v0.4.1, behoben in v0.4.2. Disclosed am 19. Februar 2026. Die Ursache ist, dass MCP-Server leere Authorization-Header als gültig akzeptierten. Der Check prüfte nur die Anwesenheit des Headers, nicht aber seinen Inhalt. Jeder lokale Prozess konnte sich damit ohne Authentifizierung mit beliebigen MCP-Servern verbinden. Diese Schwachstelle wurde in der MCP-Proxy-Kampagne genutzt, um Tool-Invocations an Angreifer-kontrollierte Server zu spiegeln.

CVE-2026-26102, Identity File Injection

Diese Schwachstelle ist mit CVSS 7,8 als High eingestuft. Betroffen sind Versionen v0.1.0 bis v0.4.0, behoben in v0.4.1. Disclosed am 14. Februar 2026. Die Ursache ist, dass Skills die zentrale Identitätsdatei ~/.openclaw/identity.json über die Configuration-API überschreiben konnten, ohne dass eine Nutzerbenachrichtigung oder ein Permission-Check ausgelöst wurde. Die Folge war eine stille Eskalation der Berechtigungen, Persistenz über Sessions hinweg und die Möglichkeit, API-Routing-Konfigurationen umzubiegen. Zwölf Varianten in ClawHavoc haben diese Lücke genutzt, um alle LLM-API-Calls an einen externen Server zu duplizieren.

CVE-2026-24763 und CVE-2026-25157, Command Injection

Beide CVEs sind mit CVSS 7,5 als High eingestuft. Es handelt sich um zwei separate Command-Injection-Schwachstellen im Gateway-Input-Handling. Shell-Metacharacter in unsanitisierten Input-Feldern erlaubten in beiden Fällen die Ausführung beliebiger Befehle. Beide Schwachstellen wurden in nachfolgenden Gateway-Releases behoben.

CVE-2026-35650, Prompt Injection und Agent Config Hijack

Diese Schwachstelle zeigt, dass die Angriffsfläche nicht nur auf Infrastruktur-Ebene liegt, sondern auch das LLM-Verhalten selbst zur Schwachstelle werden kann. Prompt-injizierter Modell-Output konnte Agent-Konfigurationen überschreiben, womit ein Policy-Bypass und ein Host-Override möglich wurden. Im Hermes-Agent-Sicherheitsmodell wird diese Klasse von Angriff durch die Schicht Context File Scanning adressiert.

Supply-Chain-Vorfälle bei OpenClaw

OpenClaw war 2026 das Ziel zweier dokumentierter Supply-Chain-Kampagnen, die jeweils unterschiedliche Angriffstechniken nutzen. Beide laufen über den ClawHub-Marketplace, sind also typische Beispiele für Risiken, die im Zusammenhang mit Plugin-Ökosystemen entstehen.

ClawHavoc

Erste Beobachtung am 3. Februar 2026. Status laut öffentlich verfügbaren Quellen Mitte März 2026 ongoing. Im Rahmen der Kampagne wurden 1.184 bösartige Pakete auf ClawHub identifiziert. 23 legitime Publisher-Accounts wurden kompromittiert, was Auto-Update-Nutzer ohne eigene Aktion infiziert hat. Drei distinct Threat-Actor-Cluster wurden identifiziert. Die Gesamtschätzung der Installationen vor Entfernung der Pakete liegt zwischen 15.000 und 25.000.

Die Angriffstechniken umfassten Typosquatting, also Paketnamen wie openclw-gmail statt openclaw-gmail, Dependency Confusion über falsch deklarierte Prerequisites, legitim wirkende Skills mit versteckten Payloads sowie Publisher-Account-Takeovers. Auf der Payload-Seite reichten die Funktionen von Credential-Diebstahl, der SSH-Keys, AWS Credentials, API-Keys und Browser-Credential-Stores erfasste, über AMOS Stealer als macOS-spezifische Komponente und ClickFix Social Engineering bis hin zu Cryptominer (XMRig), API-Key-Exfiltration via MCP-Proxy und Identity-File-Modification zur Persistenz.

MCP-Proxy-Kampagne

Erste Beobachtung am 15. Februar 2026. Die Kampagne ist raffinierter als ClawHavoc, weil sie nicht auf offensichtlich bösartige Skills setzt, sondern eine bestehende Infrastruktur unbemerkt umlenkt. Der Angriff läuft in drei Stufen. Zunächst installiert ein bösartiger Skill einen legitim wirkenden MCP-Server. Anschließend registriert sich dieser MCP-Server als Proxy für bestehende MCP-Server unter Ausnutzung von CVE-2026-25891. Schließlich werden alle Tool-Invocations geloggt und an einen Angreifer-Server exfiltriert. Aus Sicht der Nutzer funktioniert das System unauffällig weiter.

Enterprise-Advisories

Im Februar 2026 haben mehrere große Sicherheitsanbieter eigene Advisories zu OpenClaw veröffentlicht. Microsoft hat am 6. Februar 2026 das Default-Permission-Modell als zu permissiv für Enterprise-Umgebungen eingestuft. CrowdStrike hat am 10. Februar 2026 berichtet, dass Angriffe auf AI-Developer-Tools im ersten Quartal 2026 um 300 Prozent gestiegen sind und OpenClaw dabei das am häufigsten angegriffene Framework war. Palo Alto Networks Unit 42 hat am 12. Februar 2026 das Lethal-Trifecta-Framework veröffentlicht, das die Kombination aus Read Access, Network Access und Ability to Act als maximales Risikoprofil bezeichnet und die strukturelle Trennung mindestens eines dieser Faktoren als Mindeststandard fordert. Cisco Talos hat am 14. Februar 2026 eine C2-Infrastruktur-Karte, YARA-Rules für ClawHavoc und einen frei verfügbaren ClawHub Skill Scanner veröffentlicht. Meta hat am 18. Februar 2026 auf das Risiko von Agent-zu-Agent-Propagation in verknüpften Workflows hingewiesen. Die niederländische Datenschutzbehörde hat als erste europäische Aufsichtsbehörde ein offizielles Advisory zu OpenClaw-Installationen herausgegeben.

Diese Advisories sind nicht als generelles Negativurteil zu lesen. Sie zeigen vielmehr, dass das Framework von professionellen Sicherheitsorganisationen ernst genommen wird. Vergleichbare Advisories zu Hermes Agent existieren Stand Mai 2026 nicht, was sich aus der wesentlich jüngeren öffentlichen Verfügbarkeit und dem konservativer ausgelegten Sicherheitsmodell erklären lässt.

Chancen beider Frameworks

Beide Frameworks haben aus Sicht von Unternehmen eigenständige Vorzüge, die je nach Anforderungsprofil unterschiedlich ins Gewicht fallen.

OpenClaw bringt zunächst das deutlich größere Ökosystem mit. Der ClawHub-Marketplace deckt eine breite Skill-Bandbreite ab, und durch die kommerzielle SaaS-Variante unter openclawai.io existiert ein Einstiegspfad für Teams, die nicht selbst hosten wollen. Die Messaging-Plattform-Unterstützung ist ungewöhnlich breit und umfasst neben WhatsApp, Telegram und Slack auch Discord, Signal, iMessage, Google Chat, Microsoft Teams, Matrix, BlueBubbles, Zalo und WebChat. Das Canvas-UI-System bietet Visualisierungs- und Interaktionsmöglichkeiten, die im Agent-Framework-Umfeld selten sind. Mit dem Agent Communication Protocol seit v4.2 existiert ein eigener Standard für Inter-Agent-Kommunikation, der Sub-Agent-Spawning und Thread-bound Sessions unterstützt. Das Release-Tempo, gepaart mit der Foundation-Struktur, lässt eine stabile Weiterentwicklung erwarten.

Hermes Agent punktet vor allem mit seinem proaktiv designten Sicherheitsmodell. Die sieben Sicherheitsschichten adressieren genau die Klasse von Angriffen, die im OpenClaw-Ökosystem in der Frühphase aufgetreten sind, ohne dass dafür reaktiv nachgebessert werden musste. Die MIT-Lizenz ohne kommerzielle Bindung und das Fehlen einer parallelen SaaS-Variante machen das Framework attraktiv für Organisationen, die strikt auf selbst gehostete Lösungen setzen. Die Release-Kadenz ist hoch, die Community ist aktiv, und mit Nous Research steht eine in der Forschung etablierte Organisation hinter dem Projekt. Der Curator als autonomer Skill-Library-Manager ist eine Funktion, für die OpenClaw kein direktes Pendant kennt. MCP OAuth 2.1 ist ein neuer Standard, der im Hinblick auf föderierte Agent-Setups erheblich an Bedeutung gewinnen dürfte.

Risiken beider Frameworks

Beide Frameworks haben auch Risiken, die ehrlich benannt werden müssen.

Bei OpenClaw stehen die in der Frühphase aufgetretenen CVEs und die dokumentierten Supply-Chain-Kampagnen im Vordergrund. Das ClawHub-Ökosystem ist nach wie vor groß und damit ein attraktives Ziel für Angreifer. Auch nach den Sicherheits-Patches bleibt das ursprünglich permissive Default-Permission-Modell ein Element, das in regulierten Branchen sorgfältig konfiguriert werden muss. Mit dem Wechsel des Ursprungsentwicklers Peter Steinberger zu OpenAI ist außerdem eine Abhängigkeit vom OpenAI-Ökosystem entstanden, die strategisch betrachtet werden sollte. Die Foundation-Struktur federt das ab, eliminiert es aber nicht. Hinzu kommen die fortlaufenden Enterprise-Advisories, die Compliance-Teams im Genehmigungsprozess berücksichtigen müssen.

Bei Hermes Agent stehen andere Risiken im Vordergrund. Das Framework ist mit einem öffentlichen Launch im März 2026 deutlich jünger als OpenClaw. Das Ökosystem ist kleiner, und es gibt weder ein kommerzielles Support-Angebot noch eine offizielle Hosting-Variante. Der YOLO-Modus, der alle Approval-Prompts deaktiviert, ist in CI/CD-Umgebungen oder bei automatisierten Setups ein potenzielles Risiko, wenn er unkritisch aktiviert wird. Die Hardline Blocklist mildert das ab, hebt es aber nicht auf. Auch wenn bis Mai 2026 keine CVEs öffentlich dokumentiert sind, sagt das nichts über die Existenz von Schwachstellen aus, sondern nur über deren öffentlichen Bekanntheitsgrad. Dass Hermes Agent von einer kleineren Maintainer-Basis getragen wird, kann je nach Blickwinkel als Stärke (klare Verantwortung) oder als Risiko (Bus-Faktor) gelesen werden.

Große Vergleichstabelle

Die folgende Tabelle fasst alle wesentlichen Vergleichsdimensionen zusammen.

Fazit

Wer den Vergleich beider Frameworks bis hierher gelesen hat, dürfte erkannt haben, dass die Frage „Welches ist besser?" zu kurz greift. Die beiden Projekte beantworten teils dieselben, teils unterschiedliche Anforderungen, und sie tun das auf strukturell verschiedene Weise.

OpenClaw ist das deutlich breitere und ältere Projekt mit einem reicheren Ökosystem, mehr Messaging-Plattformen, einem kommerziellen SaaS-Pfad und einer aktiven Community rund um den ClawHub-Marketplace. Es hat in der Frühphase eine schwierige Sicherheitsphase durchlaufen, die in den vorgestellten CVEs und Supply-Chain-Kampagnen dokumentiert ist. Die Foundation-Struktur und die Architektur-Neufassung mit v4.0 zeigen, dass das Projekt aus dieser Phase erkennbar lernt.

Hermes Agent ist das jüngere, aber sicherheitstechnisch konservativer ausgelegte Projekt. Es bringt ein dokumentiertes, siebenschichtiges Sicherheitsmodell mit, das viele der Schwachstellenklassen aus dem OpenClaw-Umfeld architektonisch adressiert. Es ist rein selbst gehostet, MIT-lizenziert und community-getrieben. Das Ökosystem ist kleiner, dafür wirken die Designentscheidungen geradliniger.

Eine sinnvolle Entscheidungshilfe orientiert sich an drei Fragen. Erstens, welches Messaging- und Channel-Spektrum braucht das eigene Setup? OpenClaw bietet hier deutlich mehr. Zweitens, wie groß ist die eigene Risikotoleranz gegenüber Plugin-Ökosystemen mit dokumentierten Supply-Chain-Vorfällen, und wie viel Aufwand kann in eine Hardening-Strategie fließen? Bei hoher Risikotoleranz oder verfügbarem Hardening-Budget bleibt OpenClaw eine valide Option. Bei niedrigerer Risikotoleranz oder strikten Compliance-Anforderungen verschiebt sich das Bild in Richtung Hermes Agent. Drittens, wie wichtig ist eine kommerzielle Bezugsquelle mit SaaS-Option? OpenClaw bietet diese, Hermes Agent nicht.

Eine vorschnelle Festlegung ist in beiden Richtungen verfehlt. Beide Frameworks sind 2026 berechtigte Optionen, beide haben Stärken, beide haben Risiken, und beide entwickeln sich schnell weiter. Für eine fundierte Entscheidung lohnt sich der Blick auf die jeweils aktuelle Release-Note und die Sicherheitsdokumentation, nicht zuletzt deshalb, weil sich die hier dargestellten Befunde mit jedem Release verschieben können.