OpenClaw und die Lektionen des Agenten-Hypes: Autonomie braucht Sicherheitsarchitektur

Kein KI-Projekt hat das Jahr 2026 bisher so geprägt wie OpenClaw. Der quelloffene KI-Agent des österreichischen Entwicklers Peter Steinberger — zuvor unter den Namen Clawdbot und Moltbot bekannt — sammelte nach seinem viralen Start Ende Januar innerhalb weniger Wochen mehr als 135.000 GitHub-Sterne und wurde zu einem der am schnellsten wachsenden Open-Source-Projekte aller Zeiten. Das Versprechen ist verführerisch: ein persönlicher Assistent, der rund um die Uhr auf dem eigenen Rechner läuft, sich mit jedem beliebigen KI-Modell verbinden lässt und über WhatsApp, Slack oder iMessage Aufträge entgegennimmt — E-Mails senden, Dateien verwalten, im Browser recherchieren, Shell-Kommandos ausführen. Es ist gelebte Modellfreiheit und maximale Autonomie. Und es ist zugleich die bisher größte Sicherheitslektion des Agenten-Zeitalters.

Die Bilanz nach sechs Monaten

Die Sicherheitsforschung hat zu OpenClaw in kurzer Folge Befunde vorgelegt, die in ihrer Deutlichkeit selten sind. Das STRIKE-Team von SecurityScorecard fand rund 42.900 über das Internet erreichbare OpenClaw-Kontrollpanels in 82 Ländern; etwa 15.200 dieser Instanzen galten als anfällig für Remote-Code-Ausführung. Mit CVE-2026-25253 wurde eine kritische Schwachstelle dokumentiert, über die Angreifer lokale Instanzen per Ein-Klick-Angriff übernehmen konnten. Parallel berichteten Sicherheitsanbieter über Kampagnen mit bösartigen Erweiterungen im Community-Marktplatz des Projekts, die auf Zugangsdaten, Cloud-Credentials und Krypto-Wallets zielten. Kaspersky, CrowdStrike, McAfee und andere veröffentlichten binnen Wochen eigene Warnhinweise und Härtungsleitfäden — für ein einzelnes Open-Source-Projekt ein bemerkenswerter Vorgang.

Wichtig für die faire Einordnung: Kaum einer dieser Befunde beruht auf einem neuartigen Modellfehler. Die Probleme sind klassisch — exponierte Verwaltungsoberflächen, schwache Authentifizierung, ungeprüfte Erweiterungen von Dritten, zu weit gefasste Berechtigungen. Neu ist die Fallhöhe: Ein kompromittierter Agent ist kein kompromittiertes Werkzeug, sondern eine kompromittierte Identität mit allen Zugriffsrechten seines Besitzers.

Warum Agenten die Sicherheitsfrage neu stellen

Ein Chatbot, der eine falsche Antwort gibt, erzeugt ein Qualitätsproblem. Ein Agent, der eine falsche Aktion ausführt, erzeugt einen Vorfall. Sobald ein KI-System von der Textausgabe zur Ausführung übergeht — E-Mails versendet, Dateien verändert, Systeme ansteuert —, ändert sich das Sicherheitsmodell grundsätzlich. Der Agent handelt mit echten Privilegien auf Basis von Eingaben, die Dritte beeinflussen können: Eine präparierte E-Mail oder Webseite genügt, um über indirekte Prompt-Injection Anweisungen einzuschleusen, die der Agent als legitimen Auftrag behandelt.

Dazu kommt das organisatorische Muster, das Sicherheitsteams aus der Schatten-IT kennen, nun in verschärfter Form: OpenClaw-Installationen entstehen typischerweise außerhalb jeder Sicherheitsprüfung — auf Privatgeräten, Entwicklerrechnern oder Heimservern, verbunden mit dienstlichen Konten wie E-Mail, Kalender oder Dateiablagen. Aus Sicht der Organisation entsteht damit ein privilegierter Zugangspunkt zu Unternehmensdaten, den niemand inventarisiert, patcht oder überwacht.

Die Lektionen sind übertragbar

Es wäre bequem, die Befunde als Problem eines einzelnen Hobby-Projekts abzutun. Das Gegenteil ist richtig: OpenClaw zeigt im Zeitraffer, welche Fragen jede Organisation beantworten muss, die Agenten produktiv einsetzen will — egal ob selbst gebaut, quelloffen oder eingekauft:

