Sandbox OpenClaw en 5 minutes : offrez un Mac cloud isolé à votre Agent IA

Première question : pourquoi ne pas laisser les Agents tourner directement sur macOS nu ?

Beaucoup d'équipes commencent par : « C'est juste un test — on se connecte en SSH au Mac cloud et on laisse l'Agent travailler. » Le problème : les frameworks Agent modernes (LangGraph, AutoGen, Cursor Background Agent et similaires) exécutent les appels d'outils en tant qu'utilisateur courant — lectures de fichiers, processus enfants, réseau : les mêmes limites que votre propre session terminal. Lors d'un pilote interne, nous avons demandé à un Agent de scanner un dépôt Swift et de corriger automatiquement les avertissements de compilation ; à la troisième itération, il a tenté de lire ~/Library/Keychains et d'exécuter security find-identity pour « aider à trouver les certificats de signature ». Intention compréhensible — catastrophique sur une machine de build contenant des certificats Distribution.

Changer de compte ou réinstaller après chaque tâche coûte cher ; Docker sur macOS ne couvre pas toute la chaîne Xcode. L'approche OpenClaw : l'Agent tourne toujours sur un vrai macOS (xcodebuild et Apple Neural Engine fonctionnent), mais chaque appel système passe d'abord par un moteur de politique — refus en cas de violation, tout est journalisé. Pour les équipes soumises au RGPD ou à des politiques de sécurité internes, c'est crucial : vous pouvez prouver quels chemins l'Agent a touchés et quelles actions ont été bloquées, sans mettre hors ligne tout le nœud de build. Cet article ne couvre que le chemin le plus court de zéro à une tâche sandbox fonctionnelle ; architecture, zero trust multi-utilisateurs et câblage CI sont dans le guide complet OpenClaw.

Avant de commencer : trois éléments à préparer

Pas besoin de Mac local — un portable Windows ou Linux avec SSH suffit. Confirmez ces trois points avant de démarrer, sinon vous bloquerez en cours de route :

Nœud cloud : sans instance, choisissez région et durée sur la page de commande. Les cinq nœuds (Singapour, Japon Tokyo, Corée du Sud Séoul, Hong Kong, États-Unis Est) ont le même matériel et les mêmes tarifs — choisissez selon la latence. Depuis l'Europe, Singapour ou États-Unis Est conviennent souvent pour les tests SSH.
instance-token : généré la première fois que vous activez OpenClaw dans « Sécurité et sandbox » de la console ; affiché une seule fois — stockez-le immédiatement dans votre coffre de secrets d'équipe.
Fichier de politique : la section 4 fournit un modèle copier-coller orienté lecture ; enregistrez-le sous ~/policies/quickstart-readonly.yaml.

Flux en 5 minutes : de l'activation à la première tâche sandbox

Les durées ci-dessous reflètent nos mesures. Cinq répétitions sur un nœud Singapour : une fois rodé, le parcours complet prend environ 4 minutes 20. Prévoyez 5–8 minutes au premier essai. Chaque étape a un critère de validation clair — n'avancez pas tant que la sortie attendue n'apparaît pas.

1. 01
   Minute 1 : activer OpenClaw dans la console

   Connexion à la console PixVPS → détails de l'instance → « Sécurité et sandbox » → activer OpenClaw. Copiez l'instance-token dans 1Password ou Bitwarden. Terminé quand : la page affiche OpenClaw comme activé.

2. 02
   Minute 2 : SSH et installation de la CLI

   Copiez la commande SSH depuis « Informations d'accès » dans la console, connectez-vous, puis exécutez le script d'installation et l'authentification. Terminé quand : openclaw status affiche Policy Engine, Sandbox Runtime et Audit Bus tous healthy.

3. 03
   Minute 3 : rédiger la politique lecture seule minimale

   Créez ~/policies/, collez le YAML de la section 4. Exécutez openclaw policy validate -f ~/policies/quickstart-readonly.yaml pour vérifier la syntaxe. Terminé quand : sortie policy valid sans avertissement de conflit de chemins.

4. 04
   Minute 4 : créer la sandbox et sonder

   openclaw sandbox create --name quickstart --policy ~/policies/quickstart-readonly.yaml, puis openclaw sandbox exec quickstart -- /bin/zsh -lc 'ls -la /workspace'. Terminé quand : listing du répertoire workspace vide visible dans la sandbox, sans erreur de permission.

