2026 OpenClaw — sécurité passerelle : Mac distant, jetons, limites de sortie et journaux d'audit

Verrouillez le runtime avant tout durcissement. La passerelle et la CLI OpenClaw supposent une ligne Node LTS récente (beaucoup d'équipes sont passées à Node 22+ en 2026). Sur le Mac distant, vérifiez avec node -v et npm -v, et installez via nvm ou le paquet officiel pour des mises à jour reproductibles.

Créez un utilisateur macOS dédié (par ex. openclawsvc) propriétaire du répertoire d'installation et des chemins de journaux. Évitez la passerelle sur un compte admin avec sudo sans mot de passe : un jeton fuité devient alors un accès disque complet. Contrôlez les droits effectifs :

id openclawsvc
ls -la ~/openclaw-gateway
chmod 750 ~/openclaw-gateway
chmod 600 ~/openclaw-gateway/.env.gateway

Accordez les autorisations de confidentialité macOS (TCC) uniquement là où une compétence l'exige. Si une compétence appelle des outils d'automatisation, documentez les invites ; n'activez pas « Accès disque complet » par défaut pour gagner du temps. Pour launchd, utilisez la clé UserName dans le plist pour abandonner les privilèges explicitement.

Votre première décision « plan de contrôle » est l'exposition réseau. Liez la passerelle à la boucle locale et placez un reverse proxy devant, ou à une interface privée uniquement. Schéma courant sur Mac distant : OpenClaw écoute 127.0.0.1:PORT ; Caddy ou nginx termine le TLS et proxifie vers ce port, avec filtrage IP optionnel.

Activez l'authentification bearer sur le chemin utilisé par la CI et les clients. Stockez le jeton dans .env.gateway (droits 600) et référencez-le depuis launchd :

export OPENCLAW_GATEWAY_TOKEN="$(openssl rand -hex 32)"
# bloc EnvironmentVariables launchd :
# OPENCLAW_GATEWAY_TOKEN = <valeur depuis le coffre-fort secrets>

Depuis GitHub Actions ou une autre CI, injectez le jeton via secrets chiffrés — ne l'affichez jamais dans les journaux de workflow. Ajoutez une étape garde-fou qui échoue si grep -R "OPENCLAW_GATEWAY_TOKEN" . trouverait du texte en clair dans les fichiers suivis.

Fragment illustratif openclaw.json (adaptez les clés à votre version OpenClaw) :

{
  "gateway": {
    "listen": { "host": "127.0.0.1", "port": 18765 },
    "auth": { "mode": "bearer", "header": "Authorization" },
    "rateLimit": { "perMinute": 120 }
  }
}

Combinez le bearer avec VPN uniquement ou tunnel SSH (ssh -L 18765:127.0.0.1:18765 utilisateur@mac-distant) et des règles pare-feu « tout refuser » par défaut sur l'entrant.

Les agents amplifient le risque SSRF si chaque compétence peut appeler n'importe quelle URL. Partez d'une allowlist écrite des hôtes réellement nécessaires, puis appliquez-la en couches.

Définissez les variables proxy une fois pour le compte de service et l'environnement launchd :

export HTTPS_PROXY="http://proxy.corp.example:8080"
export NO_PROXY="127.0.0.1,localhost,.internal.corp,artifacts.internal"

Sans proxy central, combinez règles de pare-feu macOS et compétences versionnées pour que toute modification de sortie passe par revue.

Les journaux structurés battent les captures d'écran. Redirigez stdout/stderr de la passerelle vers des fichiers datés sous /var/log/openclaw/ (propriété du compte de service) ou utilisez StandardOutPath / StandardErrorPath dans launchd. Faites tourner avec newsyslog ou une petite config logrotate pour éviter de remplir le disque pendant les pulls de modèles.

Surveillance minimale viable sur un nœud Mac distant :

Expédiez vers un SIEM si possible ; sinon un cron + grep -E "401|403|EACCES|certificate|handshake" vaut mieux qu'un silence radio.

Après chaque changement, exécutez votre commande de santé habituelle (par ex. openclaw doctor si disponible) et un curl -sf -H "Authorization: Bearer $TOKEN" http://127.0.0.1:18765/health local avant d'ouvrir l'écoute du proxy.