Guide complet OpenClaw : sandbox AI Agent sur Mac cloud, du démarrage à la production

Pourquoi les AI Agents ont besoin de sandbox au niveau opérationnel

Les agents pilotés par LLM ne se limitent plus à quelques lignes d'autocomplétion : ils lisent et écrivent des fichiers, invoquent des terminaux, tirent des dépendances et appellent des API externes. Sur macOS, Xcode, la signature de code et l'inférence on-device via Apple Neural Engine restent souvent nécessaires ; les conteneurs Linux ne fournissent pas cette pile, tandis qu'un agent « nu » sur le MacBook du quotidien partage le même plan de permissions que vos clés SSH, le trousseau et le stockage global de l'IDE.

OpenClaw est la couche sandbox de ZovCloud sur du matériel Mac mini M4 physique dédié : chaque tâche obtient des limites configurables, traçables et stoppables tout en conservant les capacités macOS natives. Au lieu de céder la machine entière, chaque session sandbox emporte ses propres politiques et flux d'audit — les Owner peuvent révoquer les jetons et arrêter les jobs actifs à tout moment.

Cet article couvre tout, de la première session solo à « équipe + CI production ». À la fin, vous devriez pouvoir : provisionner un nœud → initialiser OpenClaw → rédiger une policy YAML → attribuer des rôles → lancer des sessions de revue isolées dans GitHub Actions → interroger et exporter les journaux d'audit.

Prérequis : nœud, réseau et attentes de permissions

OpenClaw tourne sur du matériel physique dédié ZovCloud — ce n'est pas une licence logicielle autonome. Il vous faut d'abord un nœud Mac mini M4 livré. Sur la page de commande, choisissez l'une des cinq régions (Singapour, Japon (Tokyo), Corée (Séoul), Hong Kong, Côte Est US) ; forfaits de base à partir de $19.8/jour, provisionnement en 1–5 minutes après paiement, identifiants SSH et VNC envoyés par e-mail.

La première initialisation demande l'autorisation macOS Endpoint Security (audit fichiers et processus) ainsi que les droits d'extension de filtre réseau. Si votre réseau d'entreprise utilise des proxys sortants, vérifiez que les domaines API de l'agent sont joignables ou préremplissez une liste blanche dans la policy YAML. En équipe, faites terminer l'initialisation par l'Owner avant d'inviter Operator et Auditor — plusieurs dialogues ES simultanés créent de la confusion.

Initialisation console : de l'instance au premier claw status

1. 01
   Connectez-vous à la console et ouvrez les détails de l'instance

   Sous Mes instances, sélectionnez le Mac mini M4 cible et vérifiez qu'il est en cours d'exécution. Sur un nœud neuf, connectez-vous d'abord en SSH pour valider disque et réseau.

2. 02
   Ouvrez l'onglet OpenClaw et lancez l'initialisation zéro confiance

   La première visite génère une paire de clés Ed25519, installe le service com.zovcloud.openclaw.daemon et crée /var/log/openclaw/ pour les audits. Approuvez ES et l'extension réseau selon les invites.

3. 03
   Configurez les membres et les politiques d'accès

   Sous Contrôle d'accès, ajoutez des collaborateurs et assignez les rôles Owner / Operator / Auditor. Les Operator démarrent des sessions sandbox ; les Auditor consultent uniquement les journaux d'audit — pas d'édition de politique.

4. 04
   Téléchargez le bundle CLI et le jeton, puis vérifiez

   La console fournit un script d'installation en une ligne. En SSH sur le nœud, exécutez claw status — attendu : daemon: running et auth: valid. Sinon, lancez d'abord claw doctor.

Après initialisation, le tableau de bord affiche le nombre de sessions actives, l'utilisation CPU/RAM par session, les événements BLOCK des dernières 24 heures, et peut exporter des résumés de conformité PDF pour les revues sécurité. Configurez des alertes sur les pics BLOCK pour éviter qu'une politique trop permissive passe inaperçue.

