OpenClaw sicher betreiben: Sandboxing & Exec-Approvals

OpenClaw kann KI-Agenten direkt mit lokalen Dateien, Prozessen und Netzwerkdiensten arbeiten lassen. Das ist mächtig, erhöht aber auch die Angriffsfläche: Ein fehlgeleiteter oder schlecht eingegrenzter Agent kann Dateien verändern, Prozesse starten oder auf Systeme zugreifen, die du eigentlich nicht anfassen wolltest.

Zwei Mechanismen begrenzen dieses Risiko: Sandboxing isoliert die Tool-Ausführung, und Exec-Approvals kontrollieren Host-Befehle, die ein Agent außerhalb der Sandbox ausführen möchte. Wichtig ist die genaue Abgrenzung: Sandboxing reduziert die Reichweite normaler Tool-Aufrufe; Exec-Approvals sind die zusätzliche Host-Sicherung für Ausführung auf gateway oder node.

Sandboxing: Tool-Ausführung in der Kapsel

Sandboxing ist in OpenClaw optional und wird über die Agent-Konfiguration gesteuert, entweder global über agents.defaults.sandbox oder agentenspezifisch über agents.list[].sandbox. Laut aktueller Doku steuert agents.defaults.sandbox.mode, wann Sandboxing verwendet wird. Wenn Sandboxing aus ist, laufen Tools auf dem Host.

Wenn Sandboxing aktiv ist, läuft nicht der komplette Gateway-Prozess in der Sandbox. Der Gateway bleibt auf dem Host; isoliert wird die eigentliche Tool-Ausführung.

Die Doku ist hier bewusst vorsichtig: Die Sandbox ist keine perfekte Sicherheitsgrenze. Sie reduziert aber den Blast Radius erheblich, wenn ein Modell einen unsinnigen oder riskanten Tool-Aufruf erzeugt.

Was wird gesandboxt?

Laut Doku können unter anderem diese Tool-Ausführungen in der Sandbox landen:

• exec
• read
• write
• edit
• apply_patch
• process
• weitere Tool-Ausführungen, abhängig von Konfiguration und Backend

Optional kann auch der Browser innerhalb der Sandbox betrieben werden. Die relevanten Einstellungen liegen unter agents.defaults.sandbox.browser.

Für den Sandbox-Browser nennt die Doku unter anderem diese Punkte:

• Der Sandbox-Browser kann automatisch starten, wenn das Browser-Tool ihn benötigt (autoStart, autoStartTimeoutMs).
• Browser-Container nutzen standardmäßig ein dediziertes Docker-Netzwerk namens openclaw-sandbox-browser statt des globalen bridge-Netzwerks.
• agents.defaults.sandbox.browser.cdpSourceRange kann den CDP-Ingress am Container-Rand per CIDR-Allowlist beschränken, zum Beispiel auf 172.21.0.1/32.
• noVNC-Observer-Zugriff ist standardmäßig passwortgeschützt. OpenClaw erzeugt dafür eine kurzlebige Token-URL, die eine lokale Bootstrap-Seite ausliefert und das Passwort im URL-Fragment übergibt, nicht in Query- oder Header-Logs.
• Für target: "custom" können Allowlist-Optionen wie allowedControlUrls, allowedControlHosts und allowedControlPorts greifen.

Was bleibt außerhalb?

Nicht gesandboxt werden insbesondere:

• der Gateway-Prozess selbst,
• Tools, die explizit außerhalb der Sandbox laufen dürfen,
• Elevated Exec.

Der letzte Punkt ist sicherheitsrelevant: Elevated Exec umgeht das Sandboxing und nutzt den konfigurierten Escape-Pfad. Standardmäßig ist das laut Doku gateway; wenn das Exec-Ziel node ist, kann der Escape-Pfad node sein. Wenn Sandboxing ohnehin deaktiviert ist, ändert Elevated in Bezug auf Sandbox-Isolation nichts, weil die Ausführung bereits auf dem Host stattfindet.

