Protocole de Contexte Modèle : Risques de Sécurité et Atténuations

L’adoption de l’IA progresse rapidement, passant des projets pilotes à la pratique quotidienne au niveau de l’infrastructure. La courbe budgétaire reflète ce changement. Gartner prévoit que les dépenses mondiales en IA atteignent 2,52 billions de dollars en 2026, soit une augmentation de 44 % d’une année sur l’autre. En même temps, les dépenses pour la cybersécurité IA devraient croître de plus de 90 % en 2026, signal clair que plus l’IA est intégrée profondément dans les opérations commerciales, plus la surface d’attaque devient grande.

À mesure que les organisations opérationnalisent les LLM, le véritable défi passe de la qualité de réponse à l’exécution sécurisée. Il ne suffit plus qu’un modèle explique quoi faire. Dans de nombreux environnements, la valeur vient de l’action, de l’extraction du bon contexte et de l’interaction avec les systèmes où le travail se fait. Cela inclut les dépôts de code, les plates-formes de ticketing, les outils SaaS, les bases de données et les services internes.

Avant le protocole de contexte de modèle, chaque intégration d’outil était comme construire un câble sur mesure différent pour chaque appareil, puis découvrir que chaque fournisseur de LLM utilisait une fiche légèrement différente. Le MCP standardise le connecteur et le format du message ; par conséquent, les outils peuvent exposer des capacités une fois, et plusieurs modèles peuvent les utiliser de manière cohérente. Le résultat est un développement plus rapide, moins d’intégrations sur mesure et un entretien à long terme réduit à mesure que l’adoption se propage dans l’écosystème.

Ce changement est déjà visible dans les assistants IA axés sur la cybersécurité. Par exemple, Uncoder AI de SOC Prime est alimenté par des outils MCP qui transforment un LLM en copilote de cybersécurité contextuellement conscient, facilitant l’intégration, la flexibilité des fournisseurs, les connexions préconstruites, et une gestion plus contrôlée des données. Par exemple, le MCP permet des recherches sémantiques à travers le Threat Detection Marketplace, trouvant rapidement des règles pour des sources de logs spécifiques ou des types de menaces, et réduisant le temps de recherche manuel. Tout cela est soutenu par la confidentialité et la sécurité au cœur.

Pourtant, en général, lorsque le MCP devient une voie commune entre les agents et les systèmes critiques, chaque serveur, connecteur, et périmètre de permission devient pertinent pour la sécurité. Des jetons trop larges, une isolation faible, et des pistes d’audit incomplètes peuvent transformer la commodité en exposition de données, actions involontaires, ou mouvements latéraux.

Ce guide explique comment le MCP fonctionne, puis se concentre sur les risques de sécurité pratiques et les atténuations.

Qu’est-ce que le MCP ?

Depuis sa publication et mise en open-source par Anthropic en novembre 2024, le protocole de contexte de modèle a rapidement pris de l’ampleur en tant que couche connective entre les agents IA et les outils, API, et données dont ils dépendent.

Au cœur, le MCP est un moyen standardisé pour les applications alimentées par LLM de communiquer avec les systèmes externes de manière cohérente et contrôlée. Il déplace les assistants IA au-delà des connaissances statiques du temps d’entraînement en leur permettant de récupérer un contexte frais et d’exécuter des actions via des interfaces approuvées. Le résultat pratique est un agent IA qui peut être plus précis et utile, car il peut travailler avec des données opérationnelles réelles.

Composants clés

Protocole de Contexte de Modèle architecture est construit autour d’un ensemble simple de blocs qui coordonnent la façon dont un LLM découvre des capacités externes, extrait le bon contexte, et échange des requêtes et réponses structurées avec les systèmes connectés.

