Ein KI-Agent, der Dateien öffnet, Mails vorbereitet, Termine aktualisiert und Befehle im Terminal ausführt, braucht mehr als ein gutes Chatfenster. Andrew Ng und Rohit Prasad haben OpenWorker am 23. Juli 2026 als offenen Desktop-Agenten vorgestellt. Die Software läuft local-first. Trotzdem endet der Datenweg nicht automatisch am eigenen Rechner.
Das Wichtigste in 30 Sekunden
- OpenWorker startet als MIT-lizenzierte Open Beta für den Desktop.
- Die Dokumentation nennt mehr als 25 Integrationen sowie Zugriff auf lokale Dateien, Terminal und MCP-Werkzeuge.
- Agentenlogik, Gespräche, Connector-Tokens und Modellschlüssel sollen lokal liegen.
- Bei Cloud-Modellen, verbundenen Diensten und OAuth können Inhalte trotzdem externe Systeme erreichen.
- Ein Windows-10/11-x64-Build ist in der aktuellen README vorhanden, aber noch nicht code-signiert.
OpenWorker ist mehr als ein weiteres Chatfenster
Der Launch zielt auf Menschen, die mit KI nicht nur Entwürfe erzeugen, sondern Arbeitsschritte abschließen wollen. OpenWorker soll dafür lokale Dateien und das Terminal nutzen, Dienste wie Kalender, Mail oder Slack anbinden und über MCP weitere Werkzeuge erreichen. Andrew Ng und Rohit Prasad stellen das Projekt als offenen Desktop-Agenten vor; das Repository steht unter MIT-Lizenz und bezeichnet die Software als Open Beta.
Der Unterschied ist praktisch. Ein Chat liefert Antworten. Ein Desktop-Agent kann mit Daten und Rechten arbeiten, die bereits auf dem Rechner oder in verknüpften Konten liegen. Damit rücken Datenklassen, Berechtigungen und nachvollziehbare Freigaben in den Vordergrund.
Was „local-first“ bei OpenWorker bedeutet
Die aktuelle Dokumentation beschreibt einen lokalen Agentenprozess. Gespräche, Connector-Tokens und Modellschlüssel sollen lokal gespeichert werden. Das unterscheidet OpenWorker von Anwendungen, die Steuerung und Verlauf vollständig zentral in einer Cloud führen.
Die Aussage hat aber eine klare Grenze. Local-first heißt hier: Zentrale Teile der Agentenlogik und ausgewählte Daten liegen auf dem Gerät. Es heißt weder, dass jede Aufgabe ohne Netzwerk läuft, noch dass Inhalte den Rechner nie verlassen.
Der Datenweg hängt an Modellwahl und Verbindung
OpenWorker lässt laut Launch-Post und README unterschiedliche Modellanbieter zu; auch Ollama wird als lokale Option genannt. Wer ein Cloud-Modell auswählt, übermittelt Inhalte an diesen Anbieter. Je nach Aufgabe können darunter Textauszüge, Dateiinhalte oder Anweisungen fallen. Welche Daten konkret fließen, hängt vom Auftrag und von der gewählten Integration ab.
Connectoren verbinden den Agenten zusätzlich mit Diensten wie E-Mail, Kalender oder Projektwerkzeugen. Für OAuth-Handshakes beschreibt die Dokumentation einen kleinen Cloud-Dienst. Lokal gespeicherte Tokens bedeuten nicht, dass der angebundene Dienst und der OAuth-Weg keine Daten verarbeiten.
Für die Einordnung hilft eine klare Trennung: Wo der Agent läuft, ist eine Frage. Welchen Weg einzelne Inhalte nehmen, ist eine zweite. Erst beides zusammen zeigt, was ein konkreter Auftrag mit einem Konto, einer Datei oder einem Modellanbieter macht.
| Bereich | Dokumentierter Stand | Vor dem Test zu prüfen |
|---|---|---|
| Agentenlogik und Gespräche | Laut README lokal ausgeführt beziehungsweise gespeichert | Lokaler Speicherort, Geräteschutz und Benutzerrechte |
| Modellantworten | Abhängig vom gewählten Cloud-Modell oder von Ollama | Welcher Anbieter Inhalte erhält und welche Daten in Prompts stehen |
| Connectoren und OAuth | Verbindungen zu externen Diensten; OAuth-Handshakes mit Cloud-Vermittlung dokumentiert | Berechtigungsumfang, Testkonto und Rückbau der Verbindung |
Freigaben sind ein Schutzmechanismus, kein Freibrief
README, Permission-Engine und Tests beschreiben für Werkzeugaufrufe die Zustände allow, deny und ask-user. Im Interactive-Modus sollen Schreibvorgänge und Kommandos eine Freigabe benötigen, sofern sie nicht gezielt erlaubt wurden. Für einen Agenten mit Datei-, Mail- und Terminalzugriff ist das ein sinnvoller Ausgangspunkt.
In derselben Codebasis liegen jedoch die Grenzen: Neben dem Interactive-Modus gibt es Auto-, Custom- und Session-Allowlist-Modi. Eine dokumentierte Rückfrage ist daher keine Zusage, dass jede riskante Aktion in jeder Konfiguration gestoppt wird. Auch die Lektüre von Code und Tests ersetzt kein Audit des ausgelieferten Programms.
Windows: Download vorhanden, Freigabe noch nicht
Der aktuelle Stand ist ungewöhnlich, aber nachvollziehbar. Beim Launch am 23. Juli startete OpenWorker auf dem Mac, Windows war angekündigt. In der aktuellen README findet sich inzwischen ein Windows-10/11-x64-Build. Die Dokumentation warnt zugleich ausdrücklich: Der Build ist noch nicht code-signiert, SmartScreen wird warnen, die Signierung sei in Arbeit.
Die öffentliche Produktseite wirkt beim Windows-Start weiterhin vorsichtig. Daraus folgt eine nüchterne Einordnung: Es gibt einen Beta-Download, aber keinen belastbaren Hinweis auf einen uneingeschränkt freigegebenen oder produktionsreifen Windows-Release. Wer testet, sollte die Warnung nicht wegklicken, sondern den Vorgang in eine kontrollierte Testumgebung verlegen.
Wie ein begrenzter Beta-Test aussehen kann
Für deutsche und europäische Teams ist das keine abstrakte Compliance-Frage. Bei einem Agenten, der mit Mails, Kalendern, Dateien und Terminals arbeitet, reicht die Aussage „läuft lokal“ nicht als Entscheidungsvorlage. Modellanbieter, Berechtigungen, Speicherorte und der jeweilige Datenfluss müssen getrennt bewertet werden. Das ist eine technische und organisatorische Prüfung, keine Rechtsberatung.
Open Source hilft beim Prüfen – aber nur bis zu einem Punkt
Dass Repository, Permission-Logik und Teile der OAuth-Implementierung offen einsehbar sind, erleichtert eine sachliche Prüfung. Teams können nachvollziehen, welche Freigabemodi dokumentiert sind und wo sich Integrationen in die Architektur einfügen. Das ist hilfreicher als ein bloßes Versprechen auf einer Produktseite.
Offener Code ist dennoch kein Qualitätsstempel. OWASP verweist bei KI-Agenten allgemein auf Risiken durch weitreichende Werkzeugrechte, nicht vertrauenswürdige Inhalte und Datenabfluss. Das belegt keine konkrete Schwachstelle von OpenWorker. Es zeigt, warum ein Pilot mit engen Rechten, klaren Testdaten und überprüfbaren Freigaben vernünftiger ist als direkter Zugriff auf produktive Konten.
FAQ: Was sollten Teams jetzt daraus mitnehmen?
Ist OpenWorker vollständig offline nutzbar?
Das lässt sich aus den vorliegenden Quellen nicht ableiten. Die Agentenlogik wird lokal beschrieben, doch bei Cloud-Modellen, Integrationen und OAuth können Daten externe Dienste erreichen. Mit einer lokalen Modelloption wie Ollama verändert sich der Datenweg, die Rechte der Connectoren bleiben aber eine eigene Frage.
Ist der Windows-Build schon für den breiten Einsatz gedacht?
Nein. Die aktuelle README bietet einen Windows-10/11-x64-Build an, nennt aber fehlende Code-Signierung und SmartScreen-Warnungen. Das spricht für einen vorsichtigen Beta-Test, nicht für eine allgemeine Freigabe.
Quellen und weiterführende Informationen
- Andrew Ng: „Announcing OpenWorker!“
- OpenWorker: offizielle Produktseite
- OpenWorker auf GitHub: Repository und README
- OpenWorker: Permission Engine
- OpenWorker: MCP-OAuth-Implementierung
- OWASP: Agentic AI – Threats and Mitigations
Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft. Stand: 2026-07-26
