OpenClaw : skills, autonomie du heartbeat et portes d’approbation

Une fois OpenClaw installé et l’identité des canaux verrouillée (configuration, listes d’autorisation et appairage), la couche suivante concerne les capacités : skills, tours périodiques du heartbeat, politique d’approbation du shell de l’hôte et activation éventuelle de l’automatisation du navigateur dans un flux de travail examiné.

Documentation de référence : Skills, Heartbeat, Security.

Le heartbeat combiné à un exec sans restriction sur l’hôte, ou l’automatisation d’un navigateur contenant des sessions connectées de valeur, permet des actions sans surveillance au moyen des identifiants et des accès exposés à cette interface. N’activez les tours périodiques qu’après avoir aligné la politique des outils sur votre modèle de menace, surtout si un autre canal que le vôtre peut déclencher l’agent.

Ce que sont les skills

Les skills sont des paquets d’instructions Markdown, composés d’un fichier SKILL.md avec un frontmatter YAML et un corps, qui apprennent à l’agent quand et comment utiliser les outils. OpenClaw charge les skills fournis avec le produit et les surcharges locales, puis les filtre au chargement selon l’environnement, la configuration et la présence des binaires nécessaires.

Ordre de priorité actuel, du plus élevé au plus faible, selon la documentation :

1. Skills de l’espace de travail
2. Skills d’agent du projet
3. Skills d’agent personnels, sous ~/.agents/skills dans la configuration par défaut
4. Skills gérés ou locaux dans le dossier d’état d’OpenClaw
5. Skills fournis avec OpenClaw
6. Dossiers supplémentaires ou skills de plugins

Lorsqu’un même nom de skill apparaît à plusieurs endroits, la source de priorité supérieure l’emporte. Traitez les dossiers de skills comme du code de confiance : toute personne qui peut les modifier peut changer le comportement de l’agent.

Listes d’autorisation des skills visibles par un agent

L’emplacement, qui détermine la priorité, et la visibilité, définie par une liste d’autorisation propre à chaque agent, sont deux notions distinctes. Exemple tiré de la documentation :

{
  agents: {
    defaults: {
      skills: ['github', 'weather'],
    },
    list: [
      { id: 'writer' },
      { id: 'docs', skills: ['docs-search'] },
      { id: 'locked-down', skills: [] },
    ],
  },
}

N’omettez les listes de skills par défaut que si vous souhaitez volontairement une surface étendue. Pour une passerelle personnelle, commencez avec un périmètre étroit : des skills que vous avez lus, qui correspondent aux binaires installés et aux tâches que vous exécutez réellement.

Les skills et plugins communautaires constituent une chaîne d’approvisionnement. Leur installation peut exécuter du code et étendre les outils disponibles. Préférez la documentation officielle et les skills que vous avez examinés ; utilisez security.installPolicy si vous imposez des décisions d’autorisation ou de blocage sur l’hôte sous le contrôle de l’opérateur.

Les skills hébergés sur un nœud n’apparaissent que lorsque le nœud appairé est connecté. Leurs fichiers, les chemins auxquels ils font référence et leurs binaires restent sur ce nœud, et leur exécution utilise exec host=node node=<node-id>. Le premier appairage avec le rôle de nœud autorise la publication des skills ; les modifications ultérieures nécessitent un redémarrage du nœud, pas un nouvel appairage. La politique exec de l’agent et la politique d’approbation locale de l’hôte sur le nœud continuent de gouverner l’exécution.

Heartbeat : un rythme, pas un second cerveau

Le heartbeat exécute des tours périodiques de l’agent dans la session principale pour permettre au modèle de signaler ce qui demande votre attention sans vous envoyer continuellement des messages. Il s’agit d’un tour planifié dans la session principale, pas d’un enregistrement de tâche en arrière-plan.

Valeurs par défaut, à vérifier sur votre version :

• Intervalle souvent réglé sur 30m ; les configurations Anthropic avec OAuth ou jeton peuvent adopter une valeur plus élevée si elle n’est pas définie, et la documentation mentionne 1h dans ce cas
• Définissez agents.defaults.heartbeat.every, avec 0m pour désactiver le heartbeat
• Le prompt par défaut demande à l’agent de suivre le brouillon de surveillance du heartbeat, de ne pas inventer de tâches récurrentes à partir d’anciennes conversations et de répondre HEARTBEAT_OK lorsque rien ne demande votre attention

Exemple :

{
  agents: {
    defaults: {
      heartbeat: {
        every: '30m',
        target: 'none',
        lightContext: true,
        isolatedSession: true,
        // activeHours: { start: "08:00", end: "22:00" },
      },
    },
  },
}

Conseils pratiques :

