OpenClaw-Sandbox in der Praxis: AI-Agent-Aufgaben in isoliertem macOS ausführen

Nackter Agent vs. Sandbox-Agent: Wo sich die Berechtigungsfläche unterscheidet

Wenn ein Entwickler per SSH auf einen Mac zugreift, weiß er in der Regel, dass er ~/.ssh nicht löschen oder Distribution-Zertifikate exportieren sollte. AI Agents verhalten sich anders—Frameworks, die Shell-, Datei- und Netzwerk-Tools aufrufen, erben standardmäßig die vollen Rechte des aktuellen macOS-Benutzers. Ein Agent mit der Aufgabe „scanne das Repo nach TODOs und schreibe einen Markdown-Bericht“ braucht theoretisch nur Lesezugriff auf das Projektverzeichnis und Schreibzugriff auf eine Ausgabedatei; in der Praxis kann er Keychain, Browser-Cookies und beliebige ausgehende HTTP-Anfragen erreichen.

Containerisierung isoliert Prozesse, kostet auf macOS aber die volle Xcode-Toolchain und Apple-native Frameworks; pro Aufgabe eine VM neu aufzubauen, ist für interaktive Agent-Schleifen zu langsam. OpenClaw geht einen dritten Weg: auf echtem macOS trifft YAML-Richtlinien auf Syscall-Ebene Allow/Deny-Entscheidungen, und jede Entscheidung landet im Audit-Stream. Der Agent kann weiterhin die 38 TOPS Neural Engine des M4 für lokale Inferenz nutzen, aber Reads und Writes außerhalb der Richtlinie werden sofort blockiert.

Die Demo-Aufgabe in diesem Beitrag ist bewusst schmal gehalten: statischen Scan auf einem vorhandenen Code-Snapshot in der Sandbox ausführen (rg für TODO/FIXME), einen von der Richtlinie abgelehnten git clone versuchen und den Bericht unter /workspace schreiben. Erfolgskriterien: Skript läuft durch, Audit-Logs zeigen sowohl Allow- als auch Deny-Ereignisse, und jedes Ereignis lässt sich auf die auslösende YAML-Regel zurückführen.

Für Teams in der DACH-Region ist der Audit-Stream oft der entscheidende Unterschied zur bloßen Prozessisolation: Wer Agents auf Produktions-Credentials oder Kundendaten loslässt, braucht nachvollziehbare Entscheidungsprotokolle—nicht nur „es ist schiefgegangen“. OpenClaw schreibt jede Allow- und Deny-Entscheidung mit Zeitstempel, betroffenem Pfad und Regelindex; das lässt sich in SIEM-Pipelines einspeisen oder für interne Reviews exportieren, ohne den Agent-Workflow zu verlangsamen.

Vorbereitung: Vier Voraussetzungen einmal prüfen

Ihr lokaler Laptop kann Windows, Linux oder macOS sein—solange ein SSH-Client vorhanden ist. Fehlt aber auch nur eine der vier Punkte unten, bleibt der Ablauf mittendrin hängen.

• Bereitgestellte JexMac-Instanz: In der Konsole unter „Zugangsdaten“ erscheinen SSH-Adresse und Port. Fünf Knoten—Singapur, Japan (Tokio), Korea (Seoul), Hongkong, US-Ost—gleiche Specs und Preise; für Agent-Experimente wählen Sie die Region mit der geringsten Latenz zu Ihrer Ziel-API.
• OpenClaw instance-token: Wird bei erster Aktivierung unter Konsole „Sicherheit & Sandbox“ erzeugt, Format wie oct-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Wird nur einmal angezeigt—sofort in 1Password, Bitwarden o. Ä. speichern.
• Arbeitsverzeichnis /workspace: Vorab auf dem Host anlegen; die Sandbox mappt diesen Pfad als Lese-/Schreibzone des Agents. Keine Privatkeys oder p12-Dateien hier ablegen.
• Mindestens eine Richtlinien-YAML: Abschnitt 5 liefert eine Read-only-Vorlage; Prinzip ist strikt starten und anhand von Deny-Logs lockern—nicht Berechtigungen vorab raten.

OpenClaw in der Konsole aktivieren und instance-token sichern

OpenClaw ist nicht standardmäßig an—jede physische Instanz wird unabhängig gesteuert, damit Workloads ohne Audit-Anforderung keinen Overhead zahlen. Drei Browser-Schritte unten; alles Weitere läuft über SSH.

1. 01
   Instanzdetail → „Sicherheit & Sandbox“

   In der JexMac-Konsole einloggen, die Ziel-Mac-mini-Instanz öffnen, OpenClaw-Schalter finden. Bei frischer Bereitstellung (innerhalb 1–5 Minuten) warten, bis der Status „Running“ zeigt, bevor Sie fortfahren.

2. 02
   Aktivieren und Token kopieren

   Aktivieren klicken; ein Dialog zeigt den instance-token. Nach Bestätigung der Speicherung im Secrets Manager „Gespeichert, fortfahren“ klicken. Token niemals in Slack, Tickets oder Git-Commits einfügen.

