Résumé
Depuis le début d’année 2026, les assistants personnels autonomes de type OpenClaw, Claude Cowork et d’autres solutions en sources ouvertes connaissent une adoption particulièrement soutenue. Contrairement aux assistants conversationnels classiques, ces assistants personnels autonomes ne se contentent pas de répondre aux questions. Ils peuvent exécuter des commandes, contrôler le navigateur, lire et écrire des fichiers, gérer le calendrier et envoyer des courriels, le tout déclenché par un message texte via des applications très variés (ex : Slack, WhatsApp, Discord, etc.).
Leur utilisation élargit significativement la chaîne d’approvisionnement logicielle et sa surface d’attaque : des greffons (plugins) peuvent être chargés dynamiquement et selon le modèle d’intégration, exécutés comme du code de confiance, avec les mêmes privilèges que ceux de l’application. Cela rend le niveau de sécurité très difficile à maîtriser sans une politique de durcissement et de contrôle des extensions particulièrement stricte. Ainsi, en l’absence d’une politique de sécurité stricte du poste de travail (maîtrise du parc, contrôle des installations, moindre privilège, durcissement et supervision), le risque de Shadow IT et de perte de maîtrise du SI est élevé.
En l’état, les assistants personnels autonomes tels qu’OpenClaw ne doivent pas être déployés sur des postes de travail et leur usage doit être proscrit, tant que le produit n’est pas stabilisé et éprouvé du point de vue de la sécurité. En effet, un agent IA qui orchestre des outils capables d’exécuter des actions au niveau du système d’exploitation augmente fortement le risque de compromission (exécution non autorisée de commandes et d’exfiltration de données), par exemple via des injections de prompt ou des détournements de messages.
Ces constats et recommandations s’appliquent également aux déploiements sur mobiles.
Risques
- Compromission du poste utilisateur via une vulnérabilité sur ces outils d’agents IA (qui pour la plupart sont encore en version beta) ;
- Fuite de données sensibles par les agents IA vers des ressources externes non maîtrisées ;
- Droits d’accès démesurés donnés aux agents IA à l’ensemble des applications bureautiques de l’utilisateur (messagerie, agenda, gestionnaire de fichiers, applications métier, RH, etc.) ;
- Partage des secrets d’authentification (login/mdp) aux agents IA et potentielle fuite de ces secrets ;
- Perte de maîtrise des actions réalisées par les agents IA sur le poste bureautique et possibilité d’actions destructrices (ex : perte de l’intégrité ou de la disponibilité d’applications ou données métier).
Systèmes affectés
- Postes utilisateurs (Windows / Linux / Mobiles) ;
- Toutes les applications et données auxquelles l’agent IA a accès.
Solutions
Il est fortement recommandé de maîtriser l’ensemble des postes bureautiques utilisateurs et de proscrire l’installation d’outils non validés par les équipes IT et RSSI (Shadow IT).
Les produits d’automatisation de tâches bureautiques par IA agentique n’étant pas encore éprouvés et pour la plupart en version beta, ils ne doivent en aucun cas être déployés en environnements de production. Leur usage doit être strictement limité à des environnements de tests isolés (bacs-à-sable) sans aucune données sensibles (données de production, secrets, données personnelles, données bancaires, etc.).
Au-delà du niveau de maturité actuelle de ces produits, les applications d’IA agentiques comportent des faiblesses intrinsèques résultant de la vulnérabilité des LLM aux injections de prompt. Afin de limiter leurs impacts, leur mise en œuvre doit être réalisée sous validation préalable des équipes DSI et RSSI (avec acceptation des risques résiduels), et conditionné à des règles d’autorisation explicites [1], un cadrage rigoureux des canaux de messagerie utilisés, des approbations d’exécution et un isolement des processus (sandbox).
Outre la sensibilisation des utilisateurs, des mesures techniques peuvent être mises en place. Le principal levier de sécurisation est le durcissement de la configuration. En effet, si la formulation défensive des prompts peut contribuer à réduire les risques, elle peut être contournée via des attaques par injection. Les actions et outils accessibles aux agents IA doivent être limités au strict nécessaire ; une validation humaine doit être obligatoire dès qu’une commande système ou une action à effet de bord est envisagée ; l’exécution doit se faire dans un environnement isolé (sandbox) ; et des listes blanches doivent encadrer les canaux de communication et interlocuteurs autorisés à utiliser ces fonctionnalités (DM / groupes), avec une activation restreinte (par exemple uniquement sur mention explicite de l’agent IA @agent), afin de réduire le risque d’activation malveillante ou accidentelle.
[1] Il y a un risque résiduel dans la mesure où l’agent IA pourrait étendre ses capacités de manière autonome, en contournant les règles d’autorisation initiales.
Documentation
https://oathe.ai/engineering/we-audited-1620-ai-agent-skills/
https://www.paloaltonetworks.com/blog/network-security/why-moltbot-may-signal-ai-crisis/
https://docs.openclaw.ai/gateway/security
https://depthfirst.com/post/1-click-rce-to-steal-your-moltbot-data-and-keys
https://blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare
