OpenClaw sicher betreiben: Sandboxing & Exec-Approvals

OpenClaw kann KI-Agenten direkt mit deinen lokalen Dateien, Prozessen und Netzwerkdiensten arbeiten lassen. Das ist mächtig, aber es erhöht auch die Angriffsfläche: Ein fehlgeleiteter oder ungetesteter Agent könnte versehentlich Daten überschreiben, Prozesse killen oder sich unerwünscht im System ausbreiten.

Zwei Kernmechanismen helfen, das Risiko zu begrenzen: Sandboxing isoliert die Tool-Ausführung, und Exec-Approvals erfordern manuelle Freigabe für kritische Befehle. In diesem Artikel schauen wir uns an, wie beide funktionieren, wo sie greifen und wie du sie in deiner Konfiguration aktivierst.

Sandboxing: Tool-Ausführung in der Kapsel

Sandboxing ist in OpenClaw optional und wird über die Konfiguration gesteuert (agents.defaults.sandbox oder agents.list[].sandbox). Wenn es aktiviert ist, laufen Werkzeuge wie exec, read, write, edit, apply_patch und process in einer isolierten Umgebung - typischerweise einem Container. Die Gateway-Prozesse selbst bleiben auf dem Host; nur die eigentliche Tool-Ausführung landet in der Sandbox.

Laut Dokumentation ist das keine perfekte Sicherheitsgrenze, aber es verringert die Reichweite erheblich, falls ein Modell etwas Dummes tut. Dateisystem- und Prozesszugriffe werden eingeschränkt, und ein Fehler bleibt meist in der Sandbox stecken.

Was wird gesandboxt?

• Tool-Execution: exec, read, write, edit, apply_patch, process usw.
• Optional der Browser: Über agents.defaults.sandbox.browser kann auch der Browser-Tool in einer separaten Sandbox laufen. Standardmäßig startet der Sandbox-Browser automatisch, wenn das Browser-Tool ihn benötigt. Die Container nutzen ein dediziertes Docker-Netzwerk (openclaw-sandbox-browser) statt des globalen bridge-Netzwerks.
• CDP-Zugriff: Optional lässt sich der Container-edge CDP-Ingress mit einer CIDR-Allowlist einschränken (z.B. 172.21.0.1/32).
• noVNC-Observer: Der Zugriff auf den noVNC-Observer ist standardmäßig passwortgeschützt; OpenClaw generiert eine kurzlebige Token-URL, die eine lokale Bootstrap-Seite ausliefert und noVNC mit dem Passwort im URL-Fragment öffnet (nicht in Query/Header-Logs).

Was bleibt außerhalb?

• Der Gateway-Prozess selbst.
• Tools, die explizit außerhalb der Sandbox laufen dürfen (z.B. tools.elevated).
• Elevated exec umgeht das Sandboxing und nutzt den konfigurierten Escape-Pfad (gateway standardmäßig, oder node wenn das Exec-Target node ist). Wenn Sandboxing deaktiviert ist, ändert tools.elevated nichts - die Ausführung findet ohnehin auf dem Host statt.

Exec-Approvals: Die manuelle Freigabe-Schleife

Exec-Approvals sind die Begleit-App-/Node-Host-Sicherung, die es einem gesandboxten Agenten erlaubt, Befehle auf einem echten Host (gateway oder node) auszuführen. Sie wirken wie eine Sicherheitsverriegelung: Befehle sind nur erlaubt, wenn Policy, Allowlist und (optional) manuelle Benutzerfreigabe übereinstimmen.

Exec-Approvals kommen zusätzlich zur Tool-Policy und zur Elevated-Gating (es sei denn, Elevated ist auf full gesetzt, was Approvals überspringt). Die effektive Policy ist die strengere von tools.exec.* und den Approvals-Defaults; wenn ein Approvals-Feld fehlt, wird der Wert von tools.exec verwendet.

Host-Exec nutzt auch den lokalen Approvals-Status auf der jeweiligen Maschine. Eine host-lokale ask: "always" in ~/.openclaw/exec-approvals.json sorgt dafür, dass weiterhin nachgefragt wird, selbst wenn Session- oder Config-Defaults ask: "on-miss" vorschreiben.

Wo greifen Exec-Approvals?

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

• Gateway-Host → openclaw-Prozess auf der Gateway-Maschine
• Node-Host → Node-Runner (macOS Companion-App oder headless-Node)

