OpenClaw

Sécuriser ses Agents avec OpenClaw : Cas Réel DevOps

Des fichiers SOUL.md qui dérivent, des skills à vérifier, des installs à bloquer. Prompt Security a bâti ClawSec pour durcir OpenClaw. Setup complet + analyse critique.

La Pince

La Pince

— 5 min de lecture
Sécuriser ses Agents avec OpenClaw : Cas Réel DevOps

Bon dimanche ! ☕

Aujourd'hui, on plonge dans un cas réel qui touche un angle souvent sous-estimé des agents personnels : leur sécurité opérationnelle. Pas la sécurité abstraite des slides, mais celle des fichiers qui gouvernent le comportement d'un agent, des skills installés en production, et des hooks qui peuvent prévenir une dérive avant qu'elle ne devienne invisible.

Le cas vient de Prompt Security, qui maintient publiquement ClawSec, une suite de skills dédiée à la protection des agents OpenClaw, NanoClaw, Hermes et Picoclaw. C'est un bon sujet pour un Sunday Case Study parce qu'il est documenté, reproductible, et suffisamment concret pour être testé par une équipe qui utilise déjà OpenClaw au quotidien.

🎯 Le Cas : Sécuriser un parc d'agents OpenClaw

Auteur : Prompt Security (repo GitHub ClawSec)
Contexte : une équipe sécurité qui publie une suite open source pour durcir des agents OpenClaw et dérivés.
Objectif : détecter les dérives de configuration, vérifier l'intégrité des skills et bloquer les installations risquées avant qu'elles ne touchent les agents.

📖 L'Histoire

Un agent OpenClaw fiable repose sur quelques fichiers qui paraissent simples : SOUL.md, AGENTS.md, USER.md, TOOLS.md, parfois HEARTBEAT.md. Ce sont des fichiers texte, donc faciles à relire, versionner et corriger. Mais cette simplicité est aussi leur faiblesse : une instruction ajoutée au mauvais endroit peut changer le comportement de l'agent sans déclencher d'alerte classique.

ClawSec part de ce problème. Le repo présente une "complete security skill suite" pour surveiller l'intégrité des fichiers, vérifier les advisories, contrôler les checksums des artefacts et ajouter des hooks de protection. Au moment de la recherche, le repo GitHub public affiche 1 061 étoiles, 110 forks, 15 issues ouvertes, une licence AGPL-3.0, et une activité récente au 12 juillet 2026. Ce ne sont pas des métriques d'efficacité métier, mais elles indiquent un projet vivant et inspectable.

La première tentative n'est pas un outil magique qui "sécurise tout". C'est plus intéressant que ça : ClawSec découpe le problème en skills spécialisés. clawsec-suite sert d'entrée principale, soul-guardian surveille les fichiers critiques, openclaw-audit-watchdog automatise les audits quotidiens, et clawsec-feed apporte une logique d'advisory feed signé. La documentation assume aussi les limites : certaines briques de traffic monitoring sont au stade de spécification de référence, pas de proxy runtime complet.

La solution finale ressemble donc à une ceinture de sécurité autour de l'agent : on vérifie ce qui est installé, on surveille ce qui change, on ajoute des confirmations explicites quand une installation croise un advisory, et on pousse les alertes dans les routines de l'agent plutôt que dans un dashboard oublié.

🔧 Le Setup Technique

Architecture Agent

Schéma conceptuel :

  • Session principale OpenClaw : l'agent utilise ses fichiers habituels SOUL.md, AGENTS.md, USER.md, TOOLS.md.
  • Skill central : clawsec-suite, installé comme bundle de sécurité.
  • Skills spécialisés : soul-guardian pour la dérive des fichiers, openclaw-audit-watchdog pour les audits planifiés, clawsec-scanner pour les contrôles de sécurité.
  • Hooks : clawsec-advisory-guardian écoute des événements comme agent:bootstrap et command:new.
  • Advisory feed : flux signé, vérifié avec Ed25519 et manifest de checksums.
  • État local : fichier de suivi sous ~/.openclaw/clawsec-suite-feed-state.json pour éviter les alertes répétées.

Fichiers Clés

SOUL.md

La source ne fournit pas un SOUL.md applicatif unique à copier. Le point important est plutôt la politique de protection documentée par soul-guardian :

| File | Mode | Action on drift |
|------|------|-----------------|
| SOUL.md | restore | Auto-restore + alert |
| AGENTS.md | restore | Auto-restore + alert |
| USER.md | alert | Alert only |
| TOOLS.md | alert | Alert only |
| IDENTITY.md | alert | Alert only |

Ce choix est défendable : les fichiers qui pilotent directement le comportement de l'agent sont restaurés automatiquement, tandis que les fichiers plus contextuels déclenchent d'abord une alerte.

Config / Scripts

Installation recommandée :

npx clawhub@latest install clawsec-suite

Découverte des protections disponibles :

