Comment FireAI limite les dégâts réseau des erreurs risquées d’OpenClaw sur votre Mac

Exécuter un agent autonome tel qu’OpenClaw sur un Mac confère à un modèle de langage les permissions du compte qui le lance, et les rapports de sécurité publiés depuis janvier 2026 décrivent plusieurs manières dont ce dispositif a mal tourné. La plupart de ces défaillances se terminent par une connexion réseau : des données envoyées à un serveur inconnu, un service local accessible depuis l’extérieur, ou une charge malveillante téléchargée. FireAI est un pare-feu réseau pour macOS : il peut donc limiter cette partie. Il ne peut pas empêcher un agent de lire ou de supprimer des fichiers locaux, et cet article précise où se situe cette frontière.

Contexte

La documentation d’OpenClaw indique que les outils s’exécutent sur l’hôte tant qu’aucun bac à sable n’est configuré, que les messages entrants constituent des entrées non fiables, et que les agents ayant accès à l’outil de messagerie peuvent, par défaut, envoyer des messages d’une conversation ou d’un fournisseur de canal à l’autre ^[1]. Un agent réunit donc trois éléments : il lit du texte non fiable, il peut agir sur la machine et il peut communiquer vers l’extérieur. Un pare-feu traite le troisième. Les sections suivantes examinent tour à tour chaque classe de risque documentée, nomment le contrôle FireAI correspondant et énumèrent les étapes de configuration. La comparaison générale entre OpenClaw et Hermes Agent fait l’objet d’un article distinct.

Avant les étapes : comment FireAI identifie un agent

FireAI identifie une app par la signature de code de l’exécutable qui ouvre la connexion ou, pour un programme non signé, par son chemin. Il ne dispose d’aucune intégration avec OpenClaw ou Hermes Agent et ne reconnaît ni l’un ni l’autre par son nom. Les agents de ce type s’exécutent dans un interpréteur généraliste, généralement Node.js ou Python ; FireAI affiche donc des connexions provenant de « node » ou de « python3 ». Une règle portant sur cet interpréteur s’applique à tous les scripts exécutés par ce même binaire, y compris des outils sans rapport.

L’attribution par script n’est pas disponible aujourd’hui. Chaque règle ci-dessous s’applique donc à l’interpréteur dans son ensemble, et une règle qui bloque les destinations de l’agent affecte aussi tout autre script exécuté par le même interpréteur. Lire le nom de l’interpréteur dans une invite et le rapprocher du moment où l’agent travaillait est la manière pratique d’attribuer une connexion.

Risque 1 : une injection de prompt qui fait sortir des données

Kaspersky a rapporté qu’OpenClaw s’est révélé vulnérable à l’extraction de données par le biais de contenus d’e-mails malveillants, notamment la démonstration par un chercheur de l’extraction de clés cryptographiques privées au moyen d’instructions dissimulées dans un message, ainsi que des utilisateurs signalant que le bot avait déversé le contenu de leur dossier personnel dans une discussion de groupe après une invite d’ingénierie sociale ^[3]. L’étape d’exfiltration est une connexion sortante du processus de l’agent vers un serveur contrôlé par l’attaquant ou vers un service de messagerie.

FireAI identifie chaque app par sa signature de code et vérifie ses règles pour chaque connexion. En mode Alerte, il met en pause la première connexion vers une destination sans règle et pose la question ^[12]. La configuration qui limite ce risque est une liste d’autorisation construite autour de l’agent :

Lancez l’agent une fois et laissez FireAI afficher ses premières connexions. Dans l’invite, cliquez sur Options, choisissez Toujours et Le site entier pour le domaine du fournisseur de modèle que vous utilisez réellement, puis Autoriser. L’invite nomme l’interpréteur, pas l’agent.
Bloquez toutes les autres destinations pour cette app : ouvrez Règles, cliquez sur Ajouter une règle, choisissez Arrêter la connexion, sélectionnez l’interpréteur sous lequel tourne l’agent (node ou python3) et réglez Quel site ou serveur sur N’importe où sur Internet.
Ouvrez la règle Autoriser créée pour le fournisseur de modèle et activez Quick, afin que la première règle Quick correspondante décide avant que le blocage général ne soit examiné.
Répondez Bloquer aux invites suivantes, sauf si vous savez nommer la destination. Une invite pour un domaine inconnu juste après que l’agent a lu un e-mail est précisément le signal que ce contrôle est conçu pour faire apparaître.
Ouvrez Détails dans l’invite pour vérifier l’adresse, le port et l’état de la signature de code, et utilisez Pourquoi bloquer ? lorsque l’option est proposée.