Groupes de commandes CLI et rythme d'exploitation quotidien

Le quotidien tourne autour de claw. Regrouper par responsabilité facilite le scripting :

# Contrôles de santé
claw status
claw doctor

# Cycle de vie des sessions
claw run --config policy.yaml
claw run --template ci-review --detach
claw attach <session-id>
claw stop <session-id>
claw list

# Modèles de politique
claw template list
claw template export agent > policy.yaml
claw template save my-ci-policy

# Audit et tests réseau
claw audit tail <session> --follow
claw audit query --since 24h --action BLOCK
claw audit export <session> --format json
claw net test --domain api.openai.com

Intégrez claw doctor aux contrôles de routine : santé du démon, autorisation Endpoint Security, écriture du répertoire d'audit, expiration du jeton. Si le démarrage sandbox échoue avec des erreurs vagues, diagnostiquez d'abord — causes fréquentes : approbation ES expirée ou chemin workspace manquant.

En production, séparez les modèles CI et tâches humaines : ci-review plutôt en lecture seule avec une liste blanche réseau étroite ; agent-dev autorise l'écriture sur workspace et DerivedData mais refuse toujours ~/.ssh et les chemins Keychain.

policy.yaml production : champs et pièges

Le fichier de politique est la source unique de vérité des limites sandbox. Ci-dessous une configuration complète courante pour les agents en production, avec notes par section :

version: "1"
session:
  name: "prod-agent"
  auto_cleanup: false
  max_duration: "4h"
  idle_timeout: "30m"

filesystem:
  workspace: "~/agent-workspace"
  readonly_mounts:
    - /Applications
    - /usr/local/bin
    - /Library/Developer
  deny:
    - ~/.ssh
    - ~/Library/Keychains
    - ~/Library/Application Support/Cursor/User/globalStorage

syscalls:
  preset: "agent"
  deny: [ptrace, setuid, mount]

network:
  allow_domains:
    - "api.openai.com"
    - "api.anthropic.com"
    - "*.github.com"
    - "registry.npmjs.org"
    - "pypi.org"
  block_all_others: true
  log_blocked: true

Le bloc session pilote le cycle de vie : max_duration empêche les jobs sans surveillance de retenir 16 Go de RAM indéfiniment ; idle_timeout libère les ressources après inactivité de l'agent ; auto_cleanup: false convient aux tâches de génération de code où il faut conserver les artefacts.

Dans filesystem, deny l'emporte sur readonly_mounts. OpenClaw résout les cibles des liens symboliques — si les outils Homebrew pointent vers Cellar, ajoutez Cellar aux readonly_mounts sinon git / python3 échouent silencieusement.

Pour network, gardez block_all_others: true et activez log_blocked: true : la sortie non autorisée est rejetée, mais le flux d'audit enregistre les tentatives vers des domaines inconnus.

Zéro confiance multi-utilisateur : rôles, jetons et limites de collaboration

En équipe, assignez trois rôles selon le moindre privilège. Chaque rôle s'authentifie avec son jeton CLI (TTL par défaut 24 h) ; les Owner peuvent révoquer les jetons et tuer les sessions actives correspondantes. Pour les consultants externes, des jetons Guest à durée limitée — ils expirent sans toucher au fichier de politique maître.

Ici, zéro confiance signifie que chaque appel CLI porte un jeton éphémère ; les changements de politique et actions à haut risque (élargir la liste blanche réseau) sont réservés aux Owner, et chaque événement ALLOW/BLOCK atterrit dans un flux d'audit à détection de falsification. Ne placez pas les jetons Owner dans les coffres de secrets CI — créez des jetons Operator limités au template ci-review pour les pipelines.

Intégration GitHub Actions : une session sandbox par PR

Après enregistrement de votre ZovCloud M4 comme runner auto-hébergé, vous pouvez lancer une sandbox isolée pour chaque revue de code IA dans un pipeline PR. Schéma : démarrer session → exécuter l'agent dans la sandbox → exporter l'audit quel que soit le résultat → arrêter la session.

