Agenten, die niemand freigegeben hat

Wer nicht festlegt, welche Agenten mit welchen Rechten auf welchem Code laufen dürfen, hat diese Entscheidung trotzdem getroffen, nur unbewusst. Agentenplattformen wie OpenClaw laufen auf der Maschine der Entwicklerin, brauchen keine Beschaffung und stehen in keinem Verzeichnis. Agenten-Governance besteht deshalb aus drei Teilen: einer Positivliste, abgestuften Rechteklassen und einer Erkennung, die ohne Verdächtigungen auskommt.

Der typische Auslöser ist ein Nebensatz im Daily. Jemand erwähnt, dass der Agent das Refactoring über Nacht gemacht hat, per Telegram angestossen, vom privaten MacBook aus. Und dann ist die Frage nicht mehr, ob so etwas im Einsatz ist, sondern seit wann.

Ein Repository mit 386’890 Sternen, das nie durch die Beschaffung ging

OpenClaw steht am 20.08.2026 bei 386’890 GitHub-Sternen und ist damit das sechstmeistgesternte Repository überhaupt, deutlich vor React mit 247’443 (GitHub-API, Abruf 20.08.2026). Das ist keine Herstellerangabe, sondern der Zählerstand der Plattform selbst.

Was dahintersteckt: eine offene Agentenplattform von Peter Steinberger, die auf der eigenen Maschine läuft und über gewöhnliche Chat-Apps bedient wird, WhatsApp, Telegram, Discord, Slack, Teams. Das Projekt formuliert es selbst als «Your assistant. Your machine. Your rules.» Kein SaaS, also kein Vertrag, keine Rechnung, kein Beschaffungsvorgang, den ein CTO je zu sehen bekommt.

Für die Inventarisierung ist auch die Namensgeschichte relevant. Aus dem Wochenendprojekt «WhatsApp Relay» vom November 2025 wurde «Clawd», danach «Moltbot», seit dem 29.01.2026 heisst es OpenClaw. Wer eine Liste erlaubter Werkzeuge pflegt und nach dem alten Namen sucht, findet nichts.

Welche Rechte so ein Agent tatsächlich hat

OpenClaw kann Dateien lesen, Befehle ausführen, Plugins installieren und Netzwerkverbindungen aufbauen, und das Projekt sagt dazu selbst den entscheidenden Satz: «It is not a sandbox.» Die Sicherheitsdokumentation beschreibt stattdessen Grenzen, etwa Pfadschutz und einen Proxy, räumt aber ein, dass ein Plugin mit Shell-Rechten weiterhin alles tun kann, was Shell-Rechte erlauben.

Diese Offenheit ist ehrlicher als das Marketing der meisten kommerziellen Werkzeuge. Sie beschreibt aber genau die Klasse von Software, die auf einem Rechner mit Kundencode nicht unbeaufsichtigt laufen sollte.

Dass die Rechteverwaltung dabei brechen kann, ist belegt. CVE-2026-33579 beschreibt eine Privilege Escalation mit CVSS v4.0 9,4 und CVSS v3.1 9,9, eingestuft als CRITICAL durch die CNA VulnCheck, CWE-863, veröffentlicht am 31.03.2026. Betroffen sind alle Versionen vor 2026.3.28: Ein Aufrufer mit Pairing-, aber ohne Admin-Rechten konnte Geräteanfragen mit erweiterten Rechten inklusive Admin genehmigen, weil die Scope-Prüfung im Genehmigungspfad fehlte.

Wenn Sie gerade nicht sagen können, welche Agenten auf Ihren Entwicklungsrechnern laufen und mit welchen Rechten: Genau diese Bestandsaufnahme machen wir in einem halben Tag mit Ihrem Team, ohne Werkzeugempfehlung am Ende. Schreiben Sie uns über Kontakt.

Was der lokale Betrieb unter revDSG auslöst

Ein Agent, der Repository-Inhalte an ein Modell schickt, ist datenschutzrechtlich eine Bekanntgabe, und zwar meist ins Ausland. Enthält der Code Personendaten, etwa in Fixtures, Logs oder Migrationsskripten, greifen Art. 16 und Art. 9 des revDSG.