Exec-Approvals: Host-Befehle kontrollieren

Exec-Approvals sind die Begleit-App- beziehungsweise Node-Host-Sicherung für Befehle, die ein gesandboxter Agent auf einem echten Host ausführen möchte: auf dem Gateway-Host oder auf einem Node.

Die Doku beschreibt sie als Sicherheitsverriegelung: Ein Befehl ist nur erlaubt, wenn Policy, Allowlist und gegebenenfalls Benutzerfreigabe zusammenpassen.

Wichtig: Exec-Approvals sind kein pauschaler Filter für jede interne Sandbox-Aktion. Sie greifen lokal auf dem Ausführungshost, wenn Host-Exec über gateway oder node angefordert wird.

Exec-Approvals liegen zusätzlich auf Tool-Policy und Elevated-Gating. Eine Ausnahme nennt die Doku ausdrücklich: Wenn Elevated auf full gesetzt ist, werden Approvals übersprungen.

Die effektive Policy ist die strengere Kombination aus tools.exec.* und den Approval-Defaults. Wenn ein Approval-Feld fehlt, wird der Wert aus tools.exec verwendet.

Außerdem zählt der lokale Approval-Zustand auf der jeweiligen Maschine. Eine host-lokale Einstellung wie ask: "always" in ~/.openclaw/exec-approvals.json sorgt weiter für Prompts, auch wenn Session- oder Config-Defaults ask: "on-miss" anfordern.

Wo greifen Exec-Approvals?

Exec-Approvals werden lokal auf dem Ausführungshost durchgesetzt:

• Gateway-Host: der openclaw-Prozess auf der Gateway-Maschine
• Node-Host: der Node-Runner, etwa über die macOS Companion-App oder einen headless Node

Wenn die Companion-App-UI nicht verfügbar ist, entscheidet der Ask-Fallback über Anfragen, die sonst einen Prompt erzeugen würden. Der Standard ist laut Doku deny.

Native Chat-Approval-Clients können zusätzliche Bedienelemente in Approval-Nachrichten anbieten. Die Doku nennt Matrix als Beispiel: Reaktionen wie ✅ für einmal erlauben, ❌ für ablehnen und ♾️ für dauerhaft erlauben können als Shortcuts erscheinen; /approve ...-Befehle bleiben als Fallback erhalten.

Praktische Einrichtung

1. Aktuelle Konfiguration finden

Zuerst solltest du prüfen, welche Konfigurationsdatei deine Installation tatsächlich verwendet:

openclaw config file

Dann validierst du den aktuellen Stand:

openclaw config validate

Für nicht-interaktive Änderungen stellt OpenClaw die Config-CLI bereit:

openclaw config get agents.defaults.sandbox --json
openclaw config schema

2. Sandboxing korrekt aktivieren

Die Live-Doku nennt agents.defaults.sandbox.mode als Steuerung dafür, wann Sandboxing verwendet wird. Verwende deshalb nicht blind ein altes oder geratenes Feld wie enabled: true, sondern prüfe die gültigen Mode-Werte deiner installierten OpenClaw-Version über Schema oder Doku.

Schema anzeigen:

openclaw config schema

Aktuelle Sandbox-Konfiguration anzeigen:

openclaw config get agents.defaults.sandbox --json

Nach der Änderung immer validieren:

openclaw config validate

Eine robuste Zielstruktur sieht konzeptionell so aus:

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "<gültiger-sandbox-mode-aus-schema-oder-doku>",
        "browser": {
          "autoStart": true,
          "network": "openclaw-sandbox-browser"
        }
      }
    }
  }
}

Der Platzhalter ist Absicht: Die OpenClaw-Doku legt fest, dass mode der relevante Schalter ist, aber die gültigen Werte solltest du gegen deine installierte Version prüfen. Ein Artikel oder Blogpost sollte hier nicht genauer sein als die tatsächlich laufende Version.

