PicoClaw: KI-Agenten auf 10-Dollar-Hardware. Warum das Sicherheitsproblem damit erst richtig beginnt

Ein KI-Agent, der auf einem Gerät für zehn Dollar läuft, sich in einer Sekunde startet und dabei weniger als zehn Megabyte RAM benötigt. Kein Proof-of-Concept, sondern ein Projekt mit 12.000 GitHub Stars in einer Woche. PicoClaw verändert die Bedrohungslandschaft für Unternehmen strukturell.

Was PicoClaw ist und was es von seinen Vorgängern unterscheidet

PicoClaw wurde am 9. Februar 2026 veröffentlicht. Hinter dem Projekt steht Sipeed, ein chinesischer Hardware-Hersteller, der vor allem für preiswerte RISC-V-Einplatinencomputer bekannt ist. Der Agent ist in Go geschrieben, läuft als einzelnes Binary und benötigt keine externe Laufzeitumgebung.

Wichtig für die Einordnung: PicoClaw befindet sich in früher Entwicklung. Das Projekt warnt im Repository ausdrücklich vor möglicherweise ungelösten Sicherheitsproblemen und rät davon ab, PicoClaw vor Erreichen der Version 1.0 in Produktivumgebungen einzusetzen.

Die Plattform-Unterstützung ist ebenfalls aufschlussreich. PicoClaw integriert sich in Telegram, Discord, QQ, DingTalk, LINE, WeCom und Slack. Als KI-Backend dienen OpenRouter, Anthropic, OpenAI, DeepSeek und Groq. Veröffentlicht unter MIT-Lizenz, frei modifizierbar, frei weiterzugeben, frei einzusetzen. Eine technische Zugangsschranke gibt es freilich nicht.

Ein Detail zur Entstehung verdient Aufmerksamkeit. 95 Prozent des PicoClaw-Codes sollen laut Projektangaben KI-generiert sein. Das Repository bezeichnet sich selbst als „self-bootstrapped", also als KI-Agent, der wesentlich an seiner eigenen Entstehung beteiligt war. Für die Sicherheitsbewertung ist das relevant. Die Code-Qualität und Auditierbarkeit eines überwiegend KI-generierten Projekts muss mit anderen Maßstäben gemessen werden als die eines klassisch entwickelten Open-Source-Tools.

Warum die Miniaturisierung das Sicherheitsproblem verschärft

Der Sicherheitskontext bei Schatten-KI war bisher vergleichsweise übersichtlich. Mitarbeiter nutzen Cloud-Dienste ohne IT-Genehmigung, und mit einem CASB lässt sich der Traffic erkennen. OpenClaw auf dem Firmenrechner hinterlässt Spuren, nämlich einen laufenden Prozess, einen belegten Port, eine erkennbare Netzwerkverbindung zu bekannten GenAI-APIs.

PicoClaw bricht diese Erkennungslogik auf mehreren Ebenen.

Kein Server, kein Fingerabdruck

Ein KI-Agent, der auf einem ESP32-Mikrocontroller, einem billigen IP-Kamerachip oder einem Raspberry Pi Zero läuft, erzeugt keinen erkennbaren Prozess auf verwalteten Firmengeräten. CASB und DLP überwachen Endpunkte, die im MDM-Inventar stehen. Ein Gerät für zehn Euro taucht dort nicht auf. Es fehlt die Grundlage für eine Baseline. Ein SIEM kann nur alarmieren, was es als Datenquelle kennt.

Messenger als Datenkanal

PicoClaw kommuniziert nativ über Telegram, Discord, Slack und DingTalk, also Dienste, die in vielen Unternehmen ohnehin für interne Kommunikation freigegeben sind. Wer über Slack mit einem PicoClaw-Agenten interagiert, der auf einem Gerät außerhalb des Unternehmensnetzwerks läuft, erzeugt Traffic, der sich nur schwer von legitimem Slack-Einsatz unterscheiden lässt. DLP-Systeme prüfen Inhalte, doch Metadaten und der Umweg über externe Agenten entziehen sich häufig der Erkennung durch gängige Kontrollmechanismen.

Ubiquitäre Hardware

Mikrocontroller mit ARM- oder RISC-V-Prozessoren stecken in Druckern, IP-Kameras, Netzwerk-Switches, Klimaanlagen-Steuerungen und industriellen Sensoren. Ein Angreifer, der ein solches Gerät kompromittiert und PicoClaw darauf installiert, hat einen persistenten Agenten im Netzwerk, der sich klassischen MDM-, CASB- und DLP-zentrierten Kontrollen weitgehend entzieht.

Regulatorische Einordnung

Personenbezogene Daten, die ein Mitarbeiter einem PicoClaw-Agenten übermittelt, verlassen möglicherweise das Unternehmen über unkontrollierte Kanäle. Art. 32 DSGVO verlangt geeignete technische und organisatorische Maßnahmen zur Sicherheit der Verarbeitung. Art. 5 Abs. 1 lit. f DSGVO statuiert das Integritäts- und Vertraulichkeitsgebot. Wer nicht weiß, welche Agenten im Netzwerk laufen, kann diese Anforderungen nicht belastbar nachweisen.

Gleichzeitig entfaltet der EU AI Act (Verordnung (EU) 2024/1689) zunehmend Wirkung. Art. 53 richtet sich an Anbieter von General-Purpose-AI-Modellen (GPAI) und verpflichtet diese zu Transparenz- und Dokumentationspflichten. Die einschlägigen GPAI-Pflichten gelten seit dem 2. August 2025. Für Unternehmen, die KI-Systeme einsetzen oder bereitstellen (Deployer), ergeben sich davon getrennte Governance- und Compliance-Pflichten. KI-Systeme im Unternehmenseinsatz müssen inventarisiert, risikoklassifiziert und dokumentiert werden. Diese Anforderung folgt nicht unmittelbar aus Art. 53. Sie ergibt sich als Governance-Schlussfolgerung aus dem Gesamtrahmen der Verordnung.

Was Unternehmen jetzt tun sollten

Die Maßnahmen folgen einer klaren Logik. Sehen, steuern, verankern.

Netzwerksegmentierung und IoT-Inventar schärfen

Der erste Schritt ist eine ehrliche Bestandsaufnahme. Welche Geräte hängen im Netz, einschließlich OT-Geräte, IP-Kameras, Drucker und Netzwerkinfrastruktur? Ein vollständiges Asset-Inventar nach ISO/IEC 27001:2022 Annex A 5.9 ist die Voraussetzung für jede weitere Maßnahme. Netzwerksegmentierung begrenzt den Blast Radius. IoT-Geräte gehören in ein isoliertes VLAN ohne ausgehenden Internet-Traffic zu Messenger-Diensten oder KI-APIs.

Detection-Strategie auf Messenger-Traffic ausweiten

CASB-Regeln und DLP allein genügen nicht. Unternehmen, die PicoClaw-ähnliche Szenarien erkennen wollen, müssen den ausgehenden Traffic zu Messenger-APIs und GenAI-Endpunkten auch dann überwachen, wenn diese Dienste grundsätzlich freigegeben sind. DNS-basierte Filterung ergänzt die Sicht.

KI-Governance-Rahmen um dezentrale Agenten erweitern

Wer ein ISMS nach ISO 27001 betreibt, hat die methodischen Grundlagen für eine Risikoanalyse. KI-Governance nach ISO 42001 adressiert darüber hinaus die spezifische Anforderung, KI-Systeme im Unternehmen zu inventarisieren und deren Risikoprofil systematisch zu bewerten.