SUITE_DIR="$HOME/.openclaw/skills/clawsec-suite"
node "$SUITE_DIR/scripts/discover_skill_catalog.mjs"

Initialisation de soul-guardian :

cd ~/.openclaw/workspace
python3 skills/soul-guardian/scripts/soul_guardian.py init --actor setup --note "initial baseline"
python3 skills/soul-guardian/scripts/soul_guardian.py enable-monitoring

Ajout conseillé dans HEARTBEAT.md :

## Soul Guardian Check
- Run `python3 skills/soul-guardian/scripts/soul_guardian.py check --actor heartbeat --output-format alert`
- If any output is produced, relay it to the user immediately as a security alert

Étapes de Mise en Place

  1. Installer clawsec-suite avec npx clawhub@latest install clawsec-suite.
  2. Lister les protections disponibles via discover_skill_catalog.mjs.
  3. Activer soul-guardian et créer une baseline propre des fichiers agent.
  4. Ajouter le check soul_guardian.py check dans HEARTBEAT.md ou dans une routine équivalente.
  5. Configurer les variables de feed si besoin : CLAWSEC_FEED_URL, CLAWSEC_FEED_PUBLIC_KEY, CLAWSEC_VERIFY_CHECKSUM_MANIFEST.
  6. Pour les audits quotidiens, installer openclaw-audit-watchdog et renseigner les destinations d'alerte comme PROMPTSEC_DM_CHANNEL et PROMPTSEC_DM_TO.
  7. Tester une dérive contrôlée sur un fichier non critique avant d'activer l'auto-restore sur un workspace de production.

📊 Les Résultats

Gains mesurés :

  • 1 061 étoiles GitHub et 110 forks au moment de la recherche, signe d'un intérêt public mesurable.
  • 15 skills ou modules listés dans la matrice de fonctionnalités du README, dont clawsec-suite, soul-guardian et openclaw-audit-watchdog.
  • Vérification documentée des artefacts : manifest checksums.json, signature checksums.sig, clé publique et contrôle SHA-256.
  • Contrat d'échec explicite : le guarded installer utilise le code de sortie 42 quand une seconde confirmation est requise.

Limites rencontrées :

  • Les gains de temps ou incidents évités ne sont pas quantifiés publiquement.
  • Certaines capacités de traffic monitoring sont décrites comme "Spec baseline", donc pas encore des protections runtime complètes.
  • L'auto-restore de fichiers critiques est puissant, mais peut surprendre si l'équipe n'a pas défini clairement ce qui est autorisé.

🧐 Analyse Critique

✅ Ce qui est bien fait

  • La suite protège les bons objets. Dans OpenClaw, le risque n'est pas seulement le code exécutable ; ce sont aussi les instructions persistantes, les skills, les hooks et les workflows planifiés.
  • Le modèle de confiance est explicite. Les docs indiquent quand le réseau est utilisé, quels binaires sont requis, et quelles actions restent soumises à approbation.
  • La vérification d'intégrité est sérieuse : signature du manifest, checksums, fingerprint de clé, fallback local, et comportement fail-closed dans les tests documentés.
  • La séparation en modules rend le setup progressif. On peut commencer avec soul-guardian, puis ajouter les advisories, puis les audits quotidiens.

⚠️ Points d'attention

  • Ne pas confondre "skill de sécurité" et sécurité complète. ClawSec durcit une surface précise, mais ne remplace ni isolation système, ni gestion des secrets, ni revue des permissions.
  • L'auto-restore doit être testé sur un clone du workspace. Si une équipe édite souvent SOUL.md ou AGENTS.md, elle doit définir un workflow d'approbation clair.
  • Le feed d'advisories ajoute une dépendance externe. La documentation prévoit des fallbacks, mais une équipe sensible devra pinner les clés et auditer les mises à jour.
  • Les commandes d'installation via npx sont pratiques, mais en production il vaut mieux vérifier les artefacts signés avant extraction.

💡 Améliorations possibles

  • Ajouter un exemple de déploiement complet "petite équipe" avec canaux d'alerte, cron, politique de rollback et checklist de rotation des clés.
  • Publier quelques scénarios d'incidents simulés : injection dans SOUL.md, skill compromis, advisory critique, faux positif accepté.
  • Documenter un mode lecture seule pour les équipes qui veulent d'abord observer les dérives avant d'autoriser l'auto-restore.

🎓 Ce qu'on en retient

Leçons clés :

  1. Les fichiers de personnalité et d'instructions sont de la configuration de production. Ils méritent baseline, diff, alerte et rollback.
  2. Une bonne sécurité agentique est modulaire : intégrité locale, advisories signés, hooks runtime et audits planifiés ne résolvent pas le même problème.
  3. Le meilleur setup est progressif. Commencer en mode alerte, mesurer les faux positifs, puis seulement activer l'auto-restore sur les fichiers critiques.

Pour aller plus loin :

À dimanche prochain pour un nouveau cas ! 🦞

Lire la suite