Sandbox OpenClaw en pratique : exécuter des tâches d'Agent IA dans un macOS isolé

Agent « nu » vs Agent en sandbox : où se creuse l'écart de permissions

Un développeur humain connecté en SSH sait en général qu'il ne doit pas effacer ~/.ssh ni exporter un certificat Distribution. Un Agent IA ne partage pas cette prudence : les frameworks qui invoquent shell, fichiers et réseau héritent par défaut de l'intégralité des droits de l'utilisateur macOS courant. Un Agent chargé de « parcourir le dépôt, repérer les TODO et produire un rapport Markdown » n'a théoriquement besoin que de lire le projet et d'écrire un fichier de sortie — en pratique, il peut atteindre le trousseau, les cookies du navigateur et n'importe quelle requête HTTP sortante.

La conteneurisation isole les processus, mais sur macOS elle sacrifie la chaîne Xcode complète et les frameworks Apple natifs ; reconstruire une VM à chaque tâche est trop lent pour des boucles Agent interactives. OpenClaw emprunte une troisième voie : sur un macOS réel, des politiques YAML tranchent allow/deny au niveau des appels système, et chaque décision alimente un flux d'audit. L'Agent conserve l'accès au Neural Engine M4 (38 TOPS) pour l'inférence locale, tandis que les lectures et écritures hors politique sont bloquées immédiatement.

La démonstration de cet article reste volontairement étroite : dans la sandbox, lancer une analyse statique sur un instantané de code (rg pour TODO/FIXME), tenter un git clone que la politique refusera, puis écrire le rapport sous /workspace. Critères de réussite : le script se termine, les journaux d'audit affichent à la fois des événements allow et deny, et vous pouvez remonter chaque entrée à la règle YAML correspondante.

Avant de commencer : quatre prérequis à valider d'un coup

Votre poste local peut être Windows, Linux ou macOS — il suffit d'un client SSH. En revanche, l'absence de l'un des quatre éléments ci-dessous bloquera le flux en cours de route.

• Instance JexMac livrée : la section « Informations d'accès » de la console affiche l'adresse et le port SSH. Cinq nœuds — Singapour, Japon (Tokyo), Corée (Séoul), Hong Kong, côte Est des États-Unis — mêmes specs et tarifs ; pour des expérimentations Agent, choisissez la région la plus proche de la latence API visée.
• OpenClaw instance-token : généré lors de la première activation dans « Sécurité et sandbox » de la console, format du type oct-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Affiché une seule fois — stockez-le immédiatement dans 1Password, Bitwarden ou équivalent.
• Répertoire de travail /workspace : créez-le sur l'hôte avant de lancer la sandbox ; ce chemin devient la zone lecture/écriture de l'Agent. N'y placez ni clés privées ni fichiers p12.
• Au moins un YAML de politique : la section 5 fournit un modèle en lecture seule ; le principe est de partir strict, puis d'assouplir en s'appuyant sur les journaux deny — pas de deviner les permissions à l'avance.

Activer OpenClaw dans la console et conserver l'instance-token

OpenClaw n'est pas activé par défaut — chaque instance physique est pilotée indépendamment, afin que les charges sans besoin d'audit n'en supportent pas le surcoût. Trois étapes dans le navigateur ci-dessous ; le reste se fait en SSH.

1. 01
   Détail de l'instance → « Sécurité et sandbox »

   Connectez-vous à la console JexMac, ouvrez l'instance Mac mini cible, repérez l'interrupteur OpenClaw. Si l'instance vient d'être livrée (1–5 minutes), attendez l'état « En cours d'exécution » avant de continuer.

2. 02
   Activer et copier le token

   Cliquez sur Activer ; une fenêtre affiche l'instance-token. Après l'avoir enregistré dans votre gestionnaire de secrets, cliquez sur « J'ai sauvegardé, continuer ». Ne collez jamais le token dans Slack, un ticket ou un commit Git.

3. 03
   Confirmer le badge « Activé »

   Si l'état reste « Activation en cours » plus de 30 secondes, rafraîchissez la page. Une fois le badge vert visible, fermez le navigateur — la CLI prend le relais.

Installation CLI via SSH et contrôle de santé des trois composants

Après connexion SSH à l'instance, le script d'installation détecte automatiquement l'architecture Apple Silicon ; sur M4, comptez en général moins de 30 secondes.

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

openclaw status doit afficher healthy pour les trois composants :

Si un composant est degraded ou unavailable, lancez d'abord openclaw doctor. Cause fréquente : extension système en attente d'approbation — connectez-vous en VNC navigateur, ouvrez « Réglages système → Confidentialité et sécurité », autorisez OpenClaw, puis redémarrez le service CLI depuis SSH. Un Policy Engine healthy signifie seulement que le processus tourne ; cela ne garantit pas un YAML valide, la validation de politique intervient à la section suivante.

Politique de moindre privilège : un YAML versionnable

