Deux équipes utilisent le même Gateway, et une conversation destinée à l’une déclenche un agent avec des outils auxquels l’autre ne devrait pas avoir accès.

La réponse rapide : ne considérez pas un Gateway OpenClaw unique comme une frontière entre équipes qui ne se font pas confiance. Séparez les instances, leurs états, leurs identifiants et leurs espaces de travail. Décidez ensuite, séparément, si ces instances peuvent utiliser le même Mac physique.

Cet article s’adresse aux responsables IT qui évaluent un Mac pour OpenClaw et doivent fixer les limites d’accès entre équipes.
Il concerne aussi les responsables plateforme chargés du Gateway, de l’appairage des nœuds et des droits des agents.
Les responsables sécurité et les directions techniques y trouveront des points de contrôle pour les identifiants, les commandes distantes et l’hôte partagé.

Dernière vérification le 5 octobre 2026, à partir de la documentation officielle OpenClaw sur l’hébergement multi-locataire, les nœuds et leurs permissions.

01

La session n’est pas une frontière de confiance

Considérez deux équipes produit qui partagent un Gateway. L’équipe A reçoit les demandes dans un canal de travail et l’équipe B utilise un autre espace de conversation. Pour simplifier, l’exploitation a configuré des identifiants de session distincts et des destinations de réponse différentes.

Le montage paraît isolé. Pourtant, le routage des conversations ne prouve pas que les deux groupes sont séparés au niveau des ressources, des configurations ou des opérations. Si les équipes ne se font pas mutuellement confiance, un identifiant de session distinct ne suffit pas à créer une frontière de sécurité.

OpenClaw décrit le Gateway par défaut comme relevant d’une frontière correspondant à un opérateur de confiance. La documentation précise qu’un Gateway partagé ne doit pas être traité comme un système d’isolation entre locataires adverses. La décision d’architecture en découle : gardez une instance commune uniquement lorsque les utilisateurs sont dans le même domaine de confiance et que les contrôles communs sont acceptables. Sinon, séparez les instances. Consultez les recommandations officielles pour l’hébergement multi-locataire avant de valider le modèle.

Cette séparation concerne le Gateway complet, et pas seulement la manière dont les conversations sont nommées. Prévoyez des frontières propres pour l’état persistant, les identifiants, les configurations et les espaces de travail. Si deux instances utilisent ensuite le même matériel, vous devez encore déterminer ce qui les sépare au niveau du système d’exploitation et des fichiers.

Attention : appeler une configuration « multi-tenant » ne la rend pas isolée. Demandez-vous plutôt si une équipe peut modifier, consulter ou déclencher les ressources de l’autre, et qui peut administrer le Gateway commun.

02

Les rôles et les portées limitent certaines opérations

Les portées d’opérateur et les règles d’outils ont une utilité réelle. Elles permettent de restreindre des capacités et de distinguer des catégories d’opérations. Mais elles ne transforment pas, à elles seules, un Gateway conçu autour d’un opérateur de confiance en une frontière robuste entre organisations indépendantes.

Examinez les contrôles séparément :

  • Rôles et portées de l’opérateur : ils déterminent certaines actions disponibles pour un opérateur. Vérifiez précisément les capacités associées à chaque rôle et les méthodes auxquelles sa portée s’applique dans la documentation officielle des portées d’opérateur.
  • Politique des outils de l’agent : elle peut limiter les outils ou opérations accessibles à un agent. Elle ne constitue pas une preuve que les données, extensions et identifiants des différentes équipes sont séparés.
  • Identifiants et configuration du Gateway : s’ils restent administrés dans un même périmètre, l’équipe qui contrôle ce périmètre peut influer sur les agents et les intégrations qui en dépendent.
  • Session et routage : ils orientent les conversations. Ils ne doivent pas être interprétés comme une autorisation d’accéder à un répertoire, un compte de canal ou un secret d’une autre équipe.

Pour chaque capacité, consignez qui peut la configurer, quel processus l’exécute et quel domaine de confiance elle touche. La documentation sur l’hébergement multi-locataire et les portées d’opérateur est utile pour comprendre les limites des contrôles. Ne décrivez pas un réglage comme une garantie d’isolation s’il s’agit seulement d’une restriction opérationnelle.

En pratique, une instance commune peut convenir à une équipe qui partage la même responsabilité d’administration et accepte les mêmes règles. Elle est inadaptée si une équipe doit empêcher l’autre d’accéder à ses ressources ou de modifier ses intégrations. Dans ce second cas, vous avez besoin d’une frontière d’instance, pas seulement d’une convention de nommage ou d’une répartition des conversations.

