OpenClaw absichern – sechs Härtungsschritte vor dem ersten Public-Deploy

OpenClaw ist eines der spannendsten Self-Hosted-Agent-Frameworks der letzten Monate — ein Web-UI plus Multi-Channel-Gateway, der einem LLM den Zugriff auf Tools, Dateisystem, Browser und Telegram-DMs gibt, alles in einem Coolify-tauglichen Container. Genau diese Bequemlichkeit ist auch das Risiko.

Die Tutorials, die gerade durch Twitter und YouTube laufen, zeigen meistens denselben Setup-Flow: Container deployen, Login-Page öffnen, „Profile: full" mit allen 23 Tools aktivieren, API-Key einkleben, fertig. Was im Demo-Video aussieht wie ein freundlicher Chat-Assistent, ist sicherheitstechnisch ein offenes Mikrofon zum Server. Wir betreiben seit ein paar Wochen einen eigenen produktiven OpenClaw-Stack und haben dabei sechs Stellen gefunden, an denen das Default-Setup nicht produktionsreif ist. Hier sind sie — mit dem konkreten Schalter, den man umlegen muss.

Hardware-Hinweis vorab

Man liest gelegentlich Anleitungen, die OpenClaw auf einem dedizierten Mac mini im Heimnetz empfehlen. Für einen produktiv genutzten Agent ist das selten die richtige Wahl. Ein günstiger Linux-VPS — 4 GB RAM reichen für den Container plus Browser-Sidecar — bringt eine statische IP, eine saubere Firewall, automatische Container-Restarts und kostet pro Monat weniger als der Strom des Mac mini. Vor allem aber sitzt er außerhalb des Heimnetzes — was bedeutet, dass eine kompromittierte Tool-Whitelist nicht direkt im selben Subnetz wie der eigene Rechner und das NAS landet. Der Mac mini ist eine charmante Bastel-Lösung; für etwas, das von außen erreichbar ist und ein LLM mit Tool-Zugriff hostet, ist ein VPS das robustere Default.

1. Die Tool-Whitelist gehört nicht auf „full"