• Hôte MCP. L’environnement où le LLM fonctionne. Les exemples incluent un IDE alimenté par l’IA ou une interface conversationnelle intégrée dans un produit. L’hôte gère la session utilisateur et décide quand un contexte ou des actions externes sont nécessaires.
• Client MCP. Un composant à l’intérieur de l’hôte qui gère la communication protocolaire. Il découvre les serveurs MCP, demande des métadonnées sur les capacités disponibles, et traduit l’intention du modèle en requêtes structurées. Il renvoie également les réponses à l’hôte sous une forme que l’application peut utiliser.
• Serveur MCP. Le service externe qui fournit contexte et capacités. Il peut accéder à des sources de données internes, plateformes SaaS, outils de sécurité spécialisés, ou flux de travail propriétaires. C’est là que les organisations appliquent généralement des autorisations spécifiques au système, le filtrage des données, et des garde-fous opérationnels.
  
  

Couches

• Couche de données. Cette couche interne est basée sur le protocole JSON-RPC et gère la communication client-serveur. Elle couvre la gestion du cycle de vie et les primitives de base que MCP expose, y compris les outils, ressources, invites, et notifications.
• Couche de transport. Cette couche externe définit comment les messages se déplacent réellement entre les clients et les serveurs. Elle spécifie les mécanismes et canaux de communication, y compris la configuration de connexion spécifique au transport, l’encadrement des messages, et l’autorisation.
  
  

Conceptuellement, la couche de données fournit le contrat et la sémantique, tandis que la couche de transport fournit la connectivité et le chemin d’application pour un échange sécurisé.

Comment le MCP fonctionne-t-il ?

Le MCP se situe entre le LLM et les systèmes externes que votre agent prévoit d’utiliser. Au lieu de donner au modèle un accès direct aux bases de données, applications SaaS, ou services internes, le MCP expose des capacités approuvées en tant qu’outils et fournit une manière standard de les appeler. Le LLM se concentre sur la compréhension de la requête et décide quoi faire ensuite. Le MCP gère la découverte des outils, leur exécution, et le retour des résultats dans un format prévisible.

Un flux typique peut ressembler à celui ci-dessous :

• L’utilisateur pose une question ou donne une tâche. L’invite arrive dans l’application AI, également appelée l’hôte MCP.
• Découverte des outils. Le client MCP vérifie un ou plusieurs serveurs MCP pour voir quels outils sont disponibles pour cette session.
• Injection de contexte. Le MCP ajoute des détails pertinents sur l’outil à l’invite, afin que le LLM sache ce qu’il peut utiliser et comment l’appeler.
• Génération d’appel d’outil. Le LLM crée une requête d’outil structurée, essentiellement un appel de fonction avec des paramètres.
• Exécution dans le service en aval. Le serveur MCP reçoit la requête et l’exécute contre le système cible, souvent via une API telle que REST.
• Résultats retournés et utilisés. La sortie revient à l’application IA. Le LLM peut l’utiliser pour faire un autre appel ou écrire la réponse finale.
  
  

Voici un exemple simple de fonctionnement dans Uncoder AI. Vous demandez : “Trouvez des détections pour le dumping de crédentiels qui fonctionnent avec les journaux de sécurité Windows.”

• Le LLM réalise qu’il a besoin d’accéder à une bibliothèque de détection, pas seulement à sa propre connaissance.
• Grâce au MCP, Uncoder AI appelle l’outil de recherche de détection pertinent connecté au Threat Detection Marketplace de SOC Prime.
• Le serveur MCP effectue la recherche et renvoie une courte liste de détections correspondantes.
• Uncoder AI analyse ensuite les résultats et répond avec une liste courte et propre de cinq règles de détection.

Risques et vulnérabilités du MCP

Le protocole de contexte de modèle élargit ce qu’un LLM peut faire en le connectant à des outils, API, et données opérationnelles. Cette capacité est la valeur, mais elle est aussi le risque. Une fois qu’un assistant peut récupérer un contexte interne et déclencher des actions via des services connectés, le MCP devient une partie de votre plan de contrôle. La posture de sécurité n’est plus définie par le modèle seul, mais par les serveurs que vous approuvez, les autorisations que vous accordez, et les garde-fous que vous appliquez autour de l’utilisation des outils.

Considérations clés sur la sécurité du MCP

Les serveurs MCP servent de liaison entre les hôtes et un large éventail de systèmes externes, potentiellement non fiables ou risqués. Comprendre votre exposition nécessite une visibilité sur ce qui se trouve de chaque côté de la frontière du serveur, quels hôtes et clients LLM l’appellent, comment le serveur est configuré, quels serveurs tiers sont activés, et quels outils le modèle peut réellement invoquer en pratique.