Besonders unangenehm ist Art. 9 Abs. 3: Ein Auftragsbearbeiter darf die Bearbeitung «nur mit vorgängiger Genehmigung des Verantwortlichen einem Dritten übertragen». Ein selbst installierter Agent, der einen zusätzlichen Modellanbieter anspricht, erzeugt exakt diesen ungenehmigten Dritten, und niemand im Unternehmen weiss davon.

Die Sanktion trifft Menschen, nicht Abteilungen. Art. 61 revDSG stellt Bussen bis CHF 250’000 in Aussicht, gegen private Personen, auf Antrag, bei Vorsatz. Erfasst sind unter anderem die Bekanntgabe ins Ausland ohne die Voraussetzungen nach Art. 17 und die Übergabe an einen Auftragsbearbeiter ohne die Voraussetzungen nach Art. 9 Abs. 1 und 2.

Wie sich das in Architektur übersetzt, haben wir in revDSG-konforme KI-Architektur Norm für Norm ausgeführt.

Drei Rechteklassen statt einer einzigen Freigabe

Eine binäre Freigabe scheitert, weil «erlaubt» für einen Autocomplete etwas anderes heisst als für einen Agenten, der nachts committet. Wir arbeiten deshalb mit drei Klassen, und die Klasse ergibt sich aus dem Zugriff, nicht aus dem Produktnamen.

Klasse	Sichtbarer Code	Ausführung	Netz	Freigabe durch	Typischer Fall
A Assistenz	offener Arbeitsbereich, keine Secrets	keine	Modellanbieter der Positivliste	Team-Lead	Autocomplete, Chat im Editor
B Beauftragt	ein Repository, Secrets über Vault	ja, in Container oder VM, Ergebnis als Pull Request	Positivliste plus freigegebene MCP-Server	Tech-Lead plus Datenschutzverantwortliche	Coding-Agent im Auftrag
C Autonom	mehrere Repositories, Produktionsnähe	ja, ausserhalb der Arbeitszeit, ohne Beobachtung	jede ausgehende Verbindung möglich	Geschäftsleitung, befristet, mit Protokoll	Allzweck-Agent über Chat-App

Die Linie, die zählt, liegt zwischen B und C. Alles, was in Klasse C fällt, gehört auf eine dedizierte Maschine mit eigenem Betriebssystem-Konto, nicht auf das Notebook, auf dem morgen ein Kundenprojekt geöffnet wird. Die OpenClaw-Dokumentation empfiehlt für geteilte Hosts von sich aus, Vertrauensgrenzen zu trennen, mit eigenen Betriebssystem-Nutzern oder eigenen Hosts.

Für Klasse B lässt sich der Rahmen konfigurativ festhalten. OpenClaw kennt dafür eine restriktive Grundhaltung, die als Vorgabe taugt, Gateway nur auf Loopback, Ausführung standardmässig verweigert:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "<langes-zufaelliges-token>" },
  },
  tools: {
    deny: ["group:automation", "group:runtime", "gateway", "cron"],
    exec: { security: "deny", ask: "always" },
  },
  agents: {
    defaults: {
      sandbox: { mode: "all", scope: "agent" },
      workspaceAccess: "ro",
    },
  },
}

Die Datei selbst gehört abgeriegelt, ~/.openclaw auf 700 und ~/.openclaw/openclaw.json auf 600. Das Projekt liefert dafür eine Prüfung mit, die auch Konfigurationsdrift findet:

openclaw security audit --deep
openclaw security audit --fix

Wie Sie den Einsatz erkennen, ohne jemanden zu jagen

Erkennung heisst hier Inventar, nicht Überwachung: Sie fragen die Maschine, nicht die Kollegin. Drei Signale reichen für eine erste Runde, und alle drei lassen sich in einem Onboarding-Skript oder im MDM-Check unterbringen.

# 1. Global installierte Agenten-Pakete
npm ls -g --depth=0 2>/dev/null | grep -Ei 'openclaw|opencode|codex|claude-code'

# 2. Konfigurationsverzeichnisse dauerhaft laufender Agenten
ls -ld ~/.openclaw ~/.claude ~/.codex 2>/dev/null

