Architecture et contrôles de sécurité de la passerelle OpenClaw

OpenClaw arrive avec des valeurs par défaut prudentes : sur un hôte ordinaire, la passerelle écoute en boucle locale, la plupart des canaux répondent à un expéditeur inconnu par un code d’appairage au lieu de traiter le message, et une commande d’audit de sécurité signale ce que vous avez desserré. La documentation organise le reste autour d’une idée, une frontière de confiance par passerelle, et d’une matrice qui dit ce que signifie chaque contrôle. Voici l’architecture telle que les pages de sécurité la décrivent, contrôle par contrôle, avec les contresens que la documentation ferme explicitement.

Une frontière de confiance par passerelle

Pris en charge : un opérateur unique, ou une équipe dont les membres se font confiance, idéalement un utilisateur système, un hôte ou un VPS par frontière. Non pris en charge : une passerelle partagée par des utilisateurs qui ne se font pas confiance. Quiconque peut écrire à un agent doté d’outils partage l’autorité d’outils déléguée de cet agent, les outils de session traversent toute la passerelle par défaut, et quiconque peut modifier la configuration de l’hôte est un opérateur de confiance. Pour des utilisateurs adverses, la réponse est des passerelles séparées, pas des réglages.

La plupart des défaillances ici ne sont pas des exploits exotiques : c’est « quelqu’un a écrit au bot et le bot a fait ce qu’on lui demandait ».

Les contrôles, dans l’ordre de la documentation

• L’identité d’abord : qui peut parler au bot. Appairage des messages directs, listes d’autorisation, ou une politique ouverte explicite.
• La portée ensuite : où le bot peut agir. Listes de groupes autorisés et filtrage par mention, politique d’outils, bac à sable, permissions des appareils.
• L’exposition réseau : un port pour WebSocket et HTTP, en boucle locale par défaut ; une écoute sur le réseau local, un tailnet ou une adresse personnalisée élargit la surface et exige l’authentification de la passerelle et un vrai pare-feu. La documentation préfère Tailscale Serve à une écoute sur le réseau local.
• L’authentification de la passerelle : un jeton, un mot de passe, un proxy de confiance ou une authentification d’appareil authentifient les appelants des API de la passerelle ; la clé de session est un sélecteur de routage, jamais un jeton d’autorisation.
• La découverte : l’extension Bonjour annonce la présence sur le réseau local quand elle est activée ; laissez-la désactivée sauf besoin, et en mode minimal quand elle est active.
• Docker : les ports de conteneur publiés contournent les règles d’entrée de l’hôte, filtrez-les donc dans la chaîne utilisateur de Docker, IPv6 compris.

Ce que la documentation refuse d’appeler une vulnérabilité

La page du modèle de confiance tient une liste de constats classés sans suite, et elle est instructive : des chaînes d’injection d’invite sans contournement de politique, d’authentification ou de bac à sable ; des allégations qui supposent une multi-location hostile sur un seul hôte ; l’accès en lecture d’un opérateur aux sessions classé comme faille d’accès ; des constats limités à localhost ; la clé de session traitée comme autorisation utilisateur ; la visibilité des sessions entre agents, par défaut, traitée comme contournement d’isolation. Chacun est une frontière que le logiciel n’a jamais revendiquée.

Passerelle et nœud

La passerelle et le nœud forment un seul domaine de confiance d’opérateur avec des rôles différents : la passerelle est le plan de contrôle et la surface de politique, le nœud est une surface d’exécution distante qui lui est appairée, et un appelant authentifié auprès de la passerelle est de confiance à l’échelle de la passerelle. Les approbations d’exécution sont des garde-fous pour l’intention de l’opérateur, pas une isolation entre locataires, et la valeur par défaut pour un opérateur unique de confiance autorise l’exécution sur l’hôte sans invite, à dessein. Nœuds OpenClaw et Remote Hands couvre l’appairage et Bac à sable, politique d’outils et mode élevé les couches de politique.

Sur Diali

Diali applique exactement la forme prise en charge, une passerelle par frontière : chaque assistant est sa propre instance, avec son propre bac à sable au niveau du noyau, son espace de noms et sa politique réseau, sans port public et avec un accès sortant limité au web public, jamais à notre réseau interne, au serveur de métadonnées du cloud ni aux autres locataires, si bien que le chapitre sur l’exposition réseau est réglé par la plateforme et que les chapitres sur l’identité et la portée restent dans votre tableau de bord. La sécurité sur Diali est la page de la frontière ; Bonnes pratiques de sécurité OpenClaw est la configuration recommandée par la documentation, expliquée.

• Une frontière par passerelle ; les adversaires ont la leur.
• L’identité d’abord, la portée ensuite, l’exposition en dernier.
• La clé de session route ; elle n’autorise jamais.