• Problème de Député Confus. Si un serveur MCP peut agir avec des privilèges plus larges que l’utilisateur, il peut exécuter des actions que l’utilisateur ne devrait pas être autorisé à déclencher. Le modèle sécurisé est que le serveur agit au nom de l’utilisateur avec son consentement explicite et des périmètres de moindre privilège, et non avec une identité de service globale.
• Passage de Jetons. Passer des jetons clients aux API en aval sans validation appropriée brise les frontières de confiance et peut déjouer le contrôle du public. Les directives MCP traitent cela comme un anti-modèle à haut risque car cela rend l’autorisation ambiguë et difficile à auditer.
• Détournement de session et injection d’événements. Les connexions avec état peuvent être abusées si des identifiants de session peuvent être volés, rejoués, ou repris par un attaquant. La gestion sécurisée des sessions est importante car les appels d’outils deviennent une séquence, pas une demande unique, et les attaquants ciblent le maillon le plus faible de cette chaîne.
• Compromission du serveur MCP local. Les serveurs locaux peuvent être puissants, et ce pouvoir agit dans les deux sens. Les risques incluent l’exécution de code non fiable, un comportement de démarrage non sécurisé et l’exposition d’un service local de manière à ce qu’un autre site ou processus puisse y accéder. Les déploiements locaux nécessitent un bac à sable, un lien strict, et des paramètres par défaut sécurisés.
• Échecs de minimisation de la portée. Des portées trop larges augmentent le rayon d’explosion et affaiblissent la gouvernance. Les spécifications soulignent les pièges de conception de la portée, tels que la surcharge d’une seule portée pour de nombreuses opérations ou la publicité d’un support de portée excessive. Les périmètres de moindre privilège et une séparation claire des capacités de lecture et d’écriture sont essentiels.
  
  

De nombreux risques MCP correspondent à des fondamentaux de sécurité familiers ; par conséquent, les serveurs MCP doivent être traités comme toute autre surface d’intégration. Les organisations doivent appliquer des contrôles de la chaîne d’approvisionnement, analyser le code et les dépendances, épingler les versions, et examiner les modifications avant la publication. Il est également important de renforcer les points de terminaison avec une authentification et une autorisation solides, des limites de taux, et des paramètres sécurisés par défaut. Ces pratiques éliminent une grande part des échecs évitables.

La spécification MCP fournit une liste de meilleures pratiques de sécurité, avec des modèles d’attaque courants et des atténuations pratiques que vous pouvez appliquer lors de la création ou de l’exploitation d’hôtes, de clients et de serveurs MCP.

Risques de sécurité principaux du MCP

Pour rendre la liste exploitable, il est utile de regrouper les menaces MCP dans les modèles de risque les plus courants que les défenseurs voient dans les déploiements réels.

Injection d’Invite

Les attaquants fabriquent des entrées qui poussent l’assistant à utiliser des outils de manière non sécurisée ou à divulguer des données sensibles.

Conseil d’atténuation : Restreindre l’accès aux outils, appliquer des politiques d’appel, et surveiller l’utilisation des outils pour des modèles anormaux.

Injection d’Invite Indirecte

Des instructions hostiles peuvent arriver via du contenu récupéré et être traitées comme une intention de confiance.

Conseil d’atténuation : Séparer le contenu non fiable, le désinfecter, et empêcher les outils d’être invoqués sur la base d’instructions trouvées dans des données externes.

Empoisonnement d’Outil

Les descriptions, paramètres, ou valeurs par défaut des outils peuvent être manipulés pour orienter les décisions du modèle.

Conseil d’atténuation : Traiter les métadonnées de l’outil comme une entrée non fiable, réviser les définitions des outils comme du code, et exiger des vérifications d’intégrité avant les mises à jour.

Masquage d’Outil et Collision de Noms d’Outils

Des outils ressemblants peuvent usurper des outils légitimes et capter des demandes.

Conseil d’atténuation : Maintenir une liste blanche des serveurs et outils approuvés, et échouer fermement quand une identité d’outil ne peut pas être vérifiée.

