Il y a dix ans, les organisations ne subissaient pas de brèches parce que les fondations cryptographiques d’AWS ou d’Azure étaient défaillantes. Elles étaient piratées parce que des développeurs déployaient des compartiments (buckets) S3 avec un accès public en lecture/écriture, intégraient des clés AWS Root dans des dépôts GitHub, et créaient des infrastructures fantômes (shadow IT) non gérées.
En 2026, l’histoire se répète avec l’IA Agentique.
Comme le souligne la publication de Microsoft de février 2026 (“Copilot Studio Agent Security: Top 10 Risks”), les principaux vecteurs d’attaque exploités avec succès dans la nature ne sont pas de complexes attaques par inversion de gradient. Au lieu de cela, les adversaires capitalisent sur des erreurs de configuration opérationnelles systémiques. Les développeurs se précipitent pour intégrer des capacités autonomes dans les flux de travail d’entreprise sans appliquer les règles fondamentales de la gouvernance informatique, ce qui conduit à une orchestration non sécurisée et à des configurations par défaut dangereuses (Insecure Defaults).
Une injection de prompt n’est fatale que si l’agent est mal configuré et fait aveuglément confiance à sa propre sortie. Pour sécuriser l’écosystème de l’IA, nous devons traiter l’IA Agentique comme un défi d’infrastructure distribuée.
La barrière à l’entrée pour déployer un agent IA est effectivement nulle. Un développeur peut instancier un agent autonome en utilisant des frameworks comme LangChain, AutoGen ou Microsoft Copilot Studio en moins de vingt lignes de code.
Cette facilité de déploiement a engendré la crise de la prolifération des agents (Agent Sprawl).
Écosystèmes d'agents non gérés
dans les entreprises modernes, des unités commerciales individuelles déploient des agents sur mesure adaptés à leurs besoins spécifiques (ex: des bots de tri de CV pour les RH, des bots d’analyse de logs pour le DevOps) complètement en dehors du contrôle de la DSI centrale et du SOC. Ces agents non gérés opèrent comme des microservices voyous.
Le problème des identifiants codés en dur
parce que ces agents sont souvent déployés en dehors des pipelines CI/CD standards et des coffres-forts de gestion des secrets (comme HashiCorp Vault ou Azure Key Vault), les développeurs codent fréquemment en dur des clés d’API hautement privilégiées et à longue durée de vie directement dans les scripts d’initialisation de l’agent pour contourner les flux d’authentification complexes.
Lorsqu’un attaquant découvre un agent non géré, il exécute simplement une attaque par détournement de fonction basique pour pivoter à travers l’agent et utiliser ses identifiants codés en dur, contournant ainsi tous les contrôles IAM (gestion des identités et des accès) de l’entreprise.
L’adoption massive du Model Context Protocol (MCP) d’Anthropic a standardisé la façon dont les modèles d’IA se connectent aux outils externes. Cependant, il a également introduit une vulnérabilité opérationnelle catastrophique en cas de mauvaise configuration.
Comme l’ont rapporté CSO Online et MBGSec en 2026, Internet est actuellement jonché de serveurs MCP exposés et mal configurés.
Le MCP prend en charge les connexions distantes via Server-Sent Events (SSE) sur HTTP. Les développeurs déploient fréquemment un serveur MCP pour exposer une base de données locale ou une instance Jira d’entreprise à un LLM distant.
Par défaut, de nombreux modèles de déploiement rapide MCP se lient à 0.0.0.0 (toutes les interfaces) plutôt qu’à 127.0.0.1 (localhost) et manquent d’exigences d’authentification par défaut.
npx @modelcontextprotocol/server-postgres sur une machine virtuelle cloud, exposant involontairement le point de terminaison /mcp ou /sse à l’Internet public sans imposer le TLS mutuel (mTLS) ni l’authentification par jeton Bearer.tools/list ou resources/list.query_database) depuis son propre script local, contournant entièrement le LLM prévu.Dans ce scénario, le modèle d’IA n’a même jamais été attaqué. L’infrastructure censée soutenir l’IA a simplement été laissée grande ouverte, transformant un outil de productivité IA en une porte dérobée d’exécution de code à distance (RCE) non authentifiée.
Si un serveur MCP exposé est l’équivalent d’un port de pare-feu ouvert, un agent sur-privilégié est l’équivalent d’un compte Administrateur de Domaine compromis.
Selon le rapport de Microsoft de 2026 sur la sécurité des agents Copilot Studio, l’attribution de permissions excessives aux agents IA est l’erreur de configuration la plus répandue et la plus dommageable dans les déploiements d’entreprise.
Lorsque les développeurs intègrent un LLM aux API backend, ils accordent fréquemment au principal de service de l’agent des rôles génériques et de grande envergure (ex: Contributor dans Azure, ou AmazonS3FullAccess dans AWS) pour éviter les frictions liées au débogage des politiques IAM granulaires.
Cette pratique crée une surexposition des API catastrophique. Le framework d’orchestration n’avait peut-être l’intention que de laisser l’agent utiliser un outil read_user_profile, mais parce que le compte de service sous-jacent détient des privilèges de lecture globaux, l’agent possède intrinsèquement la capacité d’interroger l’intégralité de l’annuaire de l’entreprise.
Si un adversaire exécute avec succès une attaque par détournement de fonction, l’agent ne sera pas contraint par son cas d’usage prévu. Il exécutera la charge utile de l’attaquant en utilisant tout le poids de son rôle IAM sur-provisionné.
Comme nous l’avons détaillé dans notre analyse du moindre privilège pour les agents LLM, la sécurité de l’IA est fondamentalement un problème de gestion des identités et des accès. S’en remettre au prompt système du LLM pour appliquer le contrôle d’accès (ex: “tu es un bot RH, ne lis pas les données financières”) est un échec architectural. L’autorisation doit être strictement appliquée au niveau de l’API et de l’infrastructure, en utilisant des jetons éphémères Just-In-Time (JIT) limités strictement à la session de l’utilisateur actuel.
Les systèmes d’IA Agentique sont hautement modulaires. Ils s’appuient sur des plugins tiers et des registres MCP dynamiques pour étendre leurs capacités. Cette modularité introduit une orchestration non sécurisée.
Configurations par défaut non sécurisées dans les plugins
de nombreux plugins d’agents open source sont livrés avec des valeurs par défaut non sécurisées, conçues pour des tests locaux plutôt que pour un déploiement en production. Par exemple, un plugin de visualisation de données pourrait implicitement autoriser l’écriture arbitraire de fichiers dans le répertoire /tmp/, ou un plugin de requête SQL pourrait utiliser autocommit=True par défaut sans nettoyer (sanitize) les entrées.
Défaillances de la confiance transitive
lorsqu’un orchestrateur (comme LangChain) intègre un plugin, il fait souvent intrinsèquement confiance à la sortie générée par ce plugin. Si un développeur configure mal l’orchestrateur pour qu’il réinjecte aveuglément les sorties du plugin non validées dans le contexte du LLM ou directement dans une interface web, il crée un vecteur pour l’empoisonnement d’outil et le Cross-Site Scripting (XSS).
Pour lutter contre la crise de sécurité cloud de 2026, l’industrie doit dépasser les déploiements d’agents ad hoc et adopter l’AI Security Posture Management (AI-SPM).
Tout comme les outils de Cloud Security Posture Management (CSPM) ont révolutionné la façon dont nous auditons AWS et Azure, les organisations doivent déployer une gouvernance automatisée sur leur infrastructure IA.
*) ou un accès en écriture à des bases de données critiques doit déclencher des alertes de conformité de haute priorité.Les centres opérationnels de sécurité (SOC) doivent chasser de manière proactive les symptômes des mauvaises configurations de l’IA.
title: Accès non authentifié à un serveur MCP exposéid: e3f4g5h6-7a8b-9c0d-1e2f-3a4b5c6d7e8fstatus: experimentaldescription: Détecte les tentatives de reconnaissance externe ou d'exploitation ciblant des points de terminaison Model Context Protocol (MCP) non authentifiés (/mcp ou /sse) sur une infrastructure exposée publiquement.logsource: category: webserver product: linuxdetection: selection: c-uri|contains: - '/mcp' - '/sse' - '/tools/list' - '/resources/list' filter_internal: # Exclure le trafic d'orchestration interne légitime c-ip|cidr: - '10.0.0.0/8' - '172.16.0.0/12' - '192.168.0.0/16' - '127.0.0.0/8' condition: selection and not filter_internallevel: hightags: - attack.initial_access - attack.t1190// Détecte un Principal de Service d'Agent IA tentant d'accéder à des ressources cloud// en dehors de sa ligne de base prévue, indiquant soit une mauvaise configuration// soit une attaque par détournement de fonction réussie exploitant des permissions excessives.CloudAppEvents| where Application == "Microsoft Azure" or Application == "AWS"// Filtrer pour les comptes de service spécifiques aux agents IA| where AccountDisplayName has_any ("svc_ai_", "copilot_backend", "mcp_runner")| summarize AccessedResources = make_set(ObjectName), ActionCount = count() by AccountDisplayName, ActionType, bin(TimeGenerated, 1h)// Chasser les actions administratives anormales ou les lectures en masse| where ActionType has_any ("ListBuckets", "ListRolePolicies", "DescribeInstances", "DeleteTable")| project TimeGenerated, AccountDisplayName, ActionType, AccessedResources, ActionCount| sort by TimeGenerated descLes brèches IA les plus dévastatrices de 2026 et au-delà ne seront pas le résultat d’une inversion de gradient mathématique hautement sophistiquée. Elles seront le résultat d’un développeur exécutant un serveur MCP sur 0.0.0.0 sans authentification, armé d’une clé racine AWS.
Au fur et à mesure que nous déployons l’IA Agentique, nous devons nous rappeler qu’un agent IA est fondamentalement un logiciel. Il requiert la même gouvernance d’infrastructure rigoureuse, la même application du moindre privilège IAM et les mêmes configurations sécurisées par défaut que n’importe quel autre microservice.
En reconnaissant les mauvaises configurations de l’IA comme le prochain défi majeur de la gouvernance des infrastructures, les organisations peuvent cesser de courir après les “hacks” d’ingénierie de prompt et commencer à construire des systèmes véritablement résilients au niveau de la couche d’orchestration.