# 3. Der OpenClaw-Gateway lauscht per Vorgabe auf 127.0.0.1:18789
lsof -nP -iTCP:18789 -sTCP:LISTEN 2>/dev/null

Der zweite Teil betrifft nicht die Rechner, sondern die Repositories. Ein Agent sieht alles, was das Arbeitsverzeichnis hergibt, und das ist regelmässig mehr als gedacht:

git ls-files | wc -l
git grep -nIE '(api[_-]?key|secret|BEGIN [A-Z ]*PRIVATE KEY)' -- ':!*_test*' | head

Wenn diese zweite Abfrage etwas findet, ist das Agenten-Thema nachrangig. Dann haben Sie ein Secret-Management-Problem, das jeden Klon des Repositories betrifft.

Werkzeugbindung ist das zweite, leisere Risiko

Wer Governance nur als Sicherheitsfrage denkt, übersieht die Konsolidierung im Markt. Windsurf existiert als eigene Marke nicht mehr: windsurf.com antwortet am 20.08.2026 mit HTTP 308 auf devin.ai/desktop, geprüft mit einem einfachen Redirect-Check. Cursor baut mit «Origin» seit dem 17.08.2026 eigenes Code-Hosting samt Repositories und Pull Requests, laut Changelog in offener Beta für alle zahlenden Pläne, mit einer Opt-out-Möglichkeit für Enterprise-Administratoren.

Die Nutzungsanteile verschieben sich im gleichen Tempo. Die JetBrains Developer Ecosystem Survey 2026 mit über 15’000 Befragten, erhoben von Mai bis Juli 2026, misst eine Umverteilung innerhalb weniger Monate. Zu beachten: JetBrains ist im selben Markt tätig und damit kein neutraler Erheber.

Werkzeug	Vorher	Erhebung Mai bis Juli 2026
Claude Code	18 %	39 %
GitHub Copilot	29 %	21 %
Codex	3 %	16 %
Cursor	18 %	12 %

Ein Werkzeug, das binnen zwei Quartalen ein Drittel seiner Nutzerschaft abgibt oder verdoppelt, ist keine Plattformentscheidung, sondern eine Momentaufnahme. Bindend sollte deshalb nicht das Werkzeug sein, sondern das, was den Wechsel überlebt.

Portabel sind heute drei Dinge: das Model Context Protocol in der Spezifikationsversion vom 28.07.2026, das Format AGENTS.md, das laut agents.md über 60’000 Open-Source-Projekte nutzen und das unter dem Dach der Linux Foundation gepflegt wird, sowie A2A in Version 1.0, ebenfalls an die Linux Foundation übergeben.

Wer seine Projektkonventionen dort ablegt statt in werkzeugeigenen Einstellungen, wechselt das Werkzeug ohne Migrationsprojekt. Wie ein eigener MCP-Server dabei aussieht, haben wir in MCP-Server in Go produktiv betreiben beschrieben.

Die MCP-Spezifikation ist in der Sicherheitsfrage bemerkenswert deutlich: Tool-Beschreibungen und Annotationen seien als nicht vertrauenswürdig zu behandeln, sofern sie nicht von einem vertrauenswürdigen Server stammen. Zugleich hält sie fest, dass das Protokoll diese Prinzipien nicht erzwingen kann. Die Absicherung liegt beim Host, also bei Ihnen.

Was in die Richtlinie gehört, und wovon wir abraten

Eine Agenten-Richtlinie passt auf zwei Seiten. Länger wird sie nur gelesen, wenn ein Audit ansteht.

Positivliste mit Version, nicht nur mit Produktnamen. OpenClaw fährt seit dem 30.07.2026 einen Extended-Stable-Kanal, die erste solche Ausgabe ist 2026.6.33. Freigegeben wird ein Kanal, nicht «das Tool».
Rechteklasse pro Einsatz, nach der Tabelle oben, dokumentiert mit einem Satz Begründung.
Ausgehende Ziele benannt. Welche Modellanbieter, welche MCP-Server. GitHub führte am 06.08.2026 MCP-Allowlists in den Enterprise-Einstellungen ein, das ist der richtige Hebel.
Private Abos sind kein Firmenzugang. Nicht weil das Werkzeug damit nicht liefe, sondern weil der Vertrag ein anderer ist: Free, Pro und Max laufen unter Consumer-Bedingungen, bei denen die Trainingsnutzung an einer persönlichen Kontoeinstellung hängt, die der Arbeitgeber weder sieht noch steuert. Anthropic beschreibt das ausdrücklich für die Nutzung von Claude Code aus solchen Konten. Welche Tarif- und Bezugswege es stattdessen gibt, steht in Coding-Agenten datenschutzkonform nutzen.
Ein Meldeweg ohne Konsequenz. Wer einen bisher nicht freigegebenen Agenten meldet, bekommt eine Klasse zugewiesen, keine Rüge.