Échecs d’Autorisation du Député Confus

Un serveur exécute des actions en utilisant ses privilèges larges plutôt que des permissions liées à l’utilisateur.

Conseil d’atténuation : Utiliser un consentement explicite, appliquer des périmètres liés à l’utilisateur, et valider les jetons selon les directives d’autorisation MCP requises.

Passage de Jetons et Validation Faible des Jetons

Transmettre des jetons ou accepter des jetons sans validation appropriée de l’audience sape l’autorisation.

Conseil d’atténuation : Interdire le passage, valider l’audience des jetons, et suivre le flux basé sur OAuth défini pour les transports HTTP.

Détournement de Session

Les attaquants exploitent des sessions ré-exécutables ou des identifiants volés pour injecter des événements ou usurper un client.

Conseil d’atténuation : Lier fermement les sessions, faire tourner les identifiants, appliquer des délais d’expiration, et enregistrer les reprises et les anomalies.

Compromission du Serveur Local

Les serveurs MCP locaux peuvent être utilisés pour accéder à des fichiers, exécuter des commandes, ou pivoter vers d’autres ressources s’ils ne sont pas isolés.

Conseil d’atténuation : Mettre en bac à sable les serveurs locaux, minimiser les privilèges du système d’exploitation, restreindre l’accès au système de fichiers, et éviter d’exposer les services locaux au-delà de ce qui est nécessaire.

Portées Excessives et Rampe des Autorisations

Les portées larges créent des accès involontaires, et les permissions tendent à s’accumuler au fil du temps.

Conseil d’atténuation : Diviser les outils de lecture et d’écriture, réviser régulièrement les portées, et garder les ensembles de portées minimaux et spécifiques à la tâche.

Manque d’Auditabilité et Réponse Faible aux Incidents

Si vous ne pouvez pas corréler les invites, appels d’outils, jetons, et actions en aval, les enquêtes deviennent devinettes.

Conseil d’atténuation : Centraliser les journaux, attacher des ID de corrélation, et enregistrer l’intention des appels d’outils, et les paramètres et résultats dans un format compatible SIEM.

La conclusion pratique est que le MCP doit être sécurisé comme une couche d’intégration à fort impact. Supposer que les sorties des outils ne sont pas fiables, minimiser les autorisations, appliquer une identité et autorisation solides, et investir tôt dans la surveillance qui peut lier les invites aux appels d’outils et actions en aval.

SOC Prime suit les meilleures pratiques de sécurité et de confidentialité établies pour protéger les clients et assurer le fonctionnement fiable de la plateforme SOC Prime et des capacités habilitées par l’IA. L’équipe de SOC Prime a également créé et mis en open source Bastion AI/DR, un système de protection GenAI complet conçu pour se protéger contre les invites malveillantes, les attaques par injection, et le contenu nuisible. Le système intègre plusieurs moteurs de détection qui fonctionnent séquentiellement pour analyser et classer les entrées utilisateur avant qu’elles n’atteignent les applications GenAI.

En outre, la plateforme SOC Prime prend en charge l’intégration avec AIDEFEND (Cadre de Défense de l’Intelligence Artificielle), une base de connaissances ouverte et axée sur l’IA pour les contre-mesures défensives contre les menaces IA/ML émergentes. Soutenu par Uncoder AI, la MCP natif AIDEFEND rend ces connaissances immédiatement exploitables. Les professionnels de la sécurité peuvent demander des défenses contre des menaces spécifiques, extraire des conseils techniques détaillés, générer des listes de contrôle rapides, ou extraire des extraits de code sécurisé pour implémenter des contrôles plus rapidement et avec moins de recherche.

Quel est l’avenir de la sécurité MCP ?

Les préoccupations de sécurité autour du MCP sont valables, mais la standardisation est aussi une grande opportunité pour améliorer le contrôle. À mesure que l’adoption du MCP croît, les organisations obtiennent une surface de sécurité plus cohérente où elles peuvent appliquer les mêmes politiques et surveillances à travers l’utilisation des outils, au lieu de sécuriser une intégration personnalisée différente pour chaque modèle et chaque système en aval.