03

L’appairage d’un nœud Mac ouvre un autre plan de risque

Un Mac associé à un Gateway n’est pas simplement un écran distant. Selon les capacités offertes au nœud et les règles d’exécution, le lien peut permettre des opérations à distance. L’appairage établit la relation de confiance prévue par le mécanisme d’association ; il ne signifie pas que chaque commande sera confirmée une par une par une personne.

Distinguez ces trois décisions :

Ajoutez ensuite le compte macOS utilisé par le processus d’exécution à votre analyse. Un contrôle côté OpenClaw et un compte du système d’exploitation ne sont pas la même frontière. Si le compte peut lire les fichiers d’une autre équipe ou accéder à ses secrets, une séparation apparente au niveau de l’agent ne corrige pas ce problème.

Pour les configurations du Gateway et de ses nœuds, confrontez aussi les réglages appliqués à la référence officielle de configuration. Vérifiez les versions déployées avant de reprendre une valeur par défaut depuis un ancien guide : les options et les comportements peuvent évoluer.

04

Les extensions et les secrets peuvent traverser les frontières

Les risques d’accès ne se limitent pas aux commandes exécutées par un agent. Dans une plateforme d’entreprise, les éléments suivants méritent un examen spécifique :

  • Extensions : traitez leur code comme du code auquel vous accordez votre confiance. Qui peut l’ajouter, le mettre à jour et le rendre disponible aux agents ? La documentation officielle des extensions OpenClaw constitue la référence pour examiner leur installation et leur gestion.
  • Compétences et répertoires dynamiques : déterminez qui peut modifier les fichiers chargés par les agents et à quel moment ces changements sont pris en compte. La documentation officielle des compétences aide à vérifier leur organisation et les conditions de confiance.
  • Identifiants de modèles et de canaux : séparez les secrets par domaine de confiance. Une séparation des sessions ne protège pas un identifiant réutilisé ou accessible depuis une configuration commune.
  • Espaces de travail et fichiers d’état : délimitez les chemins accessibles et les personnes qui peuvent les administrer. Confirmez les permissions effectives du compte macOS, pas seulement les intentions écrites dans une procédure.
  • Journaux et sauvegardes : établissez qui peut les consulter et si des données sensibles y sont conservées. Une copie de sauvegarde commune peut réintroduire un accès transversal même lorsque les répertoires actifs sont distincts.

Un conteneur ou un bac à sable d’agent peut limiter certaines opérations, selon la configuration. Ne le présentez pas comme un substitut à la séparation de Gateway que recommande la documentation pour des équipes qui ne partagent pas la confiance. Il faut évaluer chaque couche pour la fonction qu’elle assure : restriction d’outils, contrôle de fichiers, séparation d’identifiants ou frontière d’administration.

05

Le choix d’architecture dépend du domaine de confiance

Vous pouvez décider du partage du matériel après avoir choisi les frontières logiques. Cette séquence évite de confondre « instances différentes » et « hôtes isolés ».

Même domaine de confiance. Si les équipes partagent l’administration, les identifiants et les règles de changement, une instance commune peut être examinée avec des rôles, des portées et des politiques d’outils adaptés. Il reste nécessaire de documenter qui administre les canaux, les extensions, les agents et les nœuds.

Domaines de confiance distincts. Déployez des Gateways indépendants. Attribuez à chaque instance son propre état, ses identifiants et ses espaces de travail. Limitez les accès d’administration à l’équipe correspondante. Après cette séparation, évaluez si les instances peuvent cohabiter sur un même Mac en fonction des comptes macOS, des permissions de fichiers et du niveau de risque accepté.

Exigence de séparation physique ou de conformité. Si votre politique impose des hôtes dédiés, si des données sensibles ne doivent jamais partager le même système d’exploitation, ou si l’audit exige une frontière matérielle, ne considérez pas des instances distinctes sur un Mac commun comme une réponse équivalente. Il faut alors prévoir des hôtes séparés et valider les contrôles associés.

La documentation Fleet d’OpenClaw présente cette fonctionnalité comme expérimentale. Ne la retenez donc pas comme une garantie d’isolation d’entreprise déjà validée ; contrôlez son statut et ses limites dans la documentation officielle de Fleet au moment de concevoir votre déploiement.

06

Liste de contrôle avant mise en service

