Les 6 risques de sécurité MCP auxquels toute entreprise est confrontée en 2026

Pourquoi MCP a changé la question de sécurité

Avant que les agents ne disposent d'outils, la sécurité IA portait principalement sur le contenu : ce prompt tente-t-il de manipuler le model ? Cette réponse divulgue-t-elle des informations qui devraient rester confidentielles ? Ces questions restent pertinentes. Mais le Model Context Protocol en a ajouté une seconde, plus critique : que cet agent est-il concrètement autorisé à faire ?

Il s'agit d'un risque d'une autre nature. Un outil n'est pas du texte : il peut écrire des fichiers, ouvrir des connexions réseau, modifier un dépôt, appeler une API payante ou lire les données d'un système sensible. Comme l'indique la documentation sur la sécurité MCP d'Odock, l'accès MCP doit être traité comme un accès runtime à des capacités, et non comme une simple fonctionnalité pratique. Le cadre de sécurité devient alors clair : vous gouvernez des capacités, dont chacune doit être délimitée.

Les recherches menées en 2026 font régulièrement ressortir les mêmes modes de défaillance. Voici les principaux, accompagnés du contrôle qui permet de maîtriser chacun d'eux.

Risque 1 : accès sur-privilégié des agents

Le problème MCP le plus courant est aussi le plus banal : les agents obtiennent davantage d'accès que nécessaire. Une fois un serveur connecté, chaque agent qui peut l'atteindre est susceptible d'appeler tous les outils qu'il expose. Une intention read-only se transforme alors discrètement en capacité d'écriture. Le principe du moindre privilège, appliqué depuis des décennies aux comptes humains par les équipes de sécurité, disparaît souvent dès qu'un agent IA entre en jeu.

La solution consiste à rendre l'accès explicite et strictement limité. Dans Odock, la simple présence d'un serveur MCP dans l'organisation ne suffit pas à le rendre accessible. Une virtual API key doit disposer d'un access grant MCP explicite pour ce serveur précis, et l'accès peut être davantage restreint par scope d'équipe ou de clé. En complément du grant, les paramètres de gouvernance définissent les allowed tools et les blocked tools. Une clé qui n'a besoin que d'un outil de lecture n'hérite donc pas implicitement d'une dizaine d'outils d'écriture. Pour plus de détails, consultez la documentation sur la sécurité MCP.

Risque 2 : indirect prompt injection par les outils

La prompt injection directe se produit lorsqu'un utilisateur saisit un contenu malveillant. L'indirect prompt injection est plus insidieuse : l'instruction malveillante se trouve dans les données que l'agent récupère au moyen d'un outil. Un document, une page web, une ligne de base de données ou un commentaire d'issue peut contenir des instructions cachées que le model interprète comme des commandes. L'utilisateur n'a commis aucune erreur, mais le payload parvient tout de même au model.

L'inspection du contenu des requêtes ne peut donc pas constituer l'unique ligne de défense. Il faut également inspecter les données renvoyées par les outils et limiter le contenu autorisé dans les tool calls. Odock applique des semantic filters aux payloads MCP au runtime et exécute son moteur SafetySec sur le contenu des requêtes et des réponses. Les instructions injectées par l'intermédiaire d'un outil peuvent ainsi être détectées avant d'orienter une action. La prompt injection reste en tête de la liste OWASP LLM précisément parce que le retrieval et les outils ne l'éliminent pas. Nous approfondissons ce sujet dans notre article sur la prompt injection, les fuites de données et le rôle des guardrails dans la gateway.

Risque 3 : tool poisoning et rug pulls

Le tool poisoning est un risque introduit par MCP qui n'a pas d'équivalent direct dans le monde antérieur aux agents. Au lieu d'attaquer le prompt, l'attaquant manipule l'outil : sa description, ses métadonnées, ses paramètres ou son comportement. Une description empoisonnée peut contenir des instructions que le model considère comme un contexte de confiance. Des chercheurs en sécurité ont démontré que des attaques de tool poisoning pouvaient exfiltrer silencieusement l'intégralité de l'historique de conversation d'un utilisateur, credentials et tokens compris, sans jamais lui présenter de prompt suspect.

