OpenClaw 2026.9.2 modifie un réglage important pour les déploiements multi-agents. L’accès ordinaire d’un agent aux sessions des autres est désormais actif par défaut, les outils de session voient l’ensemble du Gateway et la fonction expérimentale Swarm est elle aussi activée par défaut.
Il ne s’agit pas d’un contournement de sécurité découvert après coup. OpenClaw présente explicitement un Gateway comme une seule zone de confiance et déconseille de le partager entre utilisateurs qui ne se font pas confiance. La nouveauté reste néanmoins importante pour les équipes qui avaient assimilé des agents ou des profils distincts à des frontières de confidentialité.
Les sessions sont partagées à l’échelle du Gateway par défaut
La version publiée le 5 septembre indique que les outils de session utilisent désormais une visibilité globale et que les échanges ordinaires entre agents sont activés. La documentation de sécurité précise les valeurs : tools.sessions.visibility vaut all par défaut et tools.agentToAgent.enabled vaut true.
Dans cette configuration, un agent non isolé qui dispose des outils de session peut, selon OpenClaw, lister, lire, rechercher et contacter les sessions de tous les agents, y compris des conversations d’autres utilisateurs. Un agent exécuté dans un environnement isolé reste limité, lorsqu’il agit lui-même, à l’arbre de sessions qu’il a créé. En revanche, cette isolation n’empêche pas un agent non isolé de lire ses transcriptions.
Le projet ne présente pas ce fonctionnement comme une isolation entre locataires. Un opérateur authentifié dans un Gateway appartient au domaine de confiance. Lorsque plusieurs niveaux de confiance doivent coexister, OpenClaw recommande des Gateways et des identifiants distincts, idéalement avec des comptes système ou des hôtes séparés.
Il serait donc trompeur de qualifier ce comportement de faille d’autorisation. La question utile est plutôt de savoir si l’organisation réelle des accès correspond au domaine de confiance supposé par le Gateway.
Swarm augmente la capacité d’orchestration sans accorder de nouveaux outils
La même version active Swarm par défaut. Cette fonction expérimentale permet de répartir du travail entre plusieurs sous-agents en parallèle, de récupérer des résultats structurés et de suivre leur progression tout en imposant des limites de concurrence.
Plusieurs garde-fous restent en place. Code Mode doit toujours être activé séparément. Les règles sur les outils, listes d’autorisation, fournisseurs et environnements isolés continuent de s’appliquer. Activer Swarm ne donne pas accès à un outil auparavant interdit. Les sous-agents de collecte refusent aussi une action lorsqu’elle nécessiterait une approbation interactive de l’opérateur.
Les deux évolutions concernent donc des couches différentes. Swarm détermine comment le travail peut être distribué. La visibilité des sessions détermine quelles conversations et quel contexte un agent peut atteindre. Leur combinaison oblige à réfléchir plus explicitement à la structure de confiance d’un système multi-agents.
Le Gateway, et non le nom de l’agent, constitue la frontière de confiance
La conclusion pratique d’Aipolix est simple : un profil d’agent distinct ne constitue pas à lui seul une frontière de confidentialité.
Prenons un Gateway qui héberge un assistant personnel, un agent financier et un agent d’ingénierie. Si ces rôles manipulent des données de sensibilités différentes ou servent des utilisateurs qui ne partagent pas le même niveau de confiance, séparer les instructions données aux agents et leurs règles d’accès aux outils ne suffit pas. La documentation d’OpenClaw précise que les profils d’outils ne réduisent pas la portée des outils de session et qu’un agent non isolé peut encore lire les sessions d’un agent isolé avec les réglages par défaut.
Pour des profils qui se font réellement confiance, le comportement par défaut peut être un choix pratique. Pour des niveaux de confiance différents, OpenClaw conseille de régler tools.sessions.visibility sur agent ou self, de limiter les couples autorisés avec tools.agentToAgent.allow, ou de désactiver entièrement les échanges entre agents. Pour de véritables locataires distincts ou des utilisateurs adverses, il faut séparer les Gateways.
Cette lecture est plus utile que de considérer automatiquement chaque identité d’agent comme une frontière de sécurité autonome. Après cette mise à jour, le Gateway doit être associé à un domaine de confiance réel de l’organisation.
Une mise à niveau doit inclure un contrôle de la frontière de confiance
Comme ce changement arrive sous forme de nouvelle valeur par défaut, une mise à niveau mérite un examen des accès et pas seulement une lecture de la liste des fonctions. Les équipes qui hébergent plusieurs agents ou plusieurs utilisateurs dans le même Gateway devraient comparer les droits effectifs sur les sessions avant et après la version 2026.9.2.
Trois questions suffisent pour cadrer l’examen : quels agents non isolés peuvent invoquer les outils de session ? Certains servent-ils des utilisateurs, des canaux ou des données soumis à des exigences de confidentialité différentes ? Ces rôles doivent-ils réellement rester dans le même Gateway ?
L’outil openclaw security audit vérifie lui-même l’accès croisé aux sessions et peut signaler les situations où la visibilité globale par défaut coexiste avec des indices de niveaux de confiance différents, par exemple des politiques d’isolation ou des utilisateurs partagés.
Rien dans les sources consultées ne démontre une exploitation ou un contournement des contrôles existants. Les restrictions sur les outils et les environnements isolés demeurent, et le projet documente clairement son modèle d’une zone de confiance par Gateway. L’enjeu de la version 2026.9.2 est architectural : quand le partage de contexte entre agents devient plus large par défaut, la topologie de confiance doit entrer dans la décision de mise à niveau.