Vers l’avenir, la sécurité du MCP mûrira dans quelques directions prévisibles :

• Sécuriser les blocs de construction MCP. La sécurité du MCP se concentrera de plus en plus sur les primitives du protocole qui définissent ce qu’un agent peut faire. Les outils sont des fonctions exécutables et nécessitent des permissions strictes et des règles claires pour savoir quand ils peuvent fonctionner. Les ressources agissent comme des conteneurs de données et nécessitent un contrôle d’accès et une validation pour réduire les fuites et les empoisonnements. Les invites influencent le comportement et doivent être protégées avec des solutions, comme AI/DR Bastion, contre l’injection et la modification non autorisée.
• Rendre l’identité obligatoire pour le MCP à distance. Pour tout serveur MCP en réseau, l’authentification doit être traitée comme une exigence de base. Les équipes ont besoin d’un modèle d’identité clair qui répond à qui fait l’appel, ce qu’elles sont autorisées à faire, et quel consentement a été accordé. Cela aide également à prévenir les échecs courants soulignés dans la spécification, comme le comportement de député confus et les modèles de gestion des jetons risqués.
• Appliquer la politique en utilisant le contexte complet. Les listes blanches sont utiles, mais les flux de travail des agents ont besoin de garde-fous plus riches. L’invite, l’utilisateur, l’outil sélectionné, les paramètres de l’outil, et le système cible doivent tous influencer ce qui est autorisé. Avec ce contexte, vous pouvez restreindre les opérations risquées, limiter la récupération de données sensibles, bloquer les modèles de paramètres non sécurisés, et exiger des vérifications supplémentaires lorsque le niveau de risque est élevé.
• Considérer la surveillance comme un contrôle central. À mesure que les agents enchaînent les actions, l’enquête dépend de la capacité à tracer le comportement de bout en bout. Une base pratique est la journalisation qui corrèle les invites, la sélection d’outils, les entrées d’outils, les sorties d’outils, et les requêtes en aval. Sans ce lien, il est difficile d’auditer les actions ou de répondre rapidement lorsqu’un problème survient.
• Ajouter des portes d’approbation pour les actions à fort impact. Pour les actions qui créent, modifient, suppriment, paient, ou escaladent les privilèges, une révision humaine reste essentielle. Les déploiements MCP matures ajouteront des étapes d’approbation explicites qui suspendent l’exécution jusqu’à ce qu’un utilisateur ou un flux de travail de sécurité confirme l’action. Cela réduit la surface d’attaque à la fois pour les incitations malveillantes et l’utilisation accidentelle d’outils.
• Vérifier les serveurs et contrôler les mises à jour. À mesure que l’écosystème s’étend, la confiance et la provenance deviennent obligatoires. Les organisations compteront de plus en plus sur des serveurs MCP approuvés, une intégration contrôlée, et une gestion stricte des changements pour les mises à jour. L’épinglage de version, les vérifications d’intégrité, et la numérisation des dépendances sont importants parce que les serveurs MCP sont du code exécutable, et le comportement des outils peut changer au fil du temps, même si les interfaces semblent stables.
• Garder les fondamentaux au premier plan. Même avec des contrôles spécifiques au MCP, les pratiques de sécurité les plus courantes restent les bases. Le moindre privilège, les périmètres clairs, la gestion sécurisée des sessions, l’authentification forte, les points d’extrémité renforcés, et la journalisation complète des audits éliminent une grande part du risque réel. Utilisez la liste des meilleures pratiques de sécurité MCP comme une liste de contrôle permanente, puis ajoutez des contrôles basés sur votre environnement et votre appétit pour le risque.
  
  

À mesure que le MCP se propage à travers plus d’assistants et d’outils, la sécurité devient la différence entre un copilote utile et un moteur d’automatisation non contrôlé. Le chemin le plus sûr est simple : traiter le MCP comme une infrastructure privilégiée, garder les autorisations serrées, et rendre chaque appel d’outil visible et traçable. Faites-le bien, et le MCP peut mettre à l’échelle les flux de travail des agents avec confiance au lieu de transformer la vitesse en risque.