• Gardez target: "none" tant que vous ne souhaitez aucune livraison ; utilisez target: "last" uniquement lorsque vous acceptez des notifications vers le dernier contact.
• Utilisez activeHours afin que les pulsations nocturnes restent silencieuses dans votre fuseau horaire.
• Placez les tâches récurrentes dans des automatisations ou tâches cron, et non dans des habitudes implicites du brouillon du heartbeat ; la documentation souligne cette séparation.
• Les heartbeats planifiés exigent que les automatisations soient activées. Si cron est désactivé, ils ne s’exécutent pas.

Contrat de réponse : HEARTBEAT_OK, au début ou à la fin, est traité comme un accusé de réception et masqué lorsque le contenu restant est court. Les alertes doivent omettre HEARTBEAT_OK et ne renvoyer que leur texte.

Les tours du heartbeat utilisent toujours tous les outils accessibles à l’agent. Même un « contrôle inoffensif » avec exec autorisé reste une occasion planifiée pour qu’un contenu issu d’une injection de prompt, présent dans la mémoire ou dans des pages récupérées, demande des actions du shell. Associez le heartbeat à des politiques d’outils deny/ask.

Portes d’approbation pour le shell et le navigateur

Le modèle de sécurité d’OpenClaw traite les approbations exec comme des garde-fous de l’intention de l’opérateur, pas comme une isolation mutualisée face à des utilisateurs hostiles. Pour une passerelle personnelle, elles font néanmoins la différence entre « demandez-moi » et « exécutez directement ».

Exec

Contrôles pertinents de la référence actuelle des approbations exec, à confirmer dans le schéma livré avec votre version installée :

• tools.exec.mode est la politique persistante canonique d’exécution sur l’hôte : deny, allowlist, ask, auto ou full.
• auto envoie les demandes absentes de la liste d’autorisation au système natif d’examen d’OpenClaw avant un repli humain. Il s’agit d’un raccourci pratique, pas d’une preuve que la commande est sûre.
• L’exécution sur la Gateway et sur un nœud consulte aussi le document local d’approbations sur l’hôte d’exécution. La politique effective est la plus restrictive entre la configuration et ce document local.
• askFallback s’applique lorsqu’une confirmation est requise, mais qu’aucune interface n’est accessible ou qu’elle expire. Sa valeur par défaut est deny ; conservez-la afin qu’une perte de la route d’approbation n’élargisse pas les accès.
• Les listes d’autorisation sont propres à chaque agent. Utilisez des chemins d’exécutables étroits et argPattern lorsque cela convient ; strictInlineEval apporte une protection supplémentaire lorsque des interpréteurs sont autorisés.
• tools.exec.host: "auto" choisit le sandbox s’il est actif et la Gateway dans le cas contraire. L’exécution sur un nœud exige un nœud appairé et son propre état d’approbation local à l’hôte.

Commencez avec tools.exec.mode: "deny", ou avec mode: "ask" et un document d’approbations local à l’hôte tout aussi restrictif lorsque vous avez besoin de confirmations, tout en laissant les outils élevés désactivés. L’exécution sur l’hôte de la Gateway ou d’un nœud utilise sinon full par défaut, alors que l’exécution dans le sandbox est refusée par défaut. Renforcez la politique de l’hôte avant que les canaux, les skills ou le heartbeat n’élargissent le rayon d’impact.

L’appel system.run sur un Mac appairé constitue une exécution de code à distance sur ce Mac. L’appairage ne vaut pas approbation de chaque commande ; la politique des commandes du nœud dans la Gateway et les propres approbations exec du nœud forment la frontière d’exécution. Pour désactiver le shell distant, réglez le mode exec demandé sur deny et maintenez une politique locale restrictive sur l’hôte du nœud, ou retirez le rôle et l’appairage du nœud si vous n’en avez pas besoin.

Navigateur

Le contrôle du navigateur est une interface de niveau opérateur qui permet de naviguer, de lire des pages et d’évaluer du contenu. Traitez l’exposition distante du navigateur ou de CDP comme un accès opérateur : interface de bouclage ou chemin privé volontairement protégé, jamais de point de terminaison CDP ou de contrôle public. Utilisez le profil de navigateur openclaw dédié, isolé de votre profil quotidien, et gardez le plugin ou l’outil de navigateur désactivé jusqu’à ce qu’une tâche examinée en ait besoin. Les approbations exec ne créent pas une frontière d’approbation clic par clic dans le navigateur. Exigez une confirmation humaine dans le flux de travail avant les envois, achats, publications ou modifications de compte lourds de conséquences.

L’injection de prompt par des pages récupérées constitue un risque majeur. Les politiques d’autorisation ou de refus des outils, l’isolation du profil du navigateur, la confirmation explicite dans le flux de travail et le sandboxing réduisent le rayon d’impact ; ils ne suppriment pas la nécessité des listes d’autorisation des canaux.

Outils élevés

tools.elevated permet de sortir du sandbox. Limitez strictement allowFrom. N’activez pas le mode élevé pour des inconnus ni pour une large population de canaux.

