OpenClaw Berechtigungsgrenzen: Warum dein Agent nicht alles darf
Das Problem mit zu großzügigen Agenten
Auf X kursiert gerade ein Tweet, der in der OpenClaw-Community viel Anklang findet:
> "Dear @openclaw: no more rm -f in the workspace, no spinning up docker images without using Komodo API, no more updating your SOUL.md"
Klingt wie ein Frustrations-Tweet. Ist es aber eigentlich ein perfektes Sicherheits-Design-Dokument in drei Zeilen.
Wenn dein Agent Befehle wie `rm -rf` ausführen kann, Docker-Images starten kann und seine eigene Konfiguration ändern kann — hast du keinen Assistenten. Du hast ein autonomes System mit Root-Zugriff auf deine Infrastruktur.
Das ist nicht hypothetisch. In unserem eigenen Setup ist genau das in Woche 2 passiert: Ein Agent hat versehentlich ein komplettes Verzeichnis gelöscht, weil er "aufräumen" wollte. Kein böser Wille — nur ein schlecht definierter Auftrag.
Was du kontrollieren musst
Hier sind die vier kritischsten Berechtigungsbereiche in jeder OpenClaw-Konfiguration:
1. Shell-Befehls-Ausführung (exec)
Das ist das gefährlichste. OpenClaw gibt Agenten standardmäßig Zugriff auf Shell-Befehle. Das `exec`-Tool kann Dateien löschen, Prozesse starten, Netzwerkverbindungen aufbauen — alles.
Kontrollmechanismus: Die `exec`-Sicherheitspolicy in der Gateway-Konfiguration.
```yaml
# openclaw.config.yml (Gateway)
tools:
exec:
security: "allowlist" # deny | allowlist | full
allowlist:
- "git *"
- "bun *"
- "grep *"
- "cat *"
- "ls *"
```
Mit `security: "allowlist"` kann der Agent nur exakt die aufgeführten Muster ausführen. Alles andere löst eine Bestätigung aus — oder wird blockiert.
Für destruktive Befehle: Nutze `ask: "always"`, damit der Agent bei jedem `rm`, `kill` oder `docker`-Befehl eine explizite Genehmigung anfordern muss.
2. Datei-Schreibzugriff
Ein Agent mit Schreibzugriff auf sein eigenes Konfigurationsverzeichnis kann buchstäblich seine Identität ändern. SOUL.md, USER.md, AGENTS.md — das sind die Dateien, die sein Verhalten definieren.
Was wir gelernt haben: Wir trennen jetzt strikt zwischen:
Das durchzusetzen ist nicht trivial, weil OpenClaw selbst keine dateiebene ACLs kennt. Unser Ansatz: Docker Volume Mounts mit expliziten `ro` (read-only) Flags für sensible Dateien:
```yaml
volumes:
- ./agents/sam/workspace:/home/sam/.openclaw/workspace:rw
- ./agents/sam/soul.md:/home/sam/.openclaw/workspace/SOUL.md:ro
- ./agents/sam/agents.md:/home/sam/.openclaw/workspace/AGENTS.md:ro
```
Jetzt kann Sam lesen, aber nicht überschreiben. Änderungen an SOUL.md müssen manuell vom Menschen gemacht werden.
3. Docker- und Systemzugriff
Der Tweet trifft es genau: Agenten sollten Docker nicht direkt steuern dürfen. Das gilt für:
Warum? Ein Agent, der Container starten kann, kann potenziell seinen eigenen "Sandbox-Ausbruch" orchestrieren — neue Container mit weniger Einschränkungen starten.
Lösung: Wenn Agenten Container-Operationen brauchen (z.B. Peter als Coding-Agent), route das über eine kontrollierte API wie Komodo statt direkten Docker-Socket-Zugriff:
```bash
# Statt: docker run ...
# Besser: API-Aufruf an Komodo/Portainer
curl -X POST "$KOMODO_API/containers/start" \
-H "Authorization: Bearer $KOMODO_TOKEN" \
-d '{"name": "test-sandbox"}'
```
Der Komodo-API-Endpoint kann seinerseits auf bestimmte Container-Namen/Images limitiert sein. Der Agent bekommt nie direkten Socket-Zugriff.
4. Eigene Speicher- und Konfigurationsänderungen
Das ist subtiler. Agenten, die lernen und sich erinnern, schreiben ständig in ihre Memory-Dateien. Das ist gewollt. Aber es gibt Grenzen:
Okay:
Nicht okay:
Die Bestätigungs-Pipeline (Approval Flow)
OpenClaw hat einen eingebauten Mechanismus für sensible Aktionen: den `ask`-Parameter im `exec`-Tool.
```
# Varianten
ask: "off" # Nie fragen — gefährlich
ask: "on-miss" # Nur fragen wenn kein Allowlist-Match
ask: "always" # Immer fragen
```
In unserem Setup nutzen wir gestaffelte Sicherheitsstufen pro Agent:
| Agent | exec-Sicherheit | Begründung |
|-------|----------------|------------|
| Sam (Teamlead) | allowlist | Schreibt in bekannte Verzeichnisse, keine System-Ops |
| Peter (Coding) | on-miss + Node-Sandbox | Führt Code aus, braucht mehr Freiheit |
| Maya (Marketing) | deny | Braucht exec nicht |
| Alex (Ops) | allowlist | Definierte Backup-Skripte |
| Iris (Research) | deny | Nur web_search, kein exec |
| Atlas (CEO-Assistent) | deny | Nur Lesen/Schreiben, keine Befehle |
Das spart Tokens (weniger Approval-Anfragen) und erhöht gleichzeitig die Sicherheit.
Approval-Befehle in der Praxis
Wenn ein Agent mit `ask: "on-miss"` auf einen nicht-whitelisted Befehl trifft, pausiert er und gibt dir einen Bestätigungs-Code:
```
[exec-approval-required]
Command: rm -rf /tmp/build-artifacts
Security: on-miss (no allowlist match)
/approve allow-once abc123
/approve allow-always rm -rf /tmp/*
/approve deny abc123
```
Du kannst:
Das ist der Unterschied zwischen einem Assistenten und einem Babysitter-System: Die meisten Operationen laufen automatisch, aber bei echten Risiken hält der Agent an.
Self-Modification: Die härteste Grenze
Der Punkt "no more updating your SOUL.md" aus dem Tweet ist philosophisch interessant: Sollte ein Agent sich selbst verbessern dürfen?
Kurzfristig verlockend. Langfristig: Nein.
Hier ist warum: Ein Agent, der seine eigene SOUL.md bearbeiten kann, kann seine eigenen Sicherheitsbeschränkungen entfernen. Nicht weil er es will — sondern weil eine scheinbar harmlose Aufgabe wie "schreibe besser auf Deutsch" bedeuten könnte, dass er die Zeile "Antworte immer auf Deutsch" in SOUL.md hinzufügt. Was er dabei nicht sieht: Er hat damit auch alle anderen Verhaltensregeln neu bewertet.
Unsere Regel: SOUL.md ist read-only für den Agenten. Änderungen macht nur der Mensch — bewusst, explizit, nach Überprüfung.
Die Unternehmens-Perspektive
Es gibt einen anderen Tweet aus der gleichen Nacht, der das Problem aus einer anderen Richtung beschreibt:
> "OpenClaw Has 250,000 Stars. Enterprises Won't Touch It. Here's What Needs to Change."
Der Autor führt aus, dass das größte Blockade-Thema für Enterprise-Adoption nicht die KI-Fähigkeiten sind — sondern Trust, Safety und Security. Wie kann ein Unternehmen einem System vertrauen, das im Prinzip Shell-Zugriff auf ihre Infrastruktur hat?
Die Antwort liegt nicht in OpenClaw selbst, sondern in wie du es konfigurierst:
Das sind keine neuen Konzepte. Das ist grundlegendes Principle-of-Least-Privilege, angewandt auf KI-Agenten.
Zusammenfassung: Die Permission-Checkliste
Bevor du einen neuen Agenten in Produktion nimmst:
Das sind 10 Minuten Konfigurationsarbeit, die verhindern, dass du später eine Stunde mit "wie hat das passiert?" verbringst.
---
Die genaue Konfiguration — Allowlist-Beispiele, Docker Volume Mounts, die Approval-Flow-Einrichtung und das komplette Permission-Modell für ein 6-Agenten-Team — findest du im OpenClaw Setup Playbook.
Komplett auf Deutsch verfügbar. 🇩🇪