Cochez chaque point avec les responsables des équipes, de la plateforme et de la sécurité. Si une réponse reste indéterminée, reportez le partage des ressources concernées.

  • [ ] Définissez par écrit quelles équipes appartiennent au même domaine de confiance et lesquelles doivent être séparées.
  • [ ] Pour chaque groupe qui ne partage pas la confiance, prévoyez une instance Gateway indépendante.
  • [ ] Vérifiez que l’état, la configuration, les identifiants et les espaces de travail ne sont pas réutilisés entre ces instances.
  • [ ] Attribuez un responsable à chaque identifiant de modèle, compte de canal, extension et compétence.
  • [ ] Vérifiez les rôles et les portées d’opérateur, puis confirmez les limites de chacun dans la documentation officielle.
  • [ ] Identifiez les capacités exposées par chaque nœud Mac et les agents autorisés à les appeler.
  • [ ] Contrôlez les approbations d’exécution globales et locales, ainsi que le compte macOS qui lance les commandes.
  • [ ] Testez qu’un opérateur d’une équipe ne peut ni lire ni modifier les ressources réservées à l’autre.
  • [ ] Fixez une procédure de révocation d’un appairage, d’un identifiant ou d’une extension compromise.
  • [ ] Confirmez si la politique interne autorise plusieurs domaines de confiance sur un même hôte physique.

Cette vérification sépare les décisions souvent confondues : accès à l’interface, droit d’administration du Gateway, autorisation d’un outil, exécution sur un nœud, permissions macOS et partage du matériel. Validez-les comme des contrôles distincts, avec des responsables identifiés et des essais consignés.

07

Questions fréquentes

Les réponses suivantes précisent comment appliquer ces frontières quand vous arbitrez entre commodité opérationnelle et indépendance des équipes.

Un Gateway commun réduit le nombre d’instances à maintenir, mais augmente le nombre de décisions d’accès à administrer dans le même périmètre. Si une équipe ne peut pas faire confiance à l’autre, cette économie ne justifie pas de traiter le routage des sessions comme un cloisonnement. Séparez alors le Gateway, les identifiants et les espaces de travail.

Un nœud Mac appairé peut exposer des capacités d’exécution selon les options et les approbations configurées. L’association n’équivaut pas à une validation individuelle de chaque commande. Vérifiez les règles d’exécution, les approbations et le compte du système d’exploitation avant d’autoriser des agents à utiliser ce nœud.

Pour les secrets et les extensions, identifiez les chemins de stockage et les personnes capables de les modifier. Utilisez des identifiants distincts par domaine de confiance, contrôlez les droits sur les fichiers et limitez les changements de code chargé par les agents. Incluez les sauvegardes et journaux dans cet examen, car ils peuvent reproduire des données communes.

La séparation de Gateway est une décision logique et opérationnelle. L’isolation de l’hôte répond à une exigence différente. Vous pouvez envisager un Mac partagé seulement si les comptes, les fichiers et les règles d’administration satisfont votre politique. Si celle-ci exige une séparation physique, retenez des hôtes indépendants plutôt que d’assimiler plusieurs instances à une isolation matérielle.

Si vous exploitez déjà une machine partagée, ne commencez pas par déplacer les agents au hasard. Inventoriez les secrets, les répertoires de travail, les comptes de canaux et les capacités des nœuds, puis attribuez chaque ressource à un domaine de confiance. Migrez les éléments sensibles vers des instances distinctes et révoquez les accès devenus inutiles.

08

Déploiement sur Mac et étape suivante

Un Mac administré en interne vous donne le contrôle direct du matériel, mais vous laisse aussi gérer son entretien, les comptes locaux et les conflits d’usage entre équipes. Un Mac distant loué peut éviter l’achat immédiat d’un hôte et faciliter l’accès à une machine hébergée, mais il ne crée pas automatiquement une isolation OpenClaw conforme à vos exigences. Vous devez toujours valider les comptes, les accès, la gestion des instances et les conditions de livraison avant d’y placer des secrets d’entreprise.

Si vous comparez ces options, consultez les tarifs de location Mac, puis les informations de commande Mac. VpsMesh peut être une piste pour disposer d’un Mac distant lorsque votre architecture et vos exigences d’accès correspondent aux modalités effectivement proposées. Ne déduisez pas de la disponibilité d’un Mac que vos frontières de confiance sont garanties : faites confirmer chaque besoin d’isolation et ne demandez une offre que si les conditions réelles conviennent à votre déploiement.