1. Least Privilege für Agenten: Ein Agent braucht granulare, aufgabenbezogene Berechtigungen statt pauschalen Vollzugriff. Jede Berechtigung, die er nicht hat, kann er nicht missbrauchen — und kein Angreifer über ihn.

2. Isolation als Standard: Agenten gehören in kontrollierte Umgebungen — Container, virtuelle Maschinen, dedizierte Konten — und nicht auf das Gerät, auf dem auch das Online-Banking läuft.

3. Vertrauensgrenzen für Eingaben: Alles, was der Agent liest — E-Mails, Webseiten, Dokumente —, ist potenziell feindlicher Input. Kritische Aktionen brauchen deshalb Freigabestufen und Mensch-in-der-Schleife-Momente.

4. Erweiterungen als Lieferkette: Plugins und Skills von Dritten sind Software-Lieferkette und verdienen dieselbe Prüfung wie jede andere Abhängigkeit.

5. Inventar und Beobachtbarkeit: Wer nicht weiß, welche Agenten mit welchen Rechten im Unternehmen laufen, kann sie weder härten noch abschalten.

Was der Befund für regulierte Branchen bedeutet

Für Banken und Versicherer verschärft sich die Lage zusätzlich, weil Agenten hier auf Daten und Prozesse treffen, die besonderen Schutz genießen. Ein Agent, der auf Kundendaten, Freigabeprozesse oder interne Systeme zugreift, ist aufsichtsrechtlich ein IKT-Risiko wie jedes andere kritische System — mit denselben Anforderungen an Zugriffskontrolle, Protokollierung und Vorfallbehandlung. Die Vorstellung, ein Mitarbeiter könne einen frei konfigurierten Agenten mit dienstlichen Zugängen koppeln, ohne dass Risikomanagement und Informationssicherheit davon wissen, ist mit diesem Rahmen unvereinbar. Der pragmatische Weg ist deshalb nicht das Verbot, das erfahrungsgemäß nur die Schatten-IT vergrößert, sondern ein sanktioniertes Angebot: ein unternehmenseigener Agent mit klarem Berechtigungsmodell, zentraler Protokollierung und geprüften Anbindungen — attraktiv genug, dass niemand auf den Bastelweg ausweichen muss. Dass der Bedarf real ist, zeigt gerade der OpenClaw-Fall: Mitarbeiter greifen zu solchen Werkzeugen, weil sie ein echtes Produktivitätsbedürfnis haben. Organisationen, die diesen Bedarf ernst nehmen und kontrolliert bedienen, lösen zwei Probleme auf einmal — sie gewinnen die Produktivität und schließen zugleich die unkontrollierte Fläche.

Autonomie ja — aber als Architekturleistung

Für Unternehmen, insbesondere in regulierten Branchen, ergibt sich daraus eine klare Konsequenz: Die Frage ist nicht, ob KI-Agenten kommen — sie sind da, und ihre Produktivitätsversprechen sind real. Die Frage ist, ob Autonomie als Bastellösung oder als Architekturleistung eingeführt wird. Governance, Berechtigungsmodell, Auditierbarkeit und die Trennung von Wissens- und Ausführungsschicht sind keine Zusatzfunktionen, die man nachrüstet, sondern die Grundlage, auf der Autonomie überhaupt vertretbar wird.

Das gilt auch für die Modellfrage: Die Freiheit, jedes Modell anzuschließen, die OpenClaw so attraktiv macht, ist ein berechtigtes Bedürfnis — Unternehmen wollen sich nicht an einen einzelnen Anbieter ketten. Aber sie gehört in einen Rahmen, der Berechtigungen, Datenzugriff und Protokollierung zentral regelt, statt beides dem Endgerät des einzelnen Mitarbeiters zu überlassen. Modelloffenheit und Sicherheitsarchitektur sind kein Widerspruch — sie sind erst zusammen ein Produkt.

Die OpenClaw-Episode wird in einigen Jahren vermutlich als der Moment gelten, in dem die Branche gelernt hat, Agenten als das zu behandeln, was sie sind: privilegierte digitale Identitäten. Organisationen, die diese Lektion jetzt in ihre Einführungsentscheidungen übersetzen, bekommen beides — die Produktivität autonomer Assistenten und die Kontrolle, die der Ernstfall verlangt.

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.