OpenClaw zeigt im UI ein Profil-Dropdown („minimal", „chat", „full") mit bis zu 23 Tools. Wer „full" wählt, schaltet auch bash, exec, process und group:runtime scharf — also das Recht, beliebige Shell-Kommandos im Container auszuführen. In Kombination mit dem optionalen Docker-Socket-Mount (siehe Punkt 4) ist das praktisch Root auf dem Host.

Der eigentliche Hebel sitzt nicht im UI, sondern im Config-File. tools.allow in openclaw.json ist eine globale Whitelist, die jedes Profil überschreibt. Bei uns steht sie auf ["message", "tts", "web_fetch", "read", "write"] — fünf Tools, kein bash, kein exec. Das UI zeigt weiterhin „Profile: full mit 23/23 Tools", ein blauer Banner verrät den Override. Was wirklich in den System-Prompt geladen wird, sind die fünf.

Praktischer Effekt: weniger Tools heißt kleinerer System-Prompt heißt kleinere Rechnung und kleineres Kontext-Risiko. Mit allen 23 Tools haben wir in den ersten Tagen reproduzierbar das 30k-Token-pro-Minute-Rate-Limit von Sonnet 4.5 gerissen, ohne dass der Agent etwas Sinnvolles getan hätte. Das System-Prompt-Aufblähen kostet Geld, lange bevor das Modell überhaupt antwortet.

Empfehlung. Phasiertes Tool-Rollout. Phase 1: message, tts. Phase 2: plus web_fetch, read. Phase 3: plus write (mit Workspace-Disziplin, siehe Punkt 5). Phase 4: gh mit gescoptem Personal-Access-Token, der nur einen Branch-Prefix beschreiben darf. bash, exec, process nie — diese drei kippen die Container-Isolation, die der Rest der Installation aufbaut.

2. Login-Page gehört nicht direkt ans öffentliche Internet

OpenClaw bringt ein Login mit Username, Passwort und Gateway-Token mit. Das ist ordentlich umgesetzt, aber es ist ein Login — und Logins, die direkt an Port 443 hängen, ohne weitere Auth-Schicht, ziehen den ganzen Standard-Brute-Force-Verkehr aus China, Russland und allen Bot-Netzen, die gerade nach /wp-login.php scannen, automatisch auf sich. Sobald der Pfad bekannt ist, kommt der Verkehr.

Eine vorgeschaltete Cloudflare-Access-Policy mit Email-OTP-Allowlist (eine einzige Email, die über Magic-Link bestätigt) ist in 15 Minuten eingerichtet und schiebt das gesamte Anmelde-Surface hinter eine zweite Auth-Stufe. Der Container sieht nie eine HTTP-Anfrage, die nicht vorher von Cloudflare validiert wurde. Brute-Force-Versuche landen am Cloudflare-Edge und kommen nicht beim OpenClaw-Login an.

Für die Telegram-Integration gilt das analog. Ein Telegram-Bot kann theoretisch von jedem User der Welt eine DM bekommen, sobald sein Username bekannt ist. channels.telegram.dmPolicy mit Wert "allowlist" plus allowFrom: ["<deine-telegram-user-id>"] macht den Bot deaf für jeden außer dem Owner. Ohne diese Zeile ist jede DM ein potenzieller LLM-Aufruf auf deine Rechnung. Wichtig: dmPolicy existiert nur für WhatsApp und Telegram — für Discord oder Slack führt die Option zum Container-Crash beim Validate.

3. Spending-Cap, bevor das Modell antwortet

Der Default in vielen OpenClaw-Anleitungen ist Anthropic-Sonnet oder ein aktuelles OpenAI-Flaggschiff (GPT-4o, GPT-4.1) als Primärmodell. Das ist die teure Schiene — gegenüber Haiku reden wir je nach Modellwahl von Faktor 3 bis Faktor 20. Wer ohne Spending-Limit am API-Key startet und den ersten Punkt ignoriert (also alle 23 Tools enabled), kann mit einer einzigen Kontext-Loop oder einem Prompt-Injection-Loop binnen Stunden ein vierstelliges Monatsbudget verbrennen — wir haben Berichte gesehen, die das mit Schraubzieher-Genauigkeit dokumentieren.

Drei Schalter zusammen schließen das Loch. Erstens: in der Anthropic- bzw. OpenAI-Console ein hartes Monthly-Spending-Limit setzen, idealerweise im niedrigen zweistelligen Bereich für den Test-Betrieb. Zweitens: in openclaw.json unter agents.defaults.model.primary ein Modell pinnen, das zum Use-Case passt — wer Kosten reduzieren möchte, ist mit einem günstigeren Modell wie anthropic/claude-haiku-4-5-20251001 gut bedient; bei komplexeren Reasoning-Aufgaben kann sich Sonnet oder Opus rechnen. Drittens: dasselbe Modell nochmal als Env-Var OPENCLAW_PRIMARY_MODEL setzen, weil ein leeres Feld in der Config sonst stillschweigend auf Sonnet zurückfällt. Defense in depth, weil das einzige Versehen, das hier teuer wird, eines ist, das du nicht bemerkst.

Konkretes Rechenbeispiel: bei voller 23-Tool-Whitelist auf Opus 4.7 kostet ein einziger System-Prompt-Roundtrip rund 0,20 €. Bei ["message", "tts", "web_fetch", "read", "write"] auf Haiku 4.5 sind es rund 0,01 €. Faktor 20 — nicht durch das, was der Agent leistet, sondern allein durch die Tool-Liste plus Modellwahl. Sonnet liegt zwischen den beiden, eher Faktor 3 bis 5 gegenüber Haiku.

4. Die Docker-Socket-Sandbox isoliert nicht den Server

OpenClaw bietet einen optionalen „Sandbox"-Mechanismus, der elevated Tools in einem separaten, frischen Per-Session-Container ausführt. Klingt sicher. Ist es nur, wenn man die Trust-Boundary richtig liest.

Der Mechanismus funktioniert so: /var/run/docker.sock wird in den OpenClaw-Container bind-gemountet, der Container darf damit auf der Host-Docker-API beliebige Container starten. Der Sandbox-Container, in dem das Tool dann läuft, ist tatsächlich vom Agent-Container getrennt — aber wer Schreibzugriff auf den Docker-Socket hat, kann auch jeden anderen Container auf dem Host starten, mit beliebigen Mounts. Das schließt /etc, /root, /var/lib/coolify und alles andere ein, was Coolify dort verwaltet.

Anders gesagt: die Sandbox isoliert das Tool vom Agenten, nicht den Server vom Agenten. Wenn das LLM einen Weg findet, Code auszuführen, der den Docker-Socket benutzt — und in full-Profilen mit bash+process+group:runtime ist genau das ein verfügbares Tool — ist es Root auf dem Host. Diese Erkenntnis ist der Grund, warum Punkt 1 keine Komfort-Empfehlung ist, sondern eine Sicherheitsempfehlung.

Empfehlung. Wenn du die Sandbox aktivierst (Env-Var OPENCLAW_DOCKER_APT_PACKAGES=docker.io), behandle den OpenClaw-Container so, als wäre er ein Privileged-Container mit Host-Root. Login-Auth muss dann härter sein als das, was du auf dem Host an SSH zulassen würdest. Bei uns liegt sie aktuell deaktiviert, weil der Newsroom-Use-Case kein Shell-Tool braucht.

5. Workspace ohne harten Sandbox – Pfad-Disziplin per Konvention

Sobald write in der Tool-Whitelist steht, hat der Agent ein universelles File-Schreib-Primitiv. OpenClaw scoped write standardmäßig nicht auf einen Workspace — die Default-CWD ist /data/workspace, aber der Agent kann mit relativen Pfaden hochwandern oder mit absoluten Pfaden überall im Container schreiben, wo der Container-User schreiben darf. Inklusive /data/.openclaw/openclaw.json. Das heißt: ohne weitere Vorkehrungen ist der Agent eine Software, die ihre eigene Tool-Whitelist umschreiben darf, sobald jemand (oder das Modell selbst) auf die Idee kommt.

Eine harte Sandbox wäre konfigurierbar (agents.defaults.sandbox), kostet aber Komplexität, die für den Single-User-Telegram-Bot meist überdimensioniert ist. Die pragmatische Lösung: eine AGENTS.md im Workspace, die dem Agent in jedem Turn als System-Prompt-Ergänzung mitgegeben wird, mit klaren Pfad-Regeln. Bei uns: Drafts gehen nach drafts/YYYY-MM-DD-<slug>.md, alles unter .openclaw/ und .git/ ist tabu, Identitätsdateien werden namentlich genannt. Konvention ist nicht dasselbe wie Sandbox — sie verhindert bequeme Selbstbeschuss-Aktionen, nicht bösartige Pfad-Traversal-Versuche. Für den nächsten Vertrauenslevel ist die echte Sandbox dran.

6. Backups und Logs – die Punkte, die niemand lustig findet

Der Coolify-Volume mit dem OpenClaw-State liegt unter /var/lib/docker/volumes/<hash>_openclaw-data/_data. Ohne Backup ist eine fehlgeschlagene Server-Reinstallation gleichbedeutend mit dem Verlust der gesamten Konversationshistorie, aller Cron-Jobs, aller Persistent-Memory-Einträge des Agents und (ärgerlich) aller Workspace-Inhalte, die nie ins Git committed wurden. Coolify bietet S3- oder Object-Storage-Backups in der UI an. Fünf Minuten Setup, schließt das Loch komplett.

Zweiter Punkt: logging.redactSensitive = "tools" in openclaw.json. Ohne diese Zeile landen Tool-Argumente vollständig in den Container-Logs — also auch der Anthropic-API-Key, das Telegram-Bot-Token und alles, was per web_fetch über Authorization-Header rausgeht. Wenn jemand mal Container-Logs für ein Issue weiterreicht (oder Coolify-Logs für Support), gehen diese Secrets mit. Das Maskieren ist eine Zeile Config und kostet keine Performance — das ist der einzige Grund, warum es noch nicht überall an ist.

Was diese sechs gemeinsam haben

OpenClaw ist ein Werkzeug, das im Browser lokal harmlos wirkt, weil man die Konsequenzen nicht sieht. Sobald web_fetch aktiv ist, ist der Bot ein Outbound-HTTP-Klient mit Internet-Zugriff. Sobald write aktiv ist, ist er ein File-Writer im Container. Sobald die Docker-Socket bind-gemountet ist, ist er Root-äquivalent auf dem Host. Diese drei Eskalationen passieren oft in derselben Setup-Session — und keiner davon wird in den verbreiteten Tutorials sauber markiert.

Das Muster ist immer dasselbe: das UI sieht aus wie ein Chat. Das Backend ist ein Daemon mit weitreichenden Capabilities. Wer den Sprung zwischen diesen beiden Realitäten nicht aktiv macht, deployed gut gemeinte Software, die im Worst Case auf seine Rechnung redet, schreibt und exekutiert. Die sechs Härtungspunkte oben sind kein Optimum — sie sind das Minimum, das wir uns selbst beim Live-Gang abverlangen, bevor wir den Bot in den eigenen Coolify-Stack lassen. Bei jedem zusätzlichen Tool, das später dazukommt (Phase 3 mit gh, perspektivisch echte Sandbox), wandert die Liste mit.

Wer einen produktiv genutzten Agent betreibt, sollte die openclaw.json einmal alleine durchlesen — nicht das UI, nicht das Tutorial, sondern das tatsächliche Config-File. Dort steht, was der Agent darf. Alles andere ist Marketing.