.jpg) Donner à une IA l'accès direct à vos emails, votre CRM ou votre base de données change radicalement la donne en matière de sécurité. Le protocole MCP (Model Context Protocol), lancé par Anthropic fin 2024, a rendu cette connexion tellement simple que des dizaines de milliers d'organisations l'ont adopté en quelques mois, souvent plus vite que leurs équipes sécurité n'ont pu l'évaluer. Ce guide fait le point sur les risques réels, sans catastrophisme, et sur les mesures concrètes pour les maîtriser. ## 1. Qu'est-ce que le MCP et pourquoi change-t-il la surface de risque ? Le MCP est un protocole ouvert qui standardise la façon dont un assistant IA se connecte à des outils, des bases de données ou des services externes. Concrètement, il fonctionne comme un port USB-C universel pour l'IA : au lieu de coder une intégration sur mesure pour chaque logiciel (Gmail, Slack, Notion, une base SQL interne), l'agent IA se connecte à un serveur MCP qui expose ces capacités dans un format standardisé. L'IA n'est alors plus un simple outil de génération de texte, elle devient capable d'agir : lire un fichier, interroger une base de données, envoyer un email, déclencher un virement ou modifier un enregistrement client. Cette bascule change fondamentalement le modèle de sécurité. Un chatbot classique qui répond à des questions ne présente qu'un risque limité : au pire, il génère un texte incorrect. Un agent connecté via MCP à votre CRM, votre messagerie et vos outils financiers, lui, peut exécuter de vraies opérations. Le MCP crée un pont direct entre le raisonnement d'un modèle de langage et l'infrastructure de l'entreprise, ce qui élimine les frontières de sécurité traditionnelles fondées sur l'isolation des systèmes. La spécification officielle du protocole est d'ailleurs explicite sur ce point : elle indique ne pas appliquer de sécurité au niveau du protocole lui-même, laissant l'entière responsabilité de l'implémentation aux équipes qui déploient les serveurs MCP. L'autre nouveauté, c'est l'autonomie. Un agent IA équipé d'outils MCP peut enchaîner plusieurs actions de façon indépendante pour accomplir une tâche complexe : rechercher une information, la croiser avec une autre source, puis agir sur cette base. Cette capacité à raisonner et agir sur plusieurs étapes est précisément ce qui rend le MCP puissant pour l'automatisation de workflows métier, mais c'est aussi ce qui élargit ce que les experts appellent le « rayon d'explosion » (blast radius) d'une compromission : plus l'agent a d'accès et d'autonomie, plus les conséquences d'une erreur ou d'une attaque sont importantes.  ## 2. Quels sont les 5 risques concrets du MCP en entreprise ? Les recherches en sécurité convergent vers 5 catégories de risques majeurs, toutes documentées par des incidents réels survenus depuis 2025. Voici chacune, avec son mécanisme précis. **Accès sur-privilégié.** Quand une équipe connecte un agent IA à un système, elle utilise souvent par commodité des identifiants larges (clé API admin, compte de service) plutôt que des permissions restreintes, pour éviter les erreurs d'autorisation pendant le développement. Le problème, c'est que ces privilèges larges ne sont presque jamais réduits une fois l'agent en production. C'est exactement ce qui s'est produit lors de l'incident Supabase de juin 2025 : un agent Cursor disposant d'un accès privilégié au niveau service a traité un ticket de support contenant du contenu malveillant, ce qui a permis l'exfiltration de jetons d'intégration. Un agent limité en lecture seule sur des données de support n'aurait jamais eu les permissions nécessaires pour causer cette fuite. **Injection de prompt indirecte.** Considéré comme le risque numéro 1 du classement OWASP Top 10 des applications LLM, ce vecteur d'attaque ne nécessite aucun accès direct à vos systèmes. L'attaquant cache des instructions malveillantes dans un contenu que l'agent va traiter normalement : un email, un PDF, une page web, un fichier partagé sur un dépôt de code. Comme un modèle de langage ne fait pas de distinction stricte entre les données qu'il lit et les instructions qu'il doit exécuter, il peut interpréter ce contenu piégé comme un ordre légitime et agir en conséquence, avec ses propres permissions, parfois sans même informer l'utilisateur de cette action supplémentaire.  **Empoisonnement d'outil (tool poisoning).** Un serveur MCP malveillant ou compromis peut inclure des instructions cachées directement dans la description d'un outil, invisibles à l'œil nu mais interprétées par l'agent lors de la découverte des capacités disponibles. Invariant Labs a démontré une variante de cette attaque en exploitant un serveur MCP WhatsApp compromis pour exfiltrer silencieusement l'intégralité d'un historique de messages. Une variante encore plus sournoise, le « rug pull », consiste à faire approuver un outil au comportement normal, puis à modifier silencieusement sa définition après coup : la plupart des clients MCP ne détectent pas ce changement. **Prolifération de credentials.** Un serveur MCP centralise souvent les jetons OAuth de plusieurs services (messagerie, calendrier, stockage cloud), ce qui en fait un point de défaillance unique. Un seul serveur compromis peut donner accès à l'ensemble des services connectés, un scénario que les chercheurs qualifient de « clés du royaume ». Des chercheurs en sécurité ont recensé 492 serveurs MCP exposés publiquement sans authentification de base, et une faille critique dans le proxy OAuth mcp-remote (plus de 437 000 téléchargements) a permis l'exécution de commandes arbitraires à distance sur la machine cliente. **Angles morts d'audit.** Sans journalisation structurée attribuant chaque action à un utilisateur identifié, une équipe sécurité ne peut ni détecter une activité anormale en temps réel, ni reconstituer une chronologie d'attaque après coup. C'est un problème de conformité autant que de sécurité : le RGPD impose de pouvoir démontrer quelle donnée a été traitée, quand et par qui. Une étude 2025 sur les usages IA en entreprise a montré que moins de 15 % des systèmes étaient capables de reconstituer intégralement le parcours de décision d'un agent après un incident. Le tableau ci-dessous synthétise ces 5 risques et leur impact documenté. | Risque | Mécanisme | Incident documenté | |---|---|---| | Accès sur-privilégié | Permissions larges non réduites en production | Supabase / Cursor, juin 2025 | | Injection de prompt indirecte | Instructions cachées dans un contenu traité par l'agent | Invariant Labs, exfiltration WhatsApp | | Empoisonnement d'outil | Métadonnées d'outil manipulées pour tromper l'agent | Serveurs MCP tiers non audités | | Prolifération de credentials | Jetons OAuth stockés sans gestion centralisée | 492 serveurs MCP exposés sans authentification | | Angles morts d'audit | Absence de logs structurés attribuables à un utilisateur | Moins de 15 % des systèmes capables de reconstituer une chaîne de décision | ## 3. Comment sécuriser concrètement vos usages du MCP ? La bonne nouvelle, c'est que ces 5 risques se traitent avec 4 mesures structurées, sans renoncer aux gains de productivité du MCP. **Appliquer le principe du moindre privilège au niveau de chaque outil.** La granularité doit descendre sous le niveau du serveur : un agent de support client doit pouvoir consulter des données CRM en lecture, jamais déclencher une suppression ou un virement. Cette approche neutralise directement le risque d'accès sur-privilégié : un agent scopé en lecture seule n'aurait jamais eu les permissions nécessaires pour reproduire l'incident Supabase. **Exiger une validation humaine pour toute action irréversible.** Suppression en base, transfert de données externe, transaction financière, communication sortante en masse : la spécification MCP recommande elle-même qu'un humain reste toujours dans la boucle avec la capacité de refuser l'exécution d'un outil. C'est aussi la mitigation la plus efficace contre l'injection de prompt indirecte : une instruction malveillante qui ne peut pas s'exécuter sans validation humaine ne peut pas exfiltrer de données silencieusement, même si elle a réussi à tromper le modèle en amont. > « Le problème persistant de l'injection de prompt, c'est que nous connaissons cette faille depuis plus de deux ans et demi et que nous n'avons toujours pas de mitigation vraiment convaincante. » — Simon Willison, chercheur en sécurité informatique **Centraliser les connexions dans un registre gouverné.** Des connexions point-à-point gérées équipe par équipe créent exactement les angles morts qui permettent l'empoisonnement d'outil et la prolifération de credentials : personne n'a de vue d'ensemble sur qui a accès à quoi. Un registre centralisé permet de détecter tout changement de comportement d'un outil après son approbation, et d'appliquer une politique d'accès cohérente sur l'ensemble des serveurs connectés. .webp) **Journaliser chaque interaction de façon structurée.** L'identité de l'utilisateur, l'agent exécutant, l'outil appelé et les arguments passés doivent être enregistrés systématiquement : c'est la condition sine qua non pour combler les angles morts d'audit et satisfaire des exigences de conformité comme le RGPD. Ces 4 principes de gouvernance et de supervision d'agents autonomes, cartographie des flux, permissions par outil, points de contrôle humains, journalisation, sont précisément ce qu'apprend à mettre en œuvre la formation [Automatiser ses workflows et créer des agents IA](https://www.travelearn.fr/formation/automatiser-ses-workflows-et-crer-des-agents-ia), pour concevoir des agents à la fois utiles et maîtrisés dès la phase de conception plutôt qu'en réaction à un incident. ## FAQ **Le MCP est-il intrinsèquement dangereux à utiliser en entreprise ?** Non. Le protocole en lui-même n'est ni sûr ni dangereux : sa sécurité dépend entièrement des contrôles mis en place autour de son implémentation, permissions, authentification, supervision humaine. Un déploiement MCP bien gouverné avec accès restreints et logs structurés réduit fortement les risques documentés. **Faut-il éviter de connecter une IA à des données sensibles ?** Pas nécessairement, mais cela impose une gouvernance préalable : cartographier précisément quelles données et actions sont accessibles, appliquer le principe du moindre privilège et prévoir une validation humaine pour toute action irréversible avant d'ouvrir l'accès. **Comment une PME sans équipe sécurité dédiée peut-elle démarrer ?** En commençant petit : limiter les permissions de chaque agent au strict nécessaire, activer les logs disponibles nativement dans les outils utilisés, et exiger une confirmation manuelle pour toute action sensible (envoi, suppression, paiement) plutôt que de tout automatiser d'un coup. --- **Sources** - [Model Context Protocol (MCP) Security: Complete Guide](https://www.sentinelone.com/cybersecurity-101/cybersecurity/mcp-security/) - [MCP Security Risks & Best Practices in 2026](https://www.truefoundry.com/blog/mcp-security-risks-best-practices) - [Model Context Protocol Security Explained](https://www.wiz.io/academy/ai-security/model-context-protocol-security) - [Prompt Injection Meets MCP: A New Exploitation Vector Emerging?](https://labs.snyk.io/resources/prompt-injection-mcp/) - [Plug, Play, and Prey: The security risks of the Model Context Protocol](https://techcommunity.microsoft.com/blog/microsoftdefendercloudblog/plug-play-and-prey-the-security-risks-of-the-model-context-protocol/4410829)