Des limites s’appliquent. Si l’agent est autorisé à joindre un service de messagerie ou son fournisseur de modèle, une instruction injectée peut y envoyer des données, et FireAI voit la quantité envoyée, pas son contenu, car il ne lit pas le contenu des connexions chiffrées (comment les connexions sont inspectées sans déchiffrement).

Risque 2 : des skills malveillants ou compromis

Koi Security a audité 2 857 skills sur ClawHub et en a identifié 341 malveillants, dont 335 issus d’une même campagne ; eSecurity Planet rapporte que ces skills demandaient aux utilisateurs d’installer des « prérequis » qui livraient Atomic macOS Stealer, lequel cible les identifiants des navigateurs, les mots de passe du trousseau, les portefeuilles, les clés SSH et les jetons d’API ^[6]. Un skill s’exécute avec les permissions de l’agent, de sorte que ses appels réseau apparaissent comme ceux de l’agent.

Les contrôles de FireAI agissent sur la destination de ces appels, de deux manières. D’abord, la liste d’autorisation de la section précédente refuse les destinations qui n’ont jamais été approuvées. Ensuite, FireAI peut utiliser des listes de menaces publiques :

Ouvrez la page des listes de menaces dans FireAI et activez Utiliser les données publiques sur les menaces. FireAI télécharge alors une fois par jour des listes telles qu’abuse.ch URLhaus, ThreatFox et Feodo Tracker, et votre trafic ne leur est jamais envoyé. Voir la documentation.
Activez Bloquer ce qu’une liste de menaces confirme, afin qu’une correspondance confirmée devienne un blocage et non un simple signalement.
Ouvrez Menaces et utilisez Investigate sur toute ligne que vous ne reconnaissez pas ; le dossier explique la connexion étape par étape.
Laissez l’Historique des connexions activé (Réglages, Historique des connexions) pour vérifier ultérieurement quelle app a contacté quelle destination ; il conserve un registre de 7 jours sur ce Mac uniquement.

Un skill qui contacte un serveur qu’aucune liste ne connaît, ou qui se contente de lire des fichiers locaux, n’est pas intercepté par ce contrôle. L’examen du skill avant son installation reste la première ligne de défense.

Risque 3 : une passerelle locale accessible depuis l’extérieur ou depuis un navigateur

Censys a relevé une progression d’environ 1 000 à 21 639 instances OpenClaw exposées publiquement en moins d’une semaine jusqu’au 31 janvier 2026, tout en notant que la Gateway est conçue pour écouter localement sur le port TCP 18789 ^[4]. Kaspersky a décrit des installations sans authentification qui faisaient confiance à localhost et se trouvaient derrière des proxys inverses mal configurés ^[3]. La découverte ClawJacked d’Oasis Security a montré qu’une page web pouvait se connecter à la Gateway locale depuis le navigateur ; la faille a été corrigée dans OpenClaw 2026.2.25 ^[5].

FireAI applique ses règles aux connexions entrantes vers le Mac comme aux connexions sortantes, même s’il ne pose jamais de question pour les connexions entrantes. Voir la documentation. Les étapes pertinentes :

Passez en mode Café lorsque le Mac se trouve sur un réseau que vous ne contrôlez pas. Ce mode bloque les connexions entrantes ainsi que le partage de fichiers et d’écran vers d’autres appareils, comme décrit dans les modes de sécurité.
Pour automatiser ce choix, associez le mode Café à vos lieux publics comme indiqué dans les lieux, ou utilisez Coffee Shop Armor, que la documentation de FireAI décrit pour les Wi-Fi publics.
Dans Règles, ajoutez une règle Bloquer entrante pour l’app de l’agent (sous Avancé, réglez Direction sur entrante) sur tout réseau auquel vous ne faites pas entièrement confiance.
Vérifiez aussi la configuration de l’agent lui-même : la Gateway doit rester liée à l’interface de bouclage, comme le décrit la documentation d’OpenClaw pour les installations classiques sur l’hôte ^[1].

Risque 4 : des identifiants et des fichiers qui quittent la machine

Les mêmes rapports citent les clés d’API, les jetons, les clés SSH et les fichiers de portefeuille parmi les cibles ^[6]. Pour l’exfiltration par le réseau, trois fonctions de FireAI s’appliquent :

