OpenClaw : listes d’autorisation, appairage et sécurité des mentions de groupe

Les fonctionnalités utiles d’OpenClaw sont précisément la raison pour laquelle le modèle de sécurité compte. La Gateway peut connecter des canaux de messagerie à un agent capable d’exécuter des commandes shell, de lire et d’écrire des fichiers, de piloter un navigateur et d’envoyer des messages. Un scénario de défaillance simple mais à fort impact est celui d’un expéditeur non fiable ou compromis qui atteint un agent trop privilégié ; les contrôles ci-dessous réduisent cette exposition, en complément de la sécurité classique de l’hôte, des dépendances, des identifiants et du réseau.

L’ordre proposé par OpenClaw lui-même est le bon (documentation de sécurité) :

1. L’identité d’abord — qui peut parler au bot (appairage des messages privés / listes d’autorisation / ouverture explicite).
2. Le périmètre ensuite — où il peut agir (groupes, outils, sandbox, permissions d’appareil).
3. Le modèle en dernier — partez du principe que le modèle peut être manipulé ; limitez le rayon d’impact.

Cet article suppose que vous avez déjà installé la passerelle (configuration de la passerelle personnelle).

dmPolicy="open" et groupPolicy="open" sont des réglages de dernier recours. Préférez l’appairage et les listes d’autorisation, sauf si vous faites pleinement confiance à chaque participant qui peut atteindre le bot. Des messages privés ouverts avec outils constituent une surface de contrôle à distance publique.

Chaque expéditeur approuvé peut devenir un chemin vers tout ce que l’agent peut lire : courrier, fichiers, sessions de navigateur, données clients dans les outils. Approuvez les personnes comme vous approuveriez des clés SSH — avec parcimonie, de façon révocable et avec un motif consigné.

Le modèle de confiance en un paragraphe

OpenClaw documente un modèle de confiance d’assistant personnel : une frontière d’opérateur de confiance par passerelle. Ce n’est pas une frontière multilocataire hostile. Si des utilisateurs qui ne se font pas mutuellement confiance peuvent écrire à un agent doté d’outils, ils partagent l’autorité déléguée de cet agent. Scindez les passerelles (et idéalement les comptes de système d’exploitation ou les hôtes) lorsque les frontières de confiance diffèrent.

Un accès authentifié à la Gateway équivaut à un accès opérateur. sessionKey est un sélecteur de routage, pas un jeton d’autorisation. Ne vous inventez pas une fausse impression de cloisonnement par utilisateur sur une passerelle personnelle partagée.

Accès en messages privés : pairing, allowlist, open, disabled

Chaque canal acceptant les messages privés prend en charge une politique dédiée (les noms varient légèrement selon le canal ; consultez la documentation actuelle) :

Approuvez délibérément :

openclaw pairing list <channel>
openclaw pairing approve <channel> <code>

Détails : pairing.

Règle pratique pour un usage personnel : gardez pairing ou une allowlist stricte. Approuvez uniquement vos propres comptes et, au plus, un tout petit groupe de co-opérateurs qui partagent la frontière de confiance.

Deux couches de liste d’autorisation

1. Liste d’autorisation des messages privés (allowFrom / équivalents propres au canal)

Qui peut écrire en privé au bot. Les versions actuelles d’OpenClaw stockent les lignes d’expéditeurs en attente et approuvés dans ~/.openclaw/state/openclaw.sqlite, indexées par canal et par compte. Les anciens fichiers JSON d’identifiants ne sont que des entrées de migration héritées, pas la source d’autorisation actuelle (documentation sur l’emplacement de l’état d’appairage). Traitez ce fichier SQLite comme un état d’autorisation sensible et sauvegardez-le de façon cohérente avec le reste de l’état de la passerelle.

2. Liste d’autorisation de groupe

Quels groupes, canaux ou guildes le bot accepte, tout simplement — et, en plus, qui peut le déclencher à l’intérieur d’un groupe (groupPolicy="allowlist" + groupAllowFrom sur les canaux pris en charge).

L’ordre de contrôle compte : la politique et les listes d’autorisation de groupe d’abord, puis l’activation par mention ou réponse. Répondre à un message du bot ne contourne pas groupAllowFrom.

Exemple de structure (adaptez les identifiants d’expéditeur stables et le nommage des agents au schéma actuel du canal) :