Une échelle d’autonomie raisonnable

Ne passez à l’étape suivante qu’après avoir exécuté openclaw security audit et conservé suffisamment d’exécutions pour éprouver le travail normal, les chemins de refus, l’expiration d’une approbation et la reprise. Un nombre fixe de jours ne prouve pas la sécurité.

Écrire un petit skill interne

Un skill minimal utile est un dossier contenant SKILL.md :

---
name: disk-check
description: Check disk usage on the gateway host when asked about disk or capacity.
---

When the user asks about disk space on this host:

1. Run only the allowlisted `df` invocation your exec policy permits.
2. Summarise filesystem use in three bullets.
3. Do not install packages or delete files.

Gardez la description concrète pour que l’agent sache quand utiliser le skill. Associez-le à un mode exec étroit, à des règles examinées pour les commandes et les arguments de chaque agent, à strictInlineEval ainsi qu’à un sandbox ou à une isolation par le système d’exploitation. Ces contrôles réduisent la surface des commandes, mais ne prouvent pas qu’un interpréteur ou un utilitaire autorisé ne peut rien faire de destructeur. Préférez les skills d’espace de travail que vous contrôlez aux paquets ClawHub choisis uniquement pour leur apparente commodité.

Que placer dans le brouillon du heartbeat, et quoi éviter

Utilisez le brouillon de surveillance du heartbeat (openclaw cron scratch <jobId> --set "...") comme une courte liste de contrôle, pas comme une seconde base de données de tâches :

Bien : « Si le disque dépasse 90 % sur l’hôte de la passerelle, avertir. Sinon, HEARTBEAT_OK. » Mal : « Se rappeler de terminer la feuille de route du troisième trimestre, écrire à Alice, remanier l’agent et extraire les prix des concurrents. »

Les tâches récurrentes doivent vivre dans des automatisations dotées de leur propre planification. Un heartbeat qui réinterprète d’anciennes conversations pour en extraire des tâches transforme une installation silencieuse en système bruyant et coûteux.

Tester les approbations avant de leur faire confiance

1. Réglez tools.exec.mode sur deny pour un test qui refuse par défaut, ou sur ask avec un document d’approbations local à l’hôte au moins aussi restrictif si vous souhaitez une confirmation.
2. Depuis vos messages privés autorisés, demandez à l’agent d’exécuter uname, ou une commande de test inoffensive équivalente.
3. Confirmez que vous obtenez un refus clair ou une demande d’approbation, jamais une réussite silencieuse.
4. Si vous testez les demandes d’approbation, laissez-en une expirer ou rendez l’interface indisponible et confirmez que askFallback: "deny" la bloque. Lorsque la politique de demande effective est always, confirmez que la prochaine commande distincte demande à nouveau une approbation.
5. Si un nœud est appairé, répétez le test avec la politique d’approbation enregistrée séparément sur ce nœud.
6. Depuis une identité absente de la liste d’autorisation, confirmez qu’aucun chemin vers les outils n’existe.

Si l’étape 3 réussit sans le garde-fou configuré, examinez à la fois le mode exec demandé et le document d’approbations local à l’hôte d’exécution avant d’activer le heartbeat.

Associer n8n lorsque la tâche est de la plomberie planifiée

Le heartbeat sert aux contrôles périodiques qui demandent la compréhension de l’agent. Les interrogations SaaS déterministes, les nouvelles tentatives et les validations humaines appartiennent souvent à n8n (idempotence et validations humaines, transfert par API ou webhook Hermes). Utilisez OpenClaw lorsque l’interface est une conversation ; utilisez n8n lorsque l’interface relie des systèmes.

Liste de contrôle de l’opérateur

• Les listes d’autorisation des skills ont été examinées et les skills inutilisés retirés
• Aucun dossier de skills non fiable n’est accessible en écriture à d’autres utilisateurs
• L’intervalle et les heures actives du heartbeat ont été définis volontairement
• La destination du heartbeat n’inonde pas les canaux de groupe
• tools.exec.mode est réglé sur deny ou ask, et le document d’approbations local à l’hôte d’exécution est aussi restrictif ou davantage
• Le navigateur, la recherche et la récupération de pages sont désactivés sauf nécessité
• Les outils élevés sont désactivés
• Le chemin d’approbation a été testé avec une commande inoffensive
• L’audit a été relancé après chaque augmentation de l’autonomie

Les skills rendent l’agent compétent. Le heartbeat lui permet d’intervenir au bon moment. Une politique exec restrictive, une politique de navigateur, le sandboxing et le contrôle de l’identité des canaux réduisent le risque que cette compétence et ce rythme se transforment en actions non surveillées sur l’hôte. Ajustez ces paramètres dans cet ordre et seulement jusqu’au niveau justifié par votre modèle de menace.