TL;DR
- Ohne ausreichende technische Kenntnisse und ein Verständnis der Sicherheitsrisiken sollten wir keine KI-Assistenten einsetzen.
- Selbst bei fundierter technischer Expertise wächst mit jedem neuen Skill in aktuellen KI-Assistenten-Architekturen das Risiko im Sinne der Lethal Trifecta.
This blog post is also available in English
OpenClaw (früher Clawd und Moltbot) ist derzeit in aller Munde und zugleich ein massiver Sicherheitsalbtraum. In diesem Beitrag spreche ich allgemein von KI-Assistent, denn OpenClaw ist inzwischen alt genug, um zahlreiche vibe-codete Nachahmer hervorgebracht zu haben. Die hier formulierten Bedenken betreffen sie alle.
Unter einem KI-Assistenten verstehe ich ein Agent-Harness, mit dem man über eine Messaging-App seiner Wahl interagiert und das Aufgaben im eigenen Namen ausführt. Präferenzen und Gewohnheiten werden gespeichert, sodass der Assistent mit der Zeit vermeintlich immer besser auf einen zugeschnitten ist.
Aus meiner Sicht lassen sich die Nutzer:innen in zwei Gruppen einteilen.
KI-Assistenten einrichten, ohne die Risiken zu verstehen
Zur ersten Gruppe gehören diejenigen, die das Tool ohne größere Sicherheitsüberlegungen installieren und einfach ausprobieren möchten, was es kann. An sie richtet sich mein klarer Appell: Stoppt. Einem Agenten weitreichende Befugnisse zu geben, kann schnell nach hinten losgehen, weil genau diese Fähigkeiten gegen euch verwendet werden können. Ein Agent, der in eurem Namen eine überzeugende E-Mail formulieren und versenden kann, kann ebenso gut eine Nachricht an Vorgesetzte oder Kund:innen schicken, die euch schadet. Ein Agent, der bei Amazon Windeln bestellt, sobald der Preis stimmt, kann aufMoltbook lernen, dass sein Mensch noch glücklicher wäre, wenn er gleich zehn Kartons bestellt. Ein Agent, der Flüge buchen darf, lässt sich unter Umständen dazu bringen, eine Luxusreise für den „Cousin“ Brendon zu kaufen.
Ja, alle coolen Kids installieren KI-Assistenten.
Ja, Lemminge springen auch gemeinsam von der Klippe.
Seid keine Lemminge.
Wenn ich neue Technologien bewerte, verlasse ich mich auf gesunden Menschenverstand. Ich versuche, Auswirkungen und Risiken zu verstehen. Gelingt mir das nicht, warte ich, bis ich es tue, statt kopfüber einzusteigen.
So war es auch beim MCP-Hype: Weil scheinbar alle darüber sprachen, habe ich mir angesehen, worum es geht und ob es für mich sinnvoll sein könnte. Ich habe mit einem kleinen Experiment begonnen und einen Playwright-MCP lokal ausprobiert. Mir fehlten jedoch Zeit und mentale Kapazität, um die sicherheitstechnischen Implikationen des Protokolls wirklich zu durchdringen. Also habe ich mich entschieden, nicht weiterzumachen. Die potenziellen Kosten einer Fehlkonfiguration waren mir zu hoch.
Als Softwareentwicklerin kann ich nicht jede neue Sicherheitslücke und jedes Exploit im Detail verfolgen. Aber ich weiß, wie kritisch Sicherheit ist. Und ich weiß genug, um meinem unguten Gefühl zu vertrauen, wenn selbst ich erkenne, wie gravierend das hier schiefgehen kann.
KI-Assistenten mit Schutzmaßnahmen einrichten
Die zweite Gruppe besteht aus Entwickler:innen, die bewusst vorgehen, ihre Systeme sauber konfigurieren und grundlegende Sicherheitsmaßnahmen berücksichtigen. Ihre Geräte sind nicht aus dem Internet erreichbar. Sie betreiben den KI-Assistenten auf separater Hardware, um eine physische Sandbox als Schadensbegrenzung einzusetzen, falls etwas schiefgeht. Manche nutzen alternative, vibe-codete Lösungen, die auf Betriebssystem-Sandboxing setzen. (Hinweis: Ich hatte keine Zeit, mir diese Lösungen im Detail anzuschauen. Prüft solche Ansätze eigenständig).
So sehr ich den Experimentierdrang nachvollziehen kann, bleibe ich angesichts des aktuellen Stands der Technik skeptisch und würde weiterhin zu außergewöhnlicher Vorsicht raten.
Der Grund ist die Lethal Trifecta, die nach wie vor sehr präsent ist: Wenn ein Agent Zugriff auf private Daten, Fähigkeit zur externen Kommunikation oder Kontakt mit nicht vertrauenswürdigen Inhalten hat, kann er dazu gebracht werden, Daten preiszugeben oder unerwünschte Aktionen in eurem Namen auszuführen.
Eine Sandbox-Umgebung schränkt zwar den Zugriff auf private Daten ein und minimiert damit einige Risiken, aber wie ich in meinem Artikel über meine Sandbox-Lösung erwähnt habe, ist die Begrenzung der Datenmenge, auf die ein Agent Zugriff hat, nur der erste Schritt. Solange der Agent uneingeschränkten Internetzugang besitzt, bleiben externe Kommunikation und der Umgang mit nicht vertrauenswürdigen Inhalten Risikofaktoren. Deshalb arbeite ich an einem weiteren Schritt, der auch den Internetzugang einschränkt. Der zugehörige Beitrag ist noch nicht veröffentlicht, aber meine aktuelle Lösung findet sich in den Slides eines kürzlich gehaltenen Vortrags.
Eine Sandbox allein reicht nicht aus. Denn die Daten, die ein Agent benötigt, um sinnvoll zu arbeiten, sind oft selbst sensibel. Beim agentischen Programmieren etwa muss der Agent Zugriff auf den Quellcode erhalten, der in vielen Fällen nicht öffentlich geteilt werden darf.
Besonders problematisch erscheint mir, dass sich die Risiken der „Lethal Trifecta“ mit jeder neuen Fähigkeit vergrößern. Jede zusätzliche Funktion erweitert potenziell die Menge sensibler Daten, die im Falle eines Angriffs offengelegt werden können. Neue Integrationen bedeuten neue Kommunikationskanäle, neue externe Systeme und zusätzliche Angriffsflächen.
Eigentlich müssten wir in die entgegengesetzte Richtung gehen und jeden dieser Risikofaktoren schrittweise reduzieren.
Wie eine risikoärmere Architektur aussehen könnte
Ein sicherheitsbewusster Ansatz würde jede Fähigkeit isoliert betrachten und technisch begrenzen. Eine Funktion zur Kategorisierung von Familienfotos hätte ausschließlich Zugriff auf diese Fotos und auf den dafür vorgesehenen Kommunikationskanal. Eine Funktion zur Verarbeitung von Belegen bekäme nur Zugriff auf die entsprechenden Dokumente. Eine Funktion zur Preisüberwachung bei Amazon dürfte lediglich eine konkrete URL abfragen und über einen dedizierten Kanal informieren.
Indem wir den Zugang zum Internet stark einschränken und die Daten, auf die ein Agent zu einem bestimmten Zeitpunkt Zugriff hat, drastisch reduzieren, könnten wir den Schaden begrenzen, den ein kompromittierter KI-Assistent anrichten könnte. Idealerweise würden wir jede einzelne Fähigkeit anhand der „Lethal Trifecta“ bewerten. Eine mögliche Heuristik ist die Agents Rule of Two: Eine Funktion sollte höchstens zwei der drei Risikodimensionen kombinieren. Auch das reduziert das Risiko lediglich, beseitigt es aber nicht vollständig. Eine Fähigkeit, die alle drei Elemente vereint, etwa das Lesen und Versenden von E-Mails, würde ich nicht einsetzen.
Sicherheit vor Bequemlichkeit
Ein solcher Ansatz erzeugt Reibung. Jede neue Fähigkeit erfordert bewusste Abwägung und zusätzliche Absicherung. Komfort tritt zugunsten von Sicherheit zurück.
Meiner Ansicht nach ist das ein sinnvoller Tausch.
Genau das bieten OpenClaw und vergleichbare Tools derzeit jedoch NICHT. Wer dennoch einen KI-Assistenten einsetzen möchte, sollte äußerst vorsichtig sein und jede neue Fähigkeit separat bewerten. Und falls euch die dafür nötige Expertise einschüchtert: Damit seid ihr nicht allein. Ich selbst werde diesen Hype vorerst aussitzen. Wer möchte, kann es genauso halten.