Andrew Ng hat eine neue Version seines quelloffenen Desktop-Agenten OpenWorker angekündigt, mit einer Reihe von Funktionen rund um Sicherheits-Workflows. Als Grund nennt er, dass nach der ersten Veröffentlichung viele Nutzer festgestellt hätten, wie gut sich das Tool gerade für Cybersicherheits-Szenarien eigne; Angreifer setzten bereits KI ein, also solle die Verteidigung denselben Hebel bekommen.
OpenWorker geht nicht den üblichen Chatfenster-Weg. Der Nutzer übergibt eine Aufgabe, der Agent zerlegt sie selbständig in Schritte, arbeitet dabei über Dateien, Terminal und verbundene Anwendungen hinweg und liefert am Ende ein direkt verwendbares Ergebnis ab. Das Projekt wurde im Juli unter MIT-Lizenz quelloffen gemacht, befindet sich derzeit in der offenen Testphase und hat auf GitHub bereits 16.400 Sterne gesammelt. Die Desktop-Version unterstützt macOS 12 und neuer (Apple Silicon, signiert und notariell beglaubigt) sowie Windows 10/11 in der x64-Version, wobei die Codesignierung für Windows noch aussteht.
Code scannen, Abhängigkeiten scannen
Die in der neuen Version an erste Stelle gerückte dedizierte Rolle heißt "Security Review". Laut Dokumentation im Repository erledigt sie zwei Dinge: Mit deterministischen Scannern kombiniert mit Modell-Inferenz wird die gesamte Codebasis samt Abhängigkeiten durchsucht, um reale Risiken aufzuspüren. Die Abhängigkeits-Seite zielt auf Supply-Chain-Angriffe ab – bösartiger Code, der in Drittanbieter-Pakete eingeschleust wird. Solche Vorfälle häuften sich im vergangenen Jahr im Open-Source-Ökosystem, während eine manuelle Prüfung jedes einzelnen Abhängigkeitsbaums praktisch unmöglich ist.
Bei der Fix-Phase gilt eine noch strengere Regel. Die Dokumentation hält fest: Ein vom Agenten vorgeschlagener Fix muss erneut gescannt und per Diff-Review geprüft werden, bevor er freigegeben wird, und der Agent, der den Fix liefert, ist nie zugleich der alleinige Prüfer.
Diese Einschränkung richtet sich gegen das Prinzip, dass KI ihre eigenen Hausaufgaben benotet. Dasselbe Modell schreibt den Patch und beurteilt ihn zugleich – das Ergebnis wirkt vollständig, ist aber im Kern Selbstbestätigung: Für genau das, was es übersehen hat, ist es ebenso blind. Deterministische Werkzeuge wie Scanner im Prozess zu belassen, verschafft dem Modellurteil eine kompromisslose Gegenkontrolle.
Vier Risikostufen, Autonomie wird schrittweise erarbeitet
Jeder Werkzeugaufruf wird einer von vier Risikoklassen zugeordnet: Lesen (read), lokal schreiben (write_local), Befehle ausführen (exec), externer Aufruf (external). Darüber liegen fünf Berechtigungsmodi: discuss und plan sind rein lesend; interactive ist der Standardmodus, bei dem vor schreibenden Aktionen nachgefragt wird; auto gibt innerhalb festgelegter Pfade alles frei; custom erlaubt es, einzelne vertrauenswürdige Werkzeuge auf automatische Freigabe zu setzen.
Die Governance-Regeln sind fest in drei Ebenen unterteilt:
- Harte Grenzen: gefährliche und irreversible Aktionen bleiben immer allein Menschen vorbehalten, egal welcher Modus aktiv ist;
- Schrittweise Autonomie: alle Aktionen laufen standardmäßig über eine Freigabe, eine einmalige Freigabe kann zu einer dauerhaften Regel aufgewertet werden, erst danach landet sie in der Konfigurations-Whitelist;
- Audit-Spur: jeder Werkzeugaufruf protokolliert die Herkunft der Freigabe – automatisch freigegeben, vom Nutzer freigegeben oder abgelehnt.
Hinzu kommt die Regel "keine Selbstfreigabe im unbeaufsichtigten Betrieb": Läuft der Agent nachts ohne Aufsicht und stößt auf eine folgenreiche Aktion, landet die unbeantwortete Anfrage im Postfach zur späteren Prüfung – die Rechte werden nicht automatisch gelockert, nur weil niemand da ist.
Die Werkzeuge der Großkonzerne auf den Laptop bringen
Nachrichten über KI-gestützte Schwachstellensuche im vergangenen Jahr stammten fast ausschließlich von Closed-Source-Großkonzernen: Mal wurde eine über zwanzig Jahre alte Lücke gefunden, mal wurden binnen eines Monats Zehntausende kritische Schwachstellen aufgespürt – jeweils mit den stärksten hauseigenen Modellen, über Unternehmensbeschaffungskanäle, mit entsprechenden Preisen und Zugangshürden. OpenWorker schlägt einen anderen Weg ein – lokal ausgeführt, quelloffen, MIT-lizenziert, der Code ist prüfbar.
Für Sicherheitsteams wiegt die Tatsache, dass sich diese Hülle selbst prüfen lässt, nicht weniger schwer als die Scan-Fähigkeit. Ein Agent, der die gesamte Codebasis lesen, Befehle ausführen und externe Anfragen stellen kann, ist von Natur aus der ideale Kanal für Datenabfluss; ist er zudem eine Black Box, gilt: Je mehr Schwachstellen er findet, desto schwerer lässt sich das Risiko seines eigenen Einsatzes einschätzen. Open Source ist hier eher eine Zugangsvoraussetzung als eine Haltungsfrage.
Öffentlich fehlen derzeit noch zwei Angaben: Das Repository nennt keine konkrete Versionsnummer für die neue Ausgabe, und für die Trefferquote der Scan-Fähigkeit auf öffentlichen Benchmarks gibt es bisher keine unabhängigen Zahlen Dritter. Bevor man das Tool in eine CI-Pipeline einbindet, empfiehlt sich, es zunächst mehrfach in einer isolierten Umgebung zu testen.
Quellen: offizielle Repository-Dokumentation von OpenWorker, CocoLoop, MarkTechPost, Help Net Security; Angaben zu Berechtigungsstufen, dreistufiger Governance und Zuständigkeiten der Sicherheitsprüfung wurden Punkt für Punkt mit der Repository-Dokumentation abgeglichen.