Depuis quelques mois, les agents IA autonomes s'installent en entreprise à un rythme qui surprend même leurs créateurs. Des plateformes comme n8n et Make.com peuvent lire des fichiers, envoyer des emails, appeler des API, interagir avec un navigateur ou déclencher des actions dans vos outils métier, selon les intégrations configurées. Certaines équipes déploient encore ces outils sans évaluer précisément la surface d'attaque qu'ils introduisent.
Des agents IA capables d'agir, pas seulement de répondre
Il faut distinguer trois niveaux. Une automatisation classique suit un parcours prédéfini. Un workflow augmenté par un LLM peut interpréter du contenu ou prendre une décision limitée. Un agent IA dispose d'outils, d'un objectif et d'une capacité de planification qui lui permettent d'enchaîner plusieurs actions de manière autonome. C'est généralement ce dernier cas qui présente la surface de risque la plus importante, car l'agent peut combiner interprétation, choix d'outils et exécution d'actions. Cisco l'a formulé clairement : un agent IA n'est plus un assistant conversationnel. C'est un nouveau vecteur d'attaque branché directement sur votre système d'information. Dans certains agents extensibles, les plugins ou skills peuvent être chargés dynamiquement et bénéficier de privilèges importants au sein de l'environnement d'exécution. Le niveau d'exposition dépend de la plateforme, du modèle d'isolation et des permissions accordées.
Les principaux risques des agents IA en entreprise
Un agent IA autonome ne devrait jamais être déployé sur un poste de production avec des privilèges élevés. En production, il doit être isolé, soumis au principe du moindre privilège, surveillé et encadré par des contrôles adaptés à la criticité de ses actions.
Les risques varient selon la plateforme et l'architecture, mais plusieurs catégories reviennent régulièrement dans les analyses de sécurité :
- Compromission du poste ou de l'environnement d'exécution : une vulnérabilité dans l'agent, une extension ou une dépendance peut permettre une prise de contrôle partielle ou complète de son environnement
- Fuite de données : l'agent transmet des informations sensibles à des services externes non contrôlés
- Droits trop larges : messagerie, agenda, fichiers, RH, applications métier : l'agent peut recevoir accès à plus de systèmes qu'il n'en a besoin
- Identifiants partagés : des jetons d'accès ou mots de passe communiqués à l'agent peuvent être exposés ou exfiltrés
- Manque de traçabilité : sans journalisation et supervision, il devient difficile de savoir quelles actions l'agent a effectuées et d'en évaluer l'impact
Injections de prompt et risques LLM : les catégories OWASP à connaître
L'OWASP Top 10 pour les applications LLM propose une classification des risques importants dans les applications qui intègrent des modèles de langage. Dans un contexte agentique, plusieurs catégories sont particulièrement pertinentes :
- Injection de prompt : un attaquant manipule l'agent via des instructions malveillantes glissées dans un email, un PDF ou un message Slack
- Divulgation de données sensibles : le modèle expose des informations confidentielles présentes dans son contexte ou ses instructions système
- Autonomie excessive et permissions trop larges : l'agent dispose de bien plus de permissions que nécessaire, ce qui amplifie les dégâts en cas de compromission
- Sorties non validées : l'IA déclenche des actions via des outils ou des API sans validation humaine intermédiaire
- Chaîne d'approvisionnement : plugins communautaires non vérifiés, dépendances tierces ou modèles non audités introduits dans l'architecture
- Empoisonnement des données ou de la base de connaissances : des données manipulées peuvent influencer les réponses du modèle ou les décisions de l'agent
Cette sélection ne constitue pas une reproduction complète du Top 10 OWASP. Elle retient les catégories les plus directement liées aux agents capables d'utiliser des outils et d'agir sur des systèmes externes.
Workflows n8n et Make.com : des risques souvent sous-estimés
Les plateformes low-code facilitent le partage de workflows en JSON. C'est pratique, mais c'est aussi une porte d'entrée. Dans n8n, un export de workflow contient la définition du workflow, ses nœuds, paramètres et connexions référencées. Certains exports peuvent aussi contenir des noms de credentials et, dans le cas de requêtes importées depuis cURL, des en-têtes d'authentification. Il faut donc inspecter et anonymiser le fichier avant de le partager. Plus généralement, comme l'explique cette analyse des risques cachés de ces plateformes, tout workflow importé doit être vérifié avant son activation, en particulier lorsqu'il utilise des scripts, des nœuds communautaires ou des intégrations externes.
- Code non vérifié dans les nœuds de script : une logique malveillante ou insuffisamment contrôlée peut exfiltrer des données ou déclencher des actions non autorisées lors de l'exécution du workflow
- Exposition des identifiants : noms de connexion et configurations révélant des détails sur votre infrastructure, ou secrets codés en dur dans le JSON
- Nœuds communautaires non vérifiés : des composants tiers peuvent introduire du code ou des dépendances présentant des risques supplémentaires, avec un niveau d'accès dépendant de leur implémentation et de la configuration de l'instance
- Instances auto-hébergées non mises à jour : pour n8n en particulier, des avis de sécurité récents ont porté sur l'évaluation d'expressions et l'exécution de code. Suivez les bulletins et appliquez rapidement les correctifs
- Conformité aux réglementations de confidentialité : données personnelles envoyées à des APIs IA potentiellement hors juridiction, sans accord de traitement formalisé
Ce que montrent les recherches récentes
Les incidents récents montrent que ces risques sont déjà exploitables dans certains écosystèmes. Trend Micro a documenté des skills OpenClaw malveillants utilisés pour distribuer une variante du voleur de données Atomic macOS Stealer (AMOS). Cisco et Palo Alto Networks ont analysé les risques liés aux privilèges élevés, aux skills malveillants et à la chaîne d'approvisionnement des extensions. Et une étude publiée sur arXiv modélise les vecteurs d'attaque contre les agents LLM en production. Ces exemples décrivent des architectures spécifiques, mais ils montrent que l'écosystème est déjà une cible.
Recommandations concrètes pour sécuriser vos automatisations
Ces risques ne sont pas une fatalité. On peut les gérer, à condition d'intégrer la sécurité dès la conception. Voici les pratiques à mettre en place avant de déployer quoi que ce soit en production.
- Moindre privilège : l'agent n'accède qu'aux outils et permissions strictement nécessaires à sa tâche, rien de plus
- Validation humaine pour les actions irréversibles : suppression, envoi, modification de données de production. Pour les actions réversibles et à faible risque, des règles de contrôle et une journalisation complète peuvent suffire
- Environnement de test isolé : tester les agents dans un environnement isolé, avec des données synthétiques ou non sensibles, avant toute connexion à des systèmes de production
- Vérification des workflows importés : inspecter chaque nœud de script, supprimer les identifiants codés en dur, n'importer que depuis des sources internes ou officielles
- Listes blanches sur les déclencheurs : restreindre quels utilisateurs ou groupes peuvent activer l'agent, et dans quelles conditions
- Journaliser et surveiller : conserver les actions effectuées, les outils appelés et les validations humaines, avec une durée de rétention compatible avec vos exigences de confidentialité
- Mécanisme d'arrêt d'urgence : tout agent capable d'actions sensibles doit pouvoir être désactivé rapidement et ses jetons d'accès révoqués sans délai
- Rotation et expiration des jetons : limiter la durée de vie des clés API et révoquer immédiatement celles qui ne sont plus nécessaires
- Limites de volume et de coût : imposer des plafonds sur le nombre d'appels, d'emails, de fichiers modifiés ou de transactions
- Séparation des environnements : utiliser des comptes, identifiants et données distincts pour le développement, les tests et la production
- Gouvernance des données : ne transmettre aux APIs IA que le strict nécessaire, pseudonymiser si possible, vérifier les accords de traitement
- Validation IT et sécurité : toute automatisation agentique en production doit faire l'objet d'une acceptation formelle des risques résiduels
L'automatisation IA peut faire gagner un temps précieux. Un agent mal configuré peut en perdre bien davantage. Ce n'est pas une raison de ne pas s'y mettre, c'est une raison de le faire correctement.
Si le sujet de l'IA en cybersécurité vous intéresse, on a aussi écrit sur l'intelligence artificielle comme atout et menace en cybersécurité.