Warum OpenClaw ein anderes Sicherheitsmodell braucht als klassische Software

Der vom österreichischen Entwickler Peter Steinberger gestartete KI-Agent OpenClaw vereint drei Eigenschaften, die ihn grundlegend von klassischer Software unterscheiden. Er hat Zugriff auf private Daten, verarbeitet nicht vertrauenswürdige Inhalte und kommuniziert eigenständig mit der Außenwelt. Sicherheitsexperte Simon Willison nennt diese Kombination das „Lethal Trifecta„. Sie macht herkömmliche Schutzkonzepte wie Sandbox, Firewall und eingeschränkte Rechte wirkungslos. Nicht weil OpenClaw schlecht entwickelt ist. Sondern weil das Produktversprechen selbst die Sicherheitslücke ist.

Ein ausführlicher Bericht von Brian Krebs auf KrebsOnSecurity hat diese Problematik am 8. März 2026 einem breiten Publikum zugänglich gemacht. Der Artikel dokumentiert konkrete Vorfälle, Expertenstimmen und Forschungsergebnisse. Wir von ClawNews nehmen den Bericht zum Anlass für eine eigene Einordnung: Warum reichen die bekannten Sicherheitskonzepte bei KI-Agenten nicht aus? Und was kommt stattdessen?

Was das Lethal Trifecta bedeutet

Simon Willison hat im Juni 2025 ein Konzept beschrieben, das die Kernproblematik von KI-Agenten auf drei Bedingungen reduziert. Willison ist Mitentwickler des Django-Webframeworks und eine der profiliertesten Stimmen zur Sicherheit von KI-Systemen.

Die erste Bedingung: Der Agent hat Zugang zu privaten Daten. E-Mails, Kalender, Dateien, Passwörter oder API-Schlüssel. Bei OpenClaw ist das der Normalzustand. Der Agent verwaltet den Posteingang, verarbeitet Dokumente und greift auf gespeicherte Zugangsdaten zu.

Die zweite Bedingung: Der Agent kommt mit nicht vertrauenswürdigen Inhalten in Kontakt. Eine E-Mail von einem Unbekannten. Eine Webseite mit versteckten Anweisungen. Eine GitHub-Issue mit manipuliertem Titel. Alles, was der Agent verarbeitet, kann manipulierte Anweisungen enthalten.

Die dritte Bedingung: Der Agent ist in der Lage nach außen zu kommunizieren. Er verschickt Nachrichten, ruft Webseiten auf oder stellt API-Anfragen. Über jede dieser Verbindungen ist es möglich, gestohlene Daten an einen Angreifer weiterzuleiten.

Wenn alle drei Bedingungen gleichzeitig erfüllt sind, können Angreifer private Daten stehlen. Nicht theoretisch, sondern praktisch. Willison hat dieses Muster bei Microsoft Copilot, GitHub, Google, Slack, Anthropic und zahlreichen weiteren Diensten dokumentiert. Fast immer wurde die Lücke schnell geschlossen. Aber bei OpenClaw liegt das Problem tiefer. Der Agent erfüllt alle drei Bedingungen nicht aus Versehen, sondern absichtlich. Sie sind das Produktversprechen.

Anzeige

Warum klassische Sicherheitskonzepte hier versagen

Bei herkömmlicher Software funktionieren drei bewährte Schutzschichten. Sandbox, Firewall und das Prinzip der minimalen Rechte. Jede dieser Schichten schränkt ein, was ein Programm darf. Genau das macht sie wirksam. Aber genau das macht sie bei OpenClaw wirkungslos.

Eine Sandbox begrenzt den Dateizugriff. OpenClaw braucht aber Dateizugriff, um Aufgaben zu erledigen. Eine Firewall kontrolliert den Netzwerkverkehr. OpenClaw braucht aber Netzwerkzugang, um E-Mails zu versenden, Webseiten aufzurufen und mit Messenger-Diensten zu kommunizieren. Das Prinzip der minimalen Rechte reduziert Berechtigungen auf das Nötigste. Doch bei OpenClaw lässt sich vorher nicht festlegen, welche Aufgabe der Agent als Nächstes übernimmt. Breite Rechte sind deshalb unvermeidbar.

Wie konkret dieses Problem ist, hat Jamieson O’Reilly gezeigt. O’Reilly ist Gründer der Sicherheitsfirma DVULN und arbeitet als Security Lead für OpenClaw. In einem Beitrag auf X dokumentierte er, dass zahlreiche OpenClaw-Installationen ihre Web-Oberfläche ungeschützt im Internet erreichbar machen. Angreifer können darüber die gesamte Konfigurationsdatei auslesen. Darin stehen sämtliche Zugangsdaten des Agenten. Mit diesen Daten lässt sich der Agent vollständig übernehmen. Wir haben die Sicherheitsrisiken von OpenClaw bereits ausführlich analysiert.

Der Zielkonflikt ist fundamental: Jede Sicherheitsmaßnahme, die den Agenten einschränkt, reduziert gleichzeitig seinen Nutzen. Das ist kein Fehler in der Implementierung. Das ist ein strukturelles Problem.