Wenn die Companion-App-UI nicht verfügbar ist, wird jede Anfrage, die eine Prompt erfordert, durch den Ask-Fallback aufgelöst (Standard: deny).

Native Chat-Approval-Clients können channel-spezifische Bedienelemente in der ausstehenden Approvals-Nachricht anbieten. Beispielsweise kann Matrix Reaktions-Shortcuts im Approvals-Prompt setzen (✅ allow once, ❌ deny, und ♾️ allow always, wenn verfügbar), während die /approve ...-Befehle als Fallback in der Nachricht bleiben.

Praktische Einrichtung

Sandboxing aktivieren

In deiner [openclaw.json](https://docs.openclaw.ai/gateway/sandboxing.md) oder Agent-Konfiguration:

{
  "agents": {
    "defaults": {
      "sandbox": {
        "enabled": true,
        "browser": {
          "autoStart": true,
          "network": "openclaw-sandbox-browser"
        }
      }
    }
  }
}

Exec-Approvals konfigurieren

Lokal auf dem Host kannst du mit openclaw approvals get (oder openclaw approvals get --gateway bzw. openclaw approvals get --node <id|name|ip>) die angeforderte Policy, die Host-Policy-Quellen und das effektive Ergebnis einsehen.

Für die lokale Maschine bietet openclaw exec-policy show dieselbe zusammengeführte Ansicht, und openclaw exec-policy set|preset kann die lokale angeforderte Policy mit der lokalen Host-Approvals-Datei in einem Schritt synchronisieren.

Praxisrelevanz

Für Entwickler und Teams, die OpenClaw im Alltagsbetrieb einsetzen, sind Sandboxing und Exec-Approvals keine optionalen Spielereien - sie sind essenzielle Sicherheitsbausteine. Sie erlauben es, die Produktivität von Agenten zu nutzen, ohne das Host-System ungeschützt zu exponieren.

Ein typisches Szenario: Ein Agent soll automatisch Cron-Jobs einrichten und Log-Dateien analysieren. Mit Sandboxing läuft die Dateiansicht in einer isolierten Umgebung; falls der Agent versehentlich versucht, systemkritische Dateien zu löschen, bleibt der Schaden begrenzt. Gleichzeitig verhindert Exec-Approvals, dass der Agent ohne explizite Freigabe rm -rf / oder ähnlich gefährliche Befehle ausführt.

Die Kombination aus beidem gibt dir die Kontrolle zurück: Du entscheidest, welche Tools in welchem Umfang laufen dürfen, und behältst ein Veto-Recht für kritische Aktionen.

Grenzen und Ausblick

Sandboxing ist kein Silver Bullet. Es schützt vor dummen Fehlern und begrenzt die Reichweite, aber es kann keine gezielten Angriffe auf Schwachstellen in der Container-Runtimes oder im Host-Kernel verhindern. Exec-Approvals wiederum setzen voraus, dass der Nutzer die ausstehenden Anfragen zeitnah prüft - im automatisierten Betrieb kann das zum Flaschenhals werden.

OpenClaw entwickelt beide Mechanismen weiter. Die Dokumentation erwähnt bereits Optionen wie allowedControlUrls, allowedControlHosts und allowedControlPorts für feingranulare Allowlists, und die Integration von Approval-Flows in native Chat-Clients macht die Freigabe praktischer.

Was wir daraus mitnehmen

Sandboxing und Exec-Approvals sind die zwei zentralen Sicherheitsbausteine in OpenClaw. Sie erlauben es dir, mächtige Agenten zu nutzen, ohne das Host-System ungeschützt zu exponieren. Die Kombination aus Isolation und manueller Freigabe gibt dir die Kontrolle zurück: Du entscheidest, welche Tools laufen dürfen, und behältst ein Veto-Recht für kritische Aktionen.

Für den Alltagsbetrieb empfehle ich, Sandboxing von Anfang an zu aktivieren und Exec-Approvals so zu konfigurieren, dass sie deinen Workflow unterstützen – nicht blockieren. Starte mit einer restriktiven Policy und passe sie schrittweise an, sobald du Vertrauen in die Agenten-Sicherheit hast.

Wer OpenClaw langfristig und verantwortungsvoll betreiben will, sollte beide Mechanismen von Anfang an mitdenken – nicht als nachträgliche Absicherung, sondern als integralen Teil der Agenten-Architektur.

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