L’inspection des protocoles bloque, avant qu’elles ne quittent le Mac, les requêtes web non chiffrées qui transportent des numéros de carte, des coordonnées bancaires, des mots de passe ou des clés, et bloque les données exfiltrées sous forme de requêtes DNS ; rien n’est stocké ni envoyé. Voir la documentation.
La Carte du monde et l’Activité montrent chaque connexion en direct et dans un historique consultable. Un clic droit sur une connexion propose Refuser l’hôte, Bloquer l’IP pour toutes les apps ou Bloquer cette app partout. Voir la documentation.
Ask FireAI accepte des ordres en langage courant tels que « bloque » suivi du nom d’une app telle qu’elle apparaît dans FireAI (l’interpréteur, dans le cas d’un agent), affiche un aperçu et n’applique rien tant que vous n’avez pas cliqué sur Appliquer. Voir la documentation.

Un identifiant envoyé à une destination autorisée par une connexion chiffrée échappe à ce que FireAI peut voir.

Risque 5 : des connexions inattendues en l’absence de surveillance

Les agents travaillent sans surveillance. La documentation d’OpenClaw précise que les expéditeurs inconnus sont appairés par défaut et que les agents peuvent envoyer des messages d’un canal à l’autre en l’absence de restriction ^[1] ; la documentation d’Hermes Agent décrit un système d’approbation des commandes dont le mode peut être désactivé ^[7]. C’est lors des exécutions sans surveillance qu’une action erronée ou injectée a le plus d’effet avant qu’une personne ne s’en aperçoive.

Utilisez une règle temporisée, créée via Ask FireAI, pour que l’agent ne se connecte qu’à des heures définies, par exemple « autorise l’agent pendant les heures de travail » ; les quatre plages intégrées sont la nuit, la soirée, les heures de travail et le week-end. Voir la documentation.
Utilisez le mode Parano lorsque l’agent fonctionne sans supervision. Il bloque le trafic de pistage, les apps non signées et tous les ports non chiffrés, et même les outils système d’Apple doivent être approuvés ^[10].
Utilisez le mode Sous attaque ou le kill switch lorsqu’un agent se comporte mal. Sous attaque n’autorise que les apps disposant d’une règle Autoriser explicite et cesse de poser des questions. Le kill switch refuse toute nouvelle connexion vers l’extérieur du réseau domestique ou professionnel, et il est également accessible depuis la barre des menus ^[11].
Réservez FireAI Pilot aux autres apps, ou vérifiez ses décisions dans Suggestions, car il répond automatiquement aux connexions dont il est sûr ; pour un agent, des règles explicites sont plus faciles à auditer.

Recommandations

Exécutez l’agent dans un compte utilisateur macOS dédié ou dans une machine virtuelle, avec uniquement les dossiers dont il a besoin.
Fournissez-lui des identifiants révocables et à portée restreinte, jamais votre gestionnaire de mots de passe principal ni vos clés SSH.
Lisez le code source d’un skill avant de l’installer, et refusez tout skill qui vous demande de coller une commande shell en guise de prérequis.
Maintenez l’agent à jour ; le correctif de ClawJacked n’a atteint les utilisateurs que par la mise à jour.
Laissez l’approbation des commandes en mode manuel lorsque l’agent le propose.
Combinez la liste d’autorisation, le kill switch et un mode adapté au lieu où vous travaillez.

Limites

FireAI voit l’interpréteur qui ouvre une connexion (par exemple node ou python3), pas le nom de l’agent ; une règle s’applique à tout ce que cet interpréteur exécute. Il ne dispose d’aucune intégration avec ces agents.
FireAI contrôle quelle app se connecte où et peut couper Internet. Il ne peut pas empêcher un agent de supprimer, chiffrer ou lire des fichiers locaux, d’exécuter des commandes ou de modifier des réglages sur le Mac.
Le kill switch refuse les nouvelles connexions ; il ne ferme pas celles qui sont déjà ouvertes.
FireAI ne lit pas le contenu des connexions chiffrées : les données envoyées à une destination autorisée ne sont pas inspectées.
Le filtrage du trafic de bouclage entre un navigateur et un service local n’est pas documenté ; mettez l’agent à jour pour corriger ce type de faille.
Les listes de menaces ne bloquent que ce qu’elles confirment ; un nouveau serveur ou un skill au comportement purement local n’est pas couvert.
Un pare-feu ne corrige pas les choix de conception propres à un agent, comme une Gateway liée à une adresse publique.
Des mesures complémentaires sont nécessaires : comptes à privilèges minimaux, bacs à sable ou machines virtuelles, sauvegardes, et examen des skills avant leur installation.

Le rôle de FireAI et de HisnLabs

Les agents agissent vite. Un pare-feu réseau décide où ils ont le droit de se connecter.

FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction FireAI Pilot) sur du trafic réel, sans que rien ne quitte votre Mac.

Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.