Ces derniers mois, une idée autrefois considérée comme de la science-fiction domestique a gagné en popularité : celle d’un assistant basé sur Intelligence Artificielle qui ne se limite pas à répondre à des questions, mais qui se connecte à de véritables canaux — messageries, outils de travail, intégrations type Slack/Discord, et bien plus — agissant comme une couche d’orchestration pour exécuter des tâches. Sur ce terrain évolue Moltbot (avec le nom Clawdbot encore très présent dans les références, exemples et le branding historique), un projet combinant modèle de langage, « gateway » et tableau de bord pour transformer un LLM en une sorte d’opérateur numérique.

La promesse est puissante : une mémoire opérationnelle, automatisation, sessions, outils (skills), tâches planifiées (cron) et une console web pour observer — en temps réel — ce que fait le bot, quelles intégrations sont actives et quels permissions ont été habilitées. En pratique, Moltbot expose un Gateway avec interface web et WebSocket (par défaut sur le port 18789), permettant de gérer canaux, configurations et actions de l’agent.

Le problème est que cette évolution — du simple « chat » à l’« agent avec mains » — transforme la cybersécurité de l’utilisateur en enjeu sérieux. Il ne s’agit plus seulement de si le modèle se trompe, mais de ce qui se passe lorsque le modèle reçoit des instructions malicieuses via un canal que le bot lui-même considère comme une « entrée valide », et qu’il dispose par ailleurs de permissions suffisantes pour agir.

Du chatbot à l’agent : pourquoi le risque évolue

Un chatbot traditionnel vit, pour ainsi dire, à l’intérieur de sa cage : il répond par du texte. Un agent comme Moltbot vise à aller plus loin en proposant :

• Canaux de messagerie (le panneau évoque WhatsApp, Telegram, Discord, Slack et des canaux via plugins).
• Gestion de sessions, contrôle du comportement, tâches programmées et « skills » installables.
• Édition de la configuration directement dans le système (la documentation mentionne des chemins comme ~/.clawdbot/moltbot.json), ce qui témoigne aussi de la continuité avec Clawdbot.
• Mécanismes d’exécution contrôlée (avec « exec approvals » et allowlists pour exécutions via la gateway ou le nœud).
• Variables d’environnement et shell : des exemples permettent d’activer un environnement shell (shellEnv) et de gérer des clés/API.

Cette architecture est attrayante — et pour un profil technique, tentante — mais soulève une réalité préoccupante : chaque intégration augmente la surface d’attaque et chaque permission amplifie le potentiel d’un mauvais fonctionnement, d’une mauvaise configuration ou d’un abus.

Le vecteur sous-estimé : l’injection de prompt

Dans ces systèmes « agentiques », le risque majeur ne se limite pas au phishing classique, mais à une variante adaptée : l’injection de prompt. Cela consiste à insérer des instructions dans un contenu — message, texte, document — que le bot va traiter, pour que le modèle « obéisse » à des directives non désirées.

Lorsque l’agent peut agir — par exemple, consulter des informations, exécuter des outils, modifier la configuration ou impulser des intégrations — l’injection de prompt cesse d’être une simple manipulation créative pour devenir un incident potentiel : exfiltration de données, actions non autorisées, modifications malicieuses. Des chercheurs en sécurité avertissent que ces assistants, si déployés sans précautions ou avec des permissions larges, peuvent être particulièrement vulnérables aux abus et aux erreurs d’exposition.

Le principe clé réside dans l’association : entrée non fiable (messagerie, canaux) + contexte unifié du modèle + outils avec permissions.

L’autre faiblesse critique : la sécurisation de la console et l’authentification

Dans Moltbot, l’interface « Control UI » est accessible via le Gateway via WebSocket. La documentation insiste sur le fait que l’assistant d’intégration (onboarding) génère un token par défaut et que l’authentification peut se faire lors du handshake WebSocket, en précisant des méthodes recommandées pour un accès à distance (par exemple, via Tailscale Serve en HTTPS).

Il est également souligné qu’il faut idéalement :

• Maintenir le Gateway en boucle locale (loopback) par défaut
• En cas d’accès distant, utiliser un proxy sécurisé (Tailscale Serve) ou faire « bind to tailnet » avec un token fort.

En pratique, toutefois, certains ouvrent des ports, publient des services en LAN/WAN ou réutilisent des tokens faibles. Cela crée un risque : un panneau de contrôle avec capacité opérationnelle, exposé à l’extérieur, peut devenir un point d’entrée potentiellement compromis.

Synthèse : menaces communes et mesures pour atténuer les risques

« Puissant, oui; mais considéré comme une infrastructure critique »

Dans un contexte professionnel — et notamment dans un environnement d’entreprise —, il est sage de traiter un tel assistant comme on traiterait un serveur avec accès à des outils internes : segmentation, contrôle d’accès, journalisation et audit.

Dès lors, une approche responsable consiste à considérer qu’un agent connecté à la messagerie et aux outils métiers constitue, en fait, un nouvel « utilisateur » du système : avec identifiant, permissions et canaux de communication. Le laisser opérer sans barrières expose non seulement à des failles mais aussi à des erreurs potentielles.

Pratiques recommandées pour une utilisation prudente

• Ne pas exposer le Gateway à Internet. Préférer le maintien en loopback et, si un accès distant est nécessaire, utiliser une solution comme Tailscale Serve en HTTPS.
• Utiliser un token fort et le faire tourner régulièrement. Éviter les « exceptions » qui compromettent la sécurité pour plus de confort (lisez bien la documentation, qui met en garde contre les modes non sécurisés).
• Appliquer le principe du moindre privilège. Commencer avec le bot « quasi cecif » et n’accorder des permissions qu’après avoir bien compris leur impact.
• Ioler l’environnement d’exécution (conteneur/VM), en limitant le réseau et en évitant d’accorder des accès inutiles.
• Mettre en place une auditabilité et des journaux : essentiels pour analyser ce que l’agent a fait en cas d’incident ou pour repérer des abus.

En définitive, Moltbot/Clawdbot témoigne d’une étape importante de notre industrie : nous passons de « dialoguer avec l’IA » à « déléguer des actions à l’IA ». Sans contrôles appropriés, cette délégation peut transformer l’automatisation en une opération risquée.

Foire aux questions

En quoi Moltbot/Clawdbot diffère-t-il d’un chatbot classique ?
Il est conçu pour fonctionner comme un agent : il intègre des canaux (WhatsApp, Telegram, Slack, Discord), gère des sessions, des tâches programmées, des outils, et s’administre via un Gateway avec panneau de contrôle.

Un modèle en local élimine-t-il le risque de sécurité ?
Il limite l’exposition à des tiers, mais ne supprime pas le problème central : l’insertion de données malicieuses (prompt injection) et les permissions excessives restent des enjeux si l’agent peut agir sur des systèmes ou intégrations.

Quelle erreur revient le plus souvent lors du déploiement ?
Accorder des permissions étendues « pour tester » tout en laissant un accès distant peu sécurisé (token faible, HTTPS pas activé, accès LAN/WAN ouvert). La documentation recommande le plus souvent une approche en boucle locale, associée à un proxy sécurisé.

Quelles mesures minimales sont indispensables en entreprise ?
Cuentas séparées, principe du moindre privilège, segmentation réseau, journalisation et audit des actions, et un processus d’approbation ou d’allowlist pour tout accès ou exécution sensibles.