La variante rug pull agit de manière différée. Un outil se comporte correctement pendant sa revue et son approbation, puis change de comportement une fois considéré comme fiable. Il s'agit d'un problème de supply chain appliqué aux agents.

La défense comporte deux volets. Il faut d'abord contrôler la provenance en ne connectant que des serveurs MCP issus de sources fiables. C'est pourquoi Odock permet d'ajouter des serveurs depuis un catalogue de confiance plutôt que depuis des endpoints arbitraires. Il faut ensuite contraindre leur comportement au runtime, quel que soit le niveau de confiance accordé. Les listes d'allowed et blocked tools, les semantic filters appliqués aux payloads et l'inspection des tool calls permettent de maintenir dans un périmètre contrôlé tout outil qui commencerait à se comporter de manière anormale. Le contexte du modèle de menace est détaillé dans notre article sur la sécurité IA en 2026.

Risque 4 : dispersion des credentials et point unique de défaillance

Les serveurs MCP ont tendance à agréger des credentials. Un même serveur peut détenir des accès à une base de données, à un système de fichiers, à un compte cloud et à une API tierce, car c'est précisément ce qui le rend utile. Mais cette agrégation le rend également dangereux. Un serveur MCP déployé sans contrôles d'authentification appropriés devient un point unique de défaillance capable d'exposer tous les systèmes auxquels il est intégré. Sa compromission ne touche pas un seul service, mais potentiellement l'ensemble de ces systèmes.

La mitigation consiste à empêcher la dispersion des credentials sur des serveurs non gouvernés et à placer une frontière contrôlée en amont. Odock gère l'authentification MCP upstream dans le cadre de ses contrôles en couches et centralise les access grants, les scopes et la sécurité du transport. Les credentials sont ainsi gouvernés depuis un point unique plutôt que disséminés dans des intégrations propres à chaque application. La surface d'authentification et de transport est présentée dans les paramètres de sécurité et d'accès MCP. La centralisation de cette frontière ne réduit pas les conséquences potentielles de la compromission d'un serveur, mais elle élimine la dispersion non gouvernée qui la rend plus facile et moins visible.

Risque 5 : angles morts d'audit

Posez une question simple à une équipe qui exploite des agents en production : quels outils cet agent a-t-il appelés mardi dernier, avec quels arguments et quels résultats ? Un nombre étonnant d'équipes ne sait pas répondre. Les tool calls s'effectuent dans le code applicatif, les logs sont incohérents et aucun enregistrement centralisé ne retrace les actions de l'agent. Cet angle mort pose un problème de sécurité et, dans un contexte de durcissement réglementaire, de conformité.

Il est impossible d'enquêter sur ce qui n'a pas été enregistré. Comme Odock intervient dans le flux de chaque appel MCP, il produit des usage records pour le trafic d'outils comme pour celui des models, auxquels sont associés l'identité, l'outil, le résultat et le coût. La documentation sur l'observability décrit la prise en charge spécifique des usage records MCP. Cet enregistrement fait toute la différence entre un tool call simplement bloqué et un blocage qu'il est possible d'expliquer.

Risque 6 : consommation non bornée via les agents

Les agents amplifient les coûts et la charge. Un model qui boucle, un outil appelé en continu ou un agent qui multiplie les retries peut provoquer simultanément un denial of wallet et un denial of service. Dans les systèmes agentiques, l'abus de coûts et l'atteinte à la disponibilité correspondent souvent au même incident opérationnel. Les tool calls MCP peuvent en effet entraîner à la fois des dépenses et des effets de bord réels.

