OpenClaw sicher betreiben im Team.

OpenClaw ist als persönliche Agenten-Runtime gebaut: eine Installation, ein Besitzer, ein gemeinsames Geheimnis fürs Gateway. Genau dieses Design macht es so leistungsfähig. Und genau deshalb wird es heikel, sobald eine zweite Person mitarbeitet. Dieser Leitfaden zeigt, was die Standardeinstellungen schon gut machen, was Sie selbst härten sollten, wo das Single-User-Design harte Grenzen setzt und was eine Governance-Schicht ergänzt.

Wir bauen Pinchy, eine quelloffene Governance-Schicht für OpenClaw. Wir sind hier also nicht neutral. Der Abschnitt zum Selbermachen steht trotzdem für sich.

Zuerst die Anerkennung: Die Standardeinstellungen sind vernünftig

OpenClaw bindet sein Gateway standardmäßig an Loopback (127.0.0.1), verlangt eine Anmeldung und bindet ohne konfiguriertes Geheimnis an keine andere Schnittstelle. Das oft gemeldete Problem ungeschützter Instanzen liegt nicht an den Standardeinstellungen, sondern am Opt-out. Betreiber binden das Gateway für den Fernzugriff öffentlich, setzen gateway.controlUi.allowInsecureAuth: true oder wählen triviale Geheimnisse. Die Forscher von Bitsight bringen es auf den Punkt: Selbst ein so triviales Passwort wie das Zeichen a wird akzeptiert.

Die Zahlen zeigen, wie verbreitet diese Opt-outs sind. Bitsight zählte zwischen dem 27. Januar und dem 8. Februar 2026 über 30.000 verschiedene exponierte OpenClaw-Instanzen und scannte dazu Port 18789 im gesamten Internet. Das STRIKE-Team von SecurityScorecard fand schon am ersten Scan-Tag über 40.000 exponierte Instanzen. Im Bericht von Februar 2026 stufte es 35,4 Prozent der beobachteten Installationen als verwundbar ein, mit Remote Code Execution als einem der häufigsten Risiken. Den aktuellen Stand verfolgt das Team live auf einem öffentlichen Dashboard, declawed.io.

Unsicher, wie es um Ihre eigene Installation steht? Unser kostenloser OpenClaw-Sicherheitscheck geht die sechs Opt-outs durch, die zu ungeschützten Instanzen führen: Binding, Anmeldung, Containment, Multi-User-Identität, ausgehender Datenverkehr und Audit. Zu jeder Lücke nennt er die konkrete Abhilfe. Es ist ein Fragebogen. Sie geben also nie ein Geheimnis oder eine Konfiguration ein, und Ihre Antworten verlassen nie Ihr Gerät.

Das Kernproblem für Teams: ein Geheimnis bedeutet eine Identität

Das Gateway prüft Clients gegen ein einziges gemeinsames Geheimnis, ein Token oder ein Passwort. Wer es hat, spricht mit jedem Agenten, löst jedes aktivierte Tool aus und liest jede Sitzung. Wer gerade anfragt, weiß die Runtime nicht. Die Kollegin, die Support-Tickets prüft, und der Admin, der das System eingerichtet hat, sehen für sie identisch aus. Daraus folgen drei Dinge:

1. Keine Zuordnung. Hat ein Agent etwas Zerstörerisches getan, lässt sich nicht sagen, wer ihn darum gebeten hat.
2. Alles oder nichts. Sie können niemandem Zugang zu einem Agenten geben, aber nicht zu einem anderen, oder Lese- statt Schreibrechte.
3. Ein Leck besitzt alles. Ein durchgesickertes Geheimnis ist nicht ein kompromittiertes Konto. Es ist die ganze Installation.

Das sind keine Fehler, sondern Eigenschaften eines Single-User-Designs. Der OpenClaw-Issue-Tracker dokumentiert den Bedarf an mehr. Gewünscht werden: Multi-Token-Anmeldung für die Zusammenarbeit im Team, isolierte Sitzungen je Benutzer, Schutzplanken zwischen Agenten, Audit-Logs für Agenten-Aktionen.

Was Sie selbst härten können und sollten

1. Lassen Sie das Gateway auf Loopback. Das ist der Standard. Widerstehen Sie der Versuchung, es aus Bequemlichkeit öffentlich zu binden. Fernzugriff läuft über ein VPN, einen SSH-Tunnel oder einen Reverse Proxy, den Sie kontrollieren. Setzen Sie nie allowInsecureAuth, und behandeln Sie ein schwaches Gateway-Geheimnis wie gar keines.

2. Schließen Sie die Runtime ein. Betreiben Sie OpenClaw in einem Container oder einer VM, nicht als Root, mit Dateisystem-Mounts, die auf den Arbeitsbereich begrenzt sind. Der Agent soll in seinen Arbeitsbereich schreiben dürfen und sonst nirgends. Halten Sie Host-Zugangsdaten wie SSH-Schlüssel, Cloud-Zugangsdaten und Browser-Profile außer Reichweite.