3. 03
   Badge „Aktiviert“ bestätigen

   Status länger als 30 Sekunden auf „Wird aktiviert“: Seite neu laden. Sobald das grüne Badge erscheint, Browser schließen—CLI übernimmt den Rest.

CLI per SSH installieren und Drei-Komponenten-Gesundheitscheck

Nach SSH-Login erkennt das Installationsskript Apple Silicon und ist auf M4 typischerweise in unter 30 Sekunden fertig.

curl -fsSL https://api.jexmac.com/openclaw/install.sh | bash
openclaw auth login --token <instance-token>
openclaw status

openclaw status muss alle drei Komponenten als healthy anzeigen:

Ist eine Komponente degraded oder unavailable, zuerst openclaw doctor ausführen. Häufige Ursache: Systemerweiterung nach Erstinstallation noch nicht freigegeben—per Browser-VNC verbinden, Systemeinstellungen → Datenschutz & Sicherheit, OpenClaw erlauben, dann CLI-Dienst per SSH neu starten. „Policy Engine healthy“ bedeutet, der Prozess läuft—nicht, dass Ihre YAML gültig ist; Richtlinienvalidierung ist ein separater Schritt im nächsten Abschnitt.

Least-Privilege-Richtlinie: versionierte YAML

Die Richtliniendatei legt fest, welche Pfade der Agent lesen darf, welche Prozesse er starten kann und ob ausgehendes Netzwerk erlaubt ist. Empfohlener Workflow: erste YAML öffnet nur das für die Aufgabe nötige Minimum → Aufgabe ausführen → Deny-Logs prüfen → bei Bedarf Allow-Regeln ergänzen—nicht weit öffnen und später einschränken.

Folgendes als ~/policies/agent-readonly.yaml speichern:

apiVersion: openclaw.jexmac.com/v2
kind: SandboxPolicy
metadata:
  name: agent-readonly
spec:
  filesystem:
    allow:
      - path: /workspace
        access: [read, write]
    deny:
      - path: "**/Keychains/**"
      - path: "**/.ssh/**"
      - path: "**/Library/Cookies/**"
  process:
    allow: [git, rg, python3, zsh, bash]
  network:
    egress: deny-all

Drei Designpunkte: Deny hat Vorrang vor Allow—selbst wenn /workspace beschreibbar ist, werden Pfade in der Deny-Liste weiter blockiert; process.allow ist eine Prozessnamen-Whitelist—braucht der Agent node oder npm, explizit ergänzen, sonst E_POLICY_DENY: process; egress: deny-all blockiert in dieser Demo absichtlich git clone, damit Netzwerk-Deny-Ereignisse im Audit-Stream sichtbar werden.

Versionieren Sie Richtliniendateien im gleichen Git-Repo wie Ihre Agent-Konfiguration (~/policies/ oder ein dediziertes infra/openclaw/-Verzeichnis). Bei Policy-Änderungen zuerst validate, dann sandbox update—so bleibt der Diff nachvollziehbar und Rollbacks sind ein git revert entfernt. In größeren Teams empfiehlt sich eine Review-Pflicht für jede Erweiterung von process.allow oder network.egress, weil diese Felder die Angriffsfläche am stärksten vergrößern.

Syntax vor Sandbox-Erstellung validieren:

openclaw policy validate -f ~/policies/agent-readonly.yaml

Erwartete Ausgabe: policy valid (0 warnings); Tippfehler in Feldern oder v1-Legacy-Format melden konkrete Zeilennummern.

Sandbox anlegen, Agent-Aufgabe einreichen, Ergebnis prüfen

Bevor LangGraph o. Ä. angebunden wird, schließt ein deterministisches Shell-Skript die Schleife—vorhersehbares Verhalten erleichtert die Unterscheidung zwischen „Richtlinienproblem“ und „Agent-Logikproblem“ bei Fehlern.

Entry-Skript /workspace/agent-entry.sh auf dem Host anlegen:

#!/bin/zsh
set -euo pipefail
cd /workspace
git clone --depth 1 https://github.com/apple/swift-sample-code.git repo 2>/dev/null \
  || echo "clone blocked (expected)"
rg -rn "TODO|FIXME" . --glob '*.swift' > scan-report.txt 2>/dev/null || true
echo "Scan complete: $(wc -l < scan-report.txt | tr -d ' ') matches" > summary.txt
cat summary.txt

Nach chmod +x /workspace/agent-entry.sh der Reihe nach ausführen:

1. 01
   Sandbox erstellen

   openclaw sandbox create --name agent-demo --policy ~/policies/agent-readonly.yaml

   Rückgabestatus ready reicht. Doppeltes Create mit gleichem Namen meldet „already exists“—löscht keine Daten.

2. 02
   Zweite SSH-Sitzung: Audit live mitverfolgen

   openclaw audit tail --sandbox agent-demo --follow

   Entscheidungs-Events erscheinen typischerweise 50–200 ms nach der Operation.