Les contrôles de coûts et de rate doivent donc s'appliquer au flux des outils, et pas uniquement à celui des models. Odock impose au trafic MCP des limites de payload, des rate limits, des contrôles de concurrency, des budgets et des quotas. Un agent dont la consommation devient incontrôlée atteint ainsi un plafond avant d'alourdir votre facture ou de saturer vos systèmes upstream. Les budgets sont réservés avant l'appel, et non rapprochés une fois les dégâts constatés : c'est ce qui distingue une véritable limite d'un simple rapport. Consultez les pages consacrées aux budgets et aux quotas.

Le point commun aux six risques

Ces six risques ont un point commun. Chacun constitue une variante de la même erreur : traiter l'accès aux outils comme une fonctionnalité d'intégration plutôt que comme une frontière gouvernée entre des capacités. L'accès sur-privilégié résulte d'une frontière absente. L'injection et le poisoning exploitent des frontières qui n'inspectent pas le contenu. La dispersion des credentials découle d'une frontière qui n'a jamais été centralisée. Les angles morts d'audit apparaissent lorsqu'elle n'enregistre rien, et la consommation non bornée lorsqu'elle n'impose aucun plafond.

C'est pourquoi Odock.ai constitue un point naturel pour maîtriser l'essentiel de ces risques. Lorsque l'accès MCP passe par la couche contrôlée d'Odock, cette frontière existe par défaut : elle inspecte, enregistre et applique des limites de manière cohérente pour chaque agent, au lieu d'être réimplémentée dans chaque application. Ce concept est approfondi dans notre article sur la gouvernance des serveurs MCP pour les agents IA.

Ce qu'Odock ne résout pas

Il est important de préciser les limites d'Odock, car certains aspects de la sécurité MCP se situent hors du périmètre de toute gateway.

Odock ne patche pas le serveur MCP lui-même. Le secure SDLC et la gestion des correctifs des serveurs que vous exploitez restent sous votre responsabilité. Il ne valide pas les schémas métier complexes au sein d'un handler d'outil, car cette vérification relève parfois du code de l'outil. Enfin, il ne remplace pas la décision initiale de refuser la connexion d'un serveur douteux. Les choix relatifs à la provenance et à la confiance vous appartiennent.

Odock permet néanmoins d'appliquer les contrôles connus, simples et efficaces qui répondent aux six risques décrits ci-dessus. Si ces risques apparaissent régulièrement dans les rapports d'incident, c'est précisément parce que ces contrôles ne sont pas appliqués de manière cohérente.

Pourquoi nous l'avons intégré à Odock.ai

Soyons transparents : la sécurisation de l'accès des agents aux outils constitue l'une des principales raisons d'être d'Odock.ai. Chaque serveur MCP est traité comme un accès scopé à des capacités, avec grants, allowed et blocked tools, semantic filters, limites de rate et de payload, ainsi qu'un enregistrement de chaque tool call. L'ensemble est placé derrière un endpoint unique compatible avec OpenAI, que vous pouvez adopter sans réécrire vos agents. En faisant passer vos accès MCP par Odock, chaque tool call devient un accès scopé à des capacités, inspecté et enregistré. La majeure partie de la surface d'attaque MCP observée en 2026 se retrouve ainsi privée de point d'entrée.

Si vos agents obtiennent de nouveaux outils plus vite que votre processus de revue de sécurité ne peut les examiner, Odock.ai est précisément conçu pour combler cet écart. Parlez à notre équipe ou découvrez la MCP gateway Odock afin de fournir des outils à vos agents sans leur accorder un accès sans limites.

Sources

• MCP Security, 6 Risks Enterprise Teams Face in 2026, DataStealth
• Model Context Protocol Security, Complete Guide, SentinelOne
• MCP Security Vulnerabilities, Prompt Injection and Tool Poisoning, Practical DevSecOps
• Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning, arXiv
• Sécurité MCP Odock
• Usage records MCP Odock