# .github/workflows/ai-review.yml
name: AI Code Review (Sandboxed)
on: [pull_request]

jobs:
  review:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4

      - name: Start OpenClaw sandbox
        run: |
          claw run --template ci-review --detach
          SESSION=$(claw list --json | jq -r '.[0].id')
          echo "SESSION_ID=$SESSION" >> $GITHUB_ENV

      - name: Run AI review agent
        run: |
          claw attach $SESSION_ID --exec \
            "claude -p 'Review this PR for security issues'"

      - name: Export audit log
        if: always()
        run: |
          claw audit export $SESSION_ID \
            --format json \
            --output audit-${{ github.run_id }}.json

      - name: Stop sandbox
        if: always()
        run: claw stop $SESSION_ID

Versionnez le YAML du template ci-review sous .openclaw/ dans le dépôt, avec le workflow — les changements de politique passent par Code Review pour que la sécurité inspecte les limites effectives. Si plusieurs projets partagent un nœud, enregistrez des labels Runner différents par dépôt, ou utilisez OpenClaw pour borner la portée filesystem de chaque session.

Journaux d'audit, alertes et dépannage courant

Pour investiguer une anomalie, filtrez le flux d'audit par temps et type :

claw audit query --since 7d --action BLOCK --type network --format table

claw audit query --since 24h --action BLOCK --type write --format json \
  | jq '.[] | select(.target | contains("/etc"))'

Les exports conformité prennent en charge JSON, CSV et PDF. Les PDF incluent résumés de session, stats ALLOW/BLOCK, instantanés de politique et chronologies — prêts pour les auditeurs. La console peut alerter sur des règles comme « BLOCK > 50 par heure dans une session » ou « tentative de lecture de ~/.ssh », avec notification Owner par e-mail ou Webhook.

L'audit complet coûte ~3 % CPU sur M4 dix cœurs — négligeable pour la plupart des charges. Les cas edge sensibles à la latence peuvent retirer l'audit syscall fin et ne garder que fichiers/réseau ; en production, préférez l'audit complet. Checklist avant mise en service : une session par tâche ; policy YAML dans Git avec revue ; ~/.ssh, Keychain et stockage global IDE toujours refusés ; réseau en refus par défaut avec liste blanche explicite ; définir max_duration et idle_timeout ; exporter l'audit en CI avec if: always() ; configurer les alertes BLOCK.

Quand faire tourner OpenClaw sur un Mac cloud dédié plutôt qu'en local

Agent nu sur MacBook : mêmes privilèges que la machine du quotidien, pas d'audit au niveau opérationnel, swap sur machines 8 Go lors de jobs longs, CI 7×24 difficile. Les instances macOS cloud publiques sont souvent virtualisées — pas de passthrough Neural Engine ni sandbox intégrée, et des minimums contractuels ou tarifs à la minute peuvent dépasser du matériel physique journalier flexible. Les runners macOS GitHub Actions facturent à la minute, environnements partagés, peu de contrôle de politique, files d'attente aux heures de pointe.

ZovCloud propose du Mac mini M4 physique dédié ($19.8/jour, $53.5/semaine, $99.1/mois dès), OpenClaw intégré, cinq régions avec livraison en 1–5 minutes et support humain 7×24 — les flux collaboration, CI et audit de ce guide supposent cette pile clé en main. Votre portable est saturé ? Louez à la journée à Singapour ou au Japon (Tokyo), exécutez le même dépôt et la même tâche agent, comparez exhaustivité d'audit et temps de fin, puis décidez si les pipelines de revue doivent vivre dans le cloud.

À la fin de location ou en cas de résiliation, ZovCloud efface le disque de façon sécurisée ; avant de libérer le nœud, archivez les journaux avec claw audit export vers un stockage objet pour que les preuves de conformité ne disparaissent pas avec l'instance. Pour un premier pas léger : démarrage en cinq minutes, puis étendez vers équipe et CI avec ce guide.