3. Exec-Approvals prüfen

Für die wirksame Approval-Policy nutzt du:

openclaw approvals get

Gezielt für den Gateway-Host:

openclaw approvals get --gateway

Gezielt für einen Node:

openclaw approvals get --node <id|name|ip>

Für die lokale Maschine zeigt diese Ansicht die zusammengeführte Exec-Policy:

openclaw exec-policy show

Zum Synchronisieren der lokal angeforderten Policy mit der lokalen Host-Approval-Datei nennt die Doku:

openclaw exec-policy set
openclaw exec-policy preset

Welche konkreten Werte du setzt, hängt von deinem Sicherheitsmodell ab. Für produktive Systeme gilt: erst restriktiv starten, dann gezielt erlauben.

Praxisrelevanz

Für Entwickler und Teams sind Sandboxing und Exec-Approvals keine kosmetischen Optionen. Sie bestimmen, ob ein Agent nur in einem begrenzten Arbeitsbereich experimentiert oder ob er direkt auf Host-Ressourcen zugreifen kann.

Ein typisches Szenario: Ein Agent soll Logs analysieren und kleinere Wartungsaufgaben vorbereiten. Mit Sandboxing laufen normale Datei- und Prozesszugriffe innerhalb der isolierten Tool-Umgebung. Wenn der Agent innerhalb dieser Umgebung einen destruktiven Befehl absetzt, bleibt der Schaden eher auf die Sandbox begrenzt.

Sobald der Agent aber auf dem echten Host ausführen will, etwa über Gateway- oder Node-Exec, müssen Exec-Approvals greifen. Dann reicht nicht mehr nur „das Modell hat es vorgeschlagen“; Policy, Allowlist und gegebenenfalls eine aktive Freigabe müssen zusammenpassen.

Die Kombination ist deshalb wichtig:

• Sandboxing reduziert den Schaden normaler Tool-Ausführung.
• Exec-Approvals kontrollieren Host-Ausführung.
• Elevated-Konfigurationen müssen besonders streng geprüft werden, weil sie die Sandbox umgehen können.

Grenzen

Sandboxing ist kein Silver Bullet. Es schützt vor vielen Fehlgriffen und begrenzt die Reichweite, ersetzt aber keine Host-Härtung, keine saubere Rechtevergabe und keine Updates für Container-Runtime oder Kernel.

Exec-Approvals sind ebenfalls nur so gut wie die Policy und die Aufmerksamkeit der freigebenden Person. Wer jede Anfrage ungelesen bestätigt, hat faktisch keine wirksame Kontrolle. Im automatisierten Betrieb können Prompts außerdem zum Flaschenhals werden. Dann brauchst du klare Allowlist-Regeln statt dauernder Ad-hoc-Freigaben.

Was wir daraus mitnehmen

Sandboxing und Exec-Approvals sind zwei zentrale Sicherheitsbausteine für den OpenClaw-Betrieb:

• Aktiviere Sandboxing früh und prüfe die wirksame Konfiguration mit openclaw config validate.
• Behandle agents.defaults.sandbox.mode als relevanten Sandbox-Schalter und gleiche gültige Werte mit Schema oder Doku ab.
• Prüfe mit openclaw approvals get und openclaw exec-policy show, welche Host-Exec-Policy wirklich gilt.
• Sei besonders vorsichtig mit Elevated Exec, weil es die Sandbox umgehen kann.

Für den Alltagsbetrieb ist eine restriktive Anfangskonfiguration sinnvoll. Erlaube nur, was du wirklich brauchst, und erweitere Policies schrittweise, sobald du das Verhalten deiner Agenten im konkreten Workflow verstanden hast.

Weiterführende Links: Tutorial: Installation & Setup · Browser Relay · Sandboxing-Doku · Exec-Approvals-Doku