Le fichier de politique fixe quels chemins l'Agent peut lire, quels processus lancer et si le réseau sortant est autorisé. Workflow recommandé : premier YAML minimal, strictement limité au besoin de la tâche → exécution → lecture des deny → ajout ciblé de règles allow, plutôt qu'un « tout ouvert » qu'on resserre après coup.

Enregistrez le contenu suivant dans ~/policies/agent-readonly.yaml :

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

Trois points de conception : deny prime sur allow — même si /workspace est entièrement inscriptible, les chemins listés en deny restent bloqués ; process.allow est une liste blanche de noms de processus — si l'Agent a besoin de node ou npm, ajoutez-les explicitement, sinon E_POLICY_DENY: process ; egress: deny-all bloque volontairement git clone dans cette démo, pour produire un événement network deny visible dans l'audit.

Avant de créer la sandbox, validez la syntaxe :

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

Sortie attendue : policy valid (0 warnings) ; une faute de champ ou un ancien format v1 renvoie le numéro de ligne concerné.

Créer la sandbox, soumettre la tâche Agent, vérifier le résultat

Avant d'intégrer LangGraph ou un autre framework, nous conseillons de boucler le circuit avec un script shell déterministe — comportement prévisible, et en cas d'erreur vous distinguez « problème de politique » de « logique Agent ».

Sur l'hôte, créez le script d'entrée /workspace/agent-entry.sh :

#!/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

Après chmod +x /workspace/agent-entry.sh, exécutez dans l'ordre :

1. 01
   Créer la sandbox

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

   Statut ready suffit. Un second create avec le même nom signale l'existence sans effacer les données.

2. 02
   Ouvrir une seconde session SSH, suivre l'audit en direct

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

   Les événements de décision apparaissent en général 50–200 ms après l'opération.

3. 03
   Exécuter le script dans la sandbox

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

   Sortie attendue : clone blocked (expected) et écriture du nombre de correspondances dans summary.txt.

4. 04
   Arrêter la sandbox

   openclaw sandbox stop agent-demo

   Les données sous /workspace restent sur l'hôte ; ajoutez --rm pour un nettoyage complet.

Le réseau sortant étant en deny, git clone échoue — c'est voulu pour générer un network deny vérifiable. Si l'étape rg se termine normalement, la configuration filesystem allow est correcte. Sur le nœud Tokyo, nous avons mesuré environ 2,6 s pour l'ensemble du script ; la surcharge de politique reste négligeable.

Champs des journaux d'audit : lire un allow puis un deny

L'audit n'est pas un rapport PDF post-mortem : c'est un flux d'événements synchronisé avec chaque décision de politique. Exemple d'enregistrement allow (lecture du script d'entrée) :

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 pointe vers l'index de la règle YAML déclenchée ; latency_us est la latence de décision en microsecondes. Le network deny correspondant (clone bloqué) :

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

Si la tâche de production doit tirer GitHub, passez network.egress en allow-list avec github.com:443, validez puis exécutez openclaw sandbox update --name agent-demo --policy ~/policies/agent-readonly.yaml — pas besoin de détruire et recréer la sandbox.

Requêtes utiles :

• Deny de la dernière heure : openclaw audit query --decision deny --since 1h
• Filtrer par chemin : openclaw audit query --resource filesystem --path "/workspace/**"
• Export JSON pour SIEM : openclaw audit export --sandbox agent-demo --since 24h --format json > audit.json

Six erreurs fréquentes et la voie de correction la plus courte

Après le PoC : sur quel Mac faire tourner l'Agent au long cours

Valider une sandbox en lecture seule n'est qu'un point de départ. En conditions réelles, l'Agent peut appeler xcodebuild, tirer npm/PyPI, ou voir des sandboxes créées et détruites par PR en CI — la trajectoire d'extension reste la même : itérer la politique à partir des journaux deny, pas deviner les permissions.

Côté capacité, un Mac mini M4 · 16 Go permet en pratique deux sandboxes de build avec DerivedData en parallèle, en laissant environ 4 Go à l'audit OpenClaw et aux services système. Si la charge augmente, le service de parallélisation Thunderbolt 5 de JexMac assemble plusieurs Mac mini en grappe 80 Gbit/s ; politiques et journaux d'audit restent stockés indépendamment par instance.

Sans Mac cloud dédié, les alternatives courantes ont chacune des limites nettes : un MacBook local 24 h/24 perturbe le développement quotidien et chauffe en charge continue ; un Runner macOS hébergé GitHub partage le pool, sans intégration OpenClaw native, et la file d'attente aux heures de pointe pénalise les Agents interactifs ; acheter un Mac mini implique cycle d'achat, hébergement et rotation de certificats sur site.

JexMac fournit un Mac mini M4 physique dédié (10 cœurs · 16 Go · 256 Go NVMe · 38 TOPS), OpenClaw inclus sur l'instance standard, cinq nœuds avec IPv4 publique dédiée et bande passante 1 Gbit/s, livraison en 1–5 minutes après paiement, à partir de $21,5/jour ou $107,3/mois sans engagement. Phase d'expérimentation Agent à la journée ; basculez au mois une fois les politiques stabilisées.