5. 05
   Minute 5 : exécuter l'entrée Agent et suivre l'audit

   Exécutez votre entrée Agent (ou le script exemple ci-dessous) dans la sandbox. Dans un second terminal, lancez openclaw audit tail --sandbox quickstart --follow pour les logs en direct. À la fin, openclaw sandbox stop quickstart. Terminé quand : les journaux d'audit contiennent decision: allow et decision: deny (si l'Agent a touché des chemins bloqués).

YAML de permissions minimal : modèle de scan de code en lecture seule

Règle du quickstart : commencer strict, assouplir ensuite. La première politique n'expose que ce dont l'Agent a besoin. Le modèle ci-dessous autorise lecture/écriture sur /workspace, exécute git / rg / python3, bloque les chemins keychain et SSH, et refuse tout réseau sortant — suffisant pour « cloner un dépôt public → scan statique → écrire un rapport ».

Note : /workspace inclut l'écriture car l'Agent doit persister le rapport de scan ; pour des tâches purement en lecture, passez access à [read]. Pour récupérer du code depuis GitHub, basculez network.egress en allow-list et ajoutez github.com:443 — l'« étape deux » la plus courante après le quickstart. Les modèles complets de liste blanche réseau sont dans la section 5 du guide complet.

Exécuter la première tâche Agent : script d'entrée copier-coller

Avant de câbler LangGraph ou un orchestrateur maison, validez la boucle « politique + sandbox + audit » avec un script shell d'une vingtaine de lignes. Enregistrez ce qui suit sous /workspace/agent-entry.sh sur l'hôte (le répertoire est automatiquement mappé dans la sandbox) :

Avec egress: deny-all toujours actif, git clone sera bloqué par la politique réseau — c'est voulu pour la démo : suivez l'audit et vous verrez un enregistrement réseau decision: deny. Ajoutez GitHub à la liste blanche et relancez ; vous devriez voir decision: allow et un summary.txt réussi.

Exécution : openclaw sandbox exec quickstart -- /bin/zsh /workspace/agent-entry.sh. Sur notre nœud M4, le script (clone inclus) a pris environ 38 secondes ; la surcharge cumulée d'évaluation de politique reste sous 200 ms — négligeable. Ensuite, openclaw sandbox stop quickstart pour libérer l'espace ; les sandboxes zombies consomment du disque — la limite par défaut est de cinq sessions simultanées par instance. Pour archiver les journaux, openclaw audit export --sandbox quickstart --format jsonl exporte vers un fichier — utile pour les audits de conformité ou les pièces jointes de tickets.

Trois blocages courants et correctifs en une ligne

Presque tout le monde en touche un au premier run. Pas besoin d'un long manuel — le tableau suffit.

Après le pilote : élargir les permissions et monter en charge à votre rythme

Une sandbox lecture seule en cinq minutes n'est qu'un point de départ. Les charges réelles exigent souvent xcodebuild, l'accès au registre npm, et une sandbox fraîche à chaque push CI. C'est le territoire « pilote vers production » — politiques plus fines et export d'audit — traité chapitre par chapitre dans le guide complet OpenClaw (YAML de permissions avancé, câblage GitHub Actions et rétention d'audit 90 jours).

Sans Mac cloud encore : chaque alternative a ses limites — un portable local avec Agents 24/7 consomme de l'énergie et n'offre pas d'IP fixe à l'étranger ; les VM macOS cloud publiques manquent d'intégration OpenClaw native et d'audit au niveau des opérations ; acheter des Mac mini de bureau implique amortissement matériel et charge ops. PixVPS propose des Mac mini M4 physiques dédiés (16 Go mémoire unifiée, 38 TOPS, 1 Gbps bande passante dédiée), OpenClaw intégré sur chaque instance standard, livraison en 1–5 minutes, à partir de $21.1/jour — louez à la journée pour les expérimentations Agent, passez à $105.7/mois une fois stabilisé, plus souple qu'acheter du matériel pour une demande incertaine.

Parcours recommandé : faire tourner la sandbox lecture seule aujourd'hui → demain copier un modèle de politique pour votre type de tâche (build / récupération doc / patrouille ops — tableau comparatif dans le guide complet) → semaine trois, committer le YAML dans Git et imposer openclaw audit export en CI. Pour des Agents de build en parallèle : un M4 16 Go fait tourner de façon fiable deux sandboxes avec DerivedData dans nos tests ; pour plus de parallélisme, ajoutez le clustering Thunderbolt 5 pour un pool multi-machines à 80 Gbps. Questions sur la mise en place : [email protected] — réponse sous une heure, 7×24.