Wovon wir abraten: von einem Verbot. Ein Verbot erzeugt besser verstecktes Schatten-IT und kostet Sie genau die Information, die Sie brauchen.

Ebenso raten wir davon ab, den Agenten seine eigene Arbeit abnehmen zu lassen. Review, Tests und Merge-Gate bleiben ausserhalb des Agenten, sonst prüft sich das System selbst. Warum das architektonisch zählt, steht in KI schreibt den Code. Wer schreibt die Architektur?.

Wann unsere Empfehlung nicht passt: In einem Zweipersonen-Team mit einem einzigen Repository ohne Personendaten ist die Rechteklassen-Matrix Overhead. Dort genügt eine gepflegte Liste im README und die Regel, dass kein Agent ohne Container Befehle ausführt.

Häufige Fragen

Ist OpenClaw für Firmen grundsätzlich ungeeignet?

Nein. OpenClaw ist ein technisch beeindruckendes Projekt mit einer offenen Sicherheitskommunikation, das seine Grenzen selbst benennt. Ungeeignet ist das Betriebsmodell auf einem Arbeitsgerät mit Kundencode: lokal, weitreichend berechtigt, über Consumer-Chat-Apps gesteuert. Auf einer dedizierten Maschine mit eigenem Betriebssystem-Konto, Loopback-Bindung und restriktiver Tool-Policy ist ein sanktionierter Einsatz möglich.

Woran erkenne ich, ob ein Agent Personendaten an ein Modell geschickt hat?

Am ausgehenden Verkehr und an der Agenten-Sitzung, nicht am Repository. Praktikabel ist der umgekehrte Weg: Sie prüfen, welche Verzeichnisse der Agent lesen durfte, und behandeln alles darin als bekanntgegeben. Deshalb steht in Klasse B workspaceAccess: "ro" und ein einzelnes Repository. Weniger Sichtbarkeit macht die datenschutzrechtliche Beurteilung nach Art. 16 revDSG erst führbar.

Reicht ein Container als Absicherung?

Ein Container begrenzt den Schaden, er verhindert ihn nicht. Er schützt das Dateisystem des Hosts und trennt Agenten voneinander, ändert aber nichts daran, welche Daten der Agent im Container sieht und wohin er sie sendet. Container plus enge Tool-Policy plus benannte ausgehende Ziele wirken zusammen. Einzeln wirkt keines der drei.

Was tun wir mit einem Agenten, der seit Monaten unbemerkt läuft?

Erst inventarisieren, dann einordnen, dann entscheiden. Version prüfen, insbesondere gegen CVE-2026-33579 und die Grenze 2026.3.28, Rechte und Zugriffsumfang festhalten, Secrets rotieren, die in seiner Reichweite lagen. Erst danach die Frage nach Weiterbetrieb oder Abschaltung stellen. Ein sofortiges Abschalten vernichtet die Information darüber, was der Agent überhaupt getan hat.

Der nächste Schritt

Nehmen Sie sich 30 Minuten mit einem unserer Engineers, ohne Verkaufsgespräch: Wir gehen Ihre Werkzeugliste durch, ordnen jeden Eintrag einer Rechteklasse zu und benennen die Stellen, an denen revDSG-Pflichten berührt sind. Termin buchen oder formlos über Kontakt, beides führt zur selben Person.

Wenn daraus mehr wird als eine Richtlinie, etwa ein Agent, der in Ihrer Umgebung sauber abgegrenzt laufen soll, ist das unser Tagesgeschäft unter Künstliche Intelligenz & Machine Learning.