3. 03
   Skript in der Sandbox ausführen

   openclaw sandbox exec agent-demo -- /bin/zsh /workspace/agent-entry.sh

   Erwartete Ausgabe enthält clone blocked (expected); summary.txt sollte die Scan-Zeilenanzahl enthalten.

4. 04
   Sandbox stoppen

   openclaw sandbox stop agent-demo

   Daten unter /workspace bleiben auf dem Host; mit --rm vollständig aufräumen.

Weil ausgehendes Netzwerk verweigert ist, schlägt git clone fehl—absichtlich, um ein prüfbares Netzwerk-Deny zu erzeugen. Läuft der rg-Schritt durch, stimmen die Filesystem-Allow-Regeln. Am Tokio-Knoten maßen wir ca. 2,6 Sekunden End-to-End; Policy-Overhead ist vernachlässigbar.

Wenn Sie später LangGraph oder CrewAI anbinden, bleibt der Einstiegspunkt gleich: der Framework-Prozess läuft außerhalb der Sandbox, Tool-Aufrufe mit Shell- oder Dateizugriff gehen über openclaw sandbox exec oder einen Wrapper, der pro Tool-Call eine kurze Sandbox-Session öffnet. So trennen Sie „Reasoning-Loop“ von „Ausführung mit erhöhten Rechten“—ein Muster, das sich in internen PoCs besser skaliert als alles unter einem Benutzerkonto laufen zu lassen.

Audit-Log-Felder: von Allow bis Deny lesen

Audit ist kein nachträglicher PDF-Bericht—sondern ein Event-Stream synchron zu Policy-Entscheidungen. Typischer Allow-Eintrag (Lesen des Entry-Skripts):

ts=2026-07-28T09:03:12.481Z
sandbox=agent-demo
syscall=open
resource=filesystem
path=/workspace/agent-entry.sh
access=read
decision=allow
policy_rule=filesystem.allow[0]
latency_us=34

policy_rule verweist auf den auslösenden YAML-Regelindex; latency_us ist Entscheidungslatenz in Mikrosekunden. Entsprechendes Netzwerk-Deny (blockierter Clone):

ts=2026-07-28T09:03:12.512Z
sandbox=agent-demo
syscall=connect
resource=network
dst=140.82.113.4:443
decision=deny
policy_rule=network.egress.deny-all
latency_us=19

Brauchen Produktionsaufgaben GitHub-Zugriff, network.egress auf allow-list setzen und github.com:443 ergänzen, validieren, dann openclaw sandbox update --name agent-demo --policy ~/policies/agent-readonly.yaml—Sandbox muss nicht zerstört und neu erstellt werden.

Häufige Abfragen:

• Denys der letzten Stunde: openclaw audit query --decision deny --since 1h
• Nach Pfad filtern: openclaw audit query --resource filesystem --path "/workspace/**"
• JSON-Export für SIEM: openclaw audit export --sandbox agent-demo --since 24h --format json > audit.json

Sechs häufige Fehler und kürzeste Fix-Pfade

Nach dem PoC: Wo sollten Agents langfristig laufen?

Ein Read-only-Sandbox-Nachweis ist nur der Anfang. Reale Workloads rufen vielleicht xcodebuild auf, ziehen von npm/PyPI oder starten pro PR in CI Sandboxes hoch und runter—der Skalierungspfad ist immer Richtlinien aus Deny-Logs iterieren, nicht Berechtigungen raten.

Bei Compute: ein Mac mini M4 · 16 GB kann zwei Build-Sandboxes mit DerivedData parallel fahren und lässt ca. 4 GB für OpenClaw-Audit und Systemdienste. Bei wachsender Last verbindet der JexMac Thunderbolt-5-Cluster-Service mehrere Mac minis mit 80 Gbit/s—jede Instanz behält unabhängige Richtlinien- und Audit-Speicherung.

Fehlt Ihrem Team ein dedizierter Cloud-Mac, haben gängige Alternativen klare Lücken: Agents 24/7 auf einem lokalen MacBook stören den Alltags-Dev und erwärmen die Maschine dauerhaft; GitHub-gehostete macOS-Runner teilen sich einen Pool ohne native OpenClaw-Integration—Spitzen-Warteschlangen treffen interaktive Agents hart; ein eigener Mac mini bedeutet Beschaffungszeit, Colocation und Zertifikatsrotation vor Ort.

JexMac bietet dedizierte physische Mac mini M4 (10 Kerne · 16 GB · 256 GB NVMe · 38 TOPS), OpenClaw in Standardinstanzen integriert, fünf Knoten mit jeweils dedizierter öffentlicher IPv4 und 1 Gbit/s Bandbreite, 1–5 Minuten Lieferung nach Zahlung, ab $21,5/Tag und $107,3/Monat ohne Vertragsbindung. Tagesmiete für Agent-Experimente; nach stabilen Richtlinien auf Monatsmiete wechseln.