3. Behandeln Sie das Gateway-Geheimnis wie ein Root-Passwort. Bewahren Sie es in einem Secrets-Manager oder einer Env-Datei mit strengen Rechten auf, nie in einem Repository oder einer Chat-Nachricht. Rotieren Sie es, indem Sie die Konfiguration anpassen und neu starten. Rechnen Sie damit, dass die Rotation stört, denn jeder Client braucht das neue Geheimnis.

4. Begrenzen Sie den ausgehenden Datenverkehr. Muss der Agent keine beliebigen Hosts erreichen, geben Sie dem Container eine explizite Allow-List für ausgehende Verbindungen. Das begrenzt sowohl den Schaden durch Prompt Injection als auch die Wege für Datenabfluss.

5. Trennen Sie Agenten nach Zweck, nicht nach Bequemlichkeit. Ein Recherche-Agent mit Web-Zugriff braucht nicht die Dateisystem-Tools Ihres Ops-Agenten. Mehrere eng begrenzte Agenten mit minimalen Tool-Sätzen schlagen einen Agenten, bei dem alles aktiviert ist.

6. Behalten und prüfen Sie die Logs, die Sie haben. Sitzungsprotokolle liegen als JSONL auf der Platte, und das Gateway protokolliert Verbindungen. Schicken Sie sie an einen Ort, an dem nur angehängt werden kann, wenn Sie können. Seien Sie ehrlich, was sie sind: nützlich zum Debuggen, schwach als Nachweis. Denn wer Zugriff auf die Platte hat, ändert sie nachträglich.

7. Nutzen Sie für mehrere Benutzer den Trusted-Proxy-Modus, kein geteiltes Geheimnis. OpenClaw unterstützt gateway.auth.mode: "trusted-proxy", das die Identität an einen Reverse Proxy vor dem Gateway übergibt. Zusammen mit einem SSO-fähigen Proxy bekommen Sie so isolierte Sitzungen je Benutzer, ohne allen das gemeinsame Geheimnis auszuhändigen. Teilt Ihr Team sich heute ein Gateway, indem es das Token herumreicht, beheben Sie das zuerst.

Wo das Selbermachen aufhört

Der Trusted-Proxy-Modus löst die Identität, nicht die Autorisierung. Selbst mit gehärteter Runtime und einem SSO-Proxy davor fehlen Ihnen vier Dinge. Rollen, also Admin gegenüber Mitglied. Zugriffskontrolle je Agent, also wer mit welchem Agenten sprechen darf. Berechtigungen je Tool, also was jeder Agent darf, je Benutzer durchgesetzt. Und ein Audit-Trail, der im Nachhinein etwas beweisen kann. Das sind keine Härtungs-Lücken, die Sie wegkonfigurieren können. Es ist eine Verwaltungsschicht, die jemand bauen muss.

Sie haben drei ehrliche Möglichkeiten:

• Bleiben Sie bei einem Benutzer. Für eine persönliche Installation völlig in Ordnung. Hier ist Schluss.
• Bauen Sie die Schicht selbst. Ein Frontend, das Konten und Rollen besitzt, Benutzer auf isolierte Sitzungen abbildet, Tools je Agent kontrolliert und signierte Audit-Einträge schreibt. Das ist echte Arbeit, und Sie pflegen sie gegen eine Runtime, die sich rasch weiterentwickelt.
• Nutzen Sie eine fertige Schicht.

Was eine Governance-Schicht ergänzt

Dafür haben wir Pinchy gebaut, der Rest dieses Abschnitts beschreibt also unser eigenes Produkt. Pinchy ist quelloffen (AGPL-3.0) und sitzt vor OpenClaw als einziger Client, der das Gateway-Geheimnis hält:

• Identität und Rollen: Benutzer melden sich mit eigenen Konten an, Admin- und Benutzerrolle sind getrennt. Das Gateway-Geheimnis erreicht nie einen Browser.
• Zugriff je Agent: Agenten sind persönlich oder geteilt, geteilte Agenten sind auf Gruppen begrenzt. Jeder Benutzer bekommt seine eigene, isolierte Unterhaltung mit einem Agenten.
• Tool-Berechtigungen per Allow-List: Ein neuer Agent startet ohne Tools. Admins schalten jedes Tool je Agent einzeln frei.
• Manipulationssichtbarer Audit-Trail: Jede Agenten-Aktion wird mit einem einzeln signierten (HMAC) Eintrag festgehalten, nachträgliche Änderungen sind also erkennbar. CSV-Exporte enthalten die Signaturen zur unabhängigen Prüfung.
• Selbst-gehostet, wie die Runtime selbst: ein Docker-Compose-Stack neben Ihrem OpenClaw, lokale Modelle über Ollama werden unterstützt.

Wenn Sie lieber bauen als übernehmen: Unsere Architektur-Notizen und das Design des Audit-Trails sind öffentlich, nehmen Sie sich, was nützlich ist. Und wenn Sie Pinchy testen und etwas diesem Artikel nicht standhält, wollen wir genau diesen Issue-Report.