{
  channels: {
    whatsapp: {
      dmPolicy: 'allowlist',
      allowFrom: ['+15555550123'],
      groupPolicy: 'allowlist',
      groupAllowFrom: ['+15555550123'],
      groups: { '<approved-group-id>': { requireMention: true } },
    },
  },
  agents: {
    list: [{ id: 'main', groupChat: { mentionPatterns: ['@openclaw'] } }],
  },
}

Personnalisez les motifs de mention pour que requireMention corresponde aux noms de votre bot, pas à une chaîne générique que tout le monde tape par accident.

Les mentions de groupe sont un contrôle de sécurité

Dans les groupes très actifs, un agent toujours à l’écoute va :

• Consommer des tokens pour du bruit
• Agir sur une injection de prompt enfouie dans des blagues, des journaux collés ou des pages liées
• Laisser fuir du contexte entre des personnes qui partagent un salon mais pas une frontière de confiance

Exigez la mention (ou une activation équivalente), sauf si le salon est un canal dédié à l’agent avec une liste de membres verrouillée.

Même avec un filtrage par mention, le contenu non fiable que le bot récupère (pages web, pièces jointes, e-mails) peut contenir des instructions. L’injection de prompt n’est pas résolue par des prompts système. Les contrôles solides sont la politique d’outils, les approbations, la mise en sandbox et, plus fondamentalement, qui peut parler au bot.

L’injection de prompt n’exige pas des messages privés publics. Si vous seul pouvez écrire au bot, mais que le bot lit le web ouvert ou des boîtes de réception partagées, du texte hostile peut tout de même arriver dans les résultats d’outils.

Isolation de session lorsque plusieurs personnes écrivent en privé

Le comportement par défaut peut router les messages privés vers une session principale pour assurer la continuité. Si plus d’une personne peut écrire en privé au bot, isolez les sessions :

{ session: { dmScope: 'per-channel-peer' } }

Sans isolation, le contexte d’une personne peut déborder sur le tour d’une autre. C’est à la fois un bug de confidentialité et un amplificateur d’injection de prompt.

Exposition réseau

Avant de vous réjouir du chat à distance :

• Préférez gateway.bind: "loopback" pour les installations personnelles
• Exigez des jetons d’authentification de passerelle pour tout accès hors bouclage
• Traitez Tailscale Serve/Funnel et les proxys inverses comme des événements d’exposition — parcourez le guide d’exposition si vous en utilisez un
• Ne publiez jamais le Control UI (:18789) ni les ports de modèle sur l’Internet public sans authentification

Exécutez :

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix   # narrow safe remediations only

Ordre de triage de la documentation : verrouillez d’abord les messages privés et groupes ouverts avec outils, puis l’exposition réseau publique, puis les contrôles distants du navigateur, puis les permissions de fichiers, puis les plugins.

Base durcie (point de départ)

OpenClaw publie un exemple durci compact : liaison locale, authentification par jeton, profil d’outils orienté messagerie, listes de refus pour les groupes automation/runtime/fs, exec refusé avec ask: "always", outils à privilèges élevés désactivés, appairage à la WhatsApp et exigences de mention. Copiez l’intention dans votre configuration depuis la page de sécurité à jour plutôt que de figer à jamais un copier-coller obsolète — puis refaites l’audit.

Les réglages par défaut pour un opérateur unique de confiance peuvent autoriser l’exécution sur l’hôte sans invite (security="full", ask="off"). C’est une ergonomie voulue pour un assistant personnel, pas la preuve qu’il faut la laisser activée lorsque les canaux s’élargissent. Resserrez la configuration dès que votre modèle de menace inclut les messages d’autres personnes.

Questions de revue trimestrielle

Chaque trimestre (ou après tout ajout de canal) :

1. Qui figure sur chaque liste d’autorisation, et pourquoi ?
2. Quels groupes hébergent encore le bot, et exigent-ils encore la mention ?
3. Quelqu’un a-t-il activé une politique open pour les messages privés ou les groupes « temporairement » ?
4. Les outils exec/navigateur sont-ils plus larges que le modèle de menace du trimestre dernier ?
5. openclaw security audit a-t-il été exécuté depuis le dernier changement de configuration ?

Consignez les réponses par écrit. Une posture de sécurité qui n’existe que dans la tête de quelqu’un ne survit pas aux premières vacances.

Notes Discord / Slack / Teams (mêmes principes)

Les interfaces des canaux diffèrent ; les questions de sécurité, non :

• Quelles guildes, quels espaces de travail ou quelles équipes figurent dans la liste d’autorisation ?
• Quels utilisateurs peuvent écrire en privé ?
• Le bot doit-il être @mentionné dans les canaux ?
• Les jetons de bot sont-ils stockés uniquement sur l’hôte de la Gateway ?

Pour Discord et Slack, OpenClaw documente des listes d’autorisation par surface (guilds, channels et clés connexes — confirmez le schéma actuel). Appliquez la même posture « fermé par défaut » que dans les exemples WhatsApp/Telegram. Un espace Slack public avec un agent ouvert et des outils exec est un incident qui n’attend qu’un collègue curieux.

Le chat professionnel contient souvent des données à caractère personnel d’employés et de clients. Connecter OpenClaw à Slack/Teams est une activité de traitement : connaissez la base légale, qui peut invoquer le bot et quelles sorties d’outils sont conservées dans ~/.openclaw.

Histoires d’échec concrètes (des schémas, pas du folklore)

Voici les formes que prennent les incidents :

Politique de messages privés ouverte oubliée

Un jeton de bot fuit dans un dépôt public ou un ami partage l’identifiant public du bot. Des inconnus envoient en privé des prompts du type « résume mon ~/Documents ». Avec les outils activés, le modèle peut essayer.

Groupe sans mention

Le bot réagit à chaque fil. Quelqu’un colle un README malveillant. L’agent le récupère et en suit les instructions.

WhatsApp familial partagé

Adolescents et prestataires partagent un groupe autorisé à mentionner le bot. La continuité de session mélange les contextes. Une blague devient une demande de commande shell.

Interface distante sans authentification

:18789 en écoute sur le LAN « pour que le téléphone puisse y accéder ». Les utilisateurs du Wi-Fi invité obtiennent un plan de contrôle.

Chacune de ces histoires est évitée par l’appairage et les listes d’autorisation, les règles de mention, l’isolation de session et la liaison/authentification — pas par un prompt système plus sévère.

Révocation et retrait des accès

Rédigez un petit guide d’exploitation :

1. Retirez l’identité de allowFrom ou révoquez son entrée d’appairage avec la CLI ou l’interface actuelle ; vérifiez, au moyen de l’outillage pris en charge, que la ligne d’autorisation canonique dans SQLite a bien disparu — n’éditez pas la base de données directement.
2. Effectuez une rotation des jetons de bot du canal si la personne les a vus un jour.
3. Passez en revue les sessions dans ~/.openclaw à la recherche de restes sensibles.
4. Relancez openclaw security audit.
5. Si la personne disposait d’un appairage de nœud, désappairez l’appareil.

Traitez cela comme la récupération d’une clé SSH, pas comme un simple désabonnement d’un bot.

Liste de contrôle opérateur

• La politique de messages privés est pairing ou une allowlist stricte
• allowFrom ne contient que des identités de confiance
• Les groupes exigent la mention ; les listes d’autorisation de groupe sont définies
• dmScope isolé si plusieurs expéditeurs de messages privés existent
• Gateway sur l’interface de bouclage (ou accès distant authentifié uniquement)
• openclaw security audit suffisamment propre pour dormir tranquille
• Outils à haut risque désactivés tant que l’identité n’est pas verrouillée
• Le répertoire d’état n’est pas lisible par tous les utilisateurs
• Étapes de retrait des accès documentées pour vos canaux

Révoquez les entrées d’appairage et de liste d’autorisation lorsqu’un numéro de téléphone, un utilisateur Slack ou une mission de prestataire prend fin. Des lignes de liste d’autorisation oubliées sont des invitations permanentes. Exportez ou supprimez l’historique de session qui contient des données à caractère personnel d’autres personnes lorsque la base légale prend fin.

Les listes d’autorisation et l’appairage ne sont pas de la bureaucratie. Ils font la différence entre une passerelle personnelle et une API d’agent non authentifiée attachée à votre shell. Configurez-les avant les skills, le heartbeat et les automatisations de confort — traités ensuite dans skills, heartbeat et approbations.