Sécurité MCP en 2026 : la faille human-in-the-loop dans la spec

La spécification du Model Context Protocol admet, en langage clair, qu’elle ne peut pas imposer l’approbation humaine avant qu’un outil IA n’agisse — cette garantie est une recommandation pour l’application construite au-dessus de MCP, pas une règle que MCP lui-même vérifie. Pour toute agence qui connecte sa propre IA, ou celle d’un client, à de vrais systèmes métier via MCP, cette seule phrase est tout le modèle de risque. Le protocole indique à votre IA quels outils existent et ce qu’ils prétendent faire. Qu’un humain voie et approuve réellement ce qui va se passer est entièrement laissé à celui qui a construit le client.

Que dit réellement la spec MCP sur le consentement ?

La section « Key Principles » de la spécification est directe sur les limites de ce que le protocole garantit :

« 1. User Consent and Control — Users must explicitly consent to and understand all data access and operations… 3. Tool Safety — Tools represent arbitrary code execution and must be treated with appropriate caution… Hosts must obtain explicit user consent before invoking any tool. »

Et immédiatement après :

« While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications… »

C’est la faille en un paragraphe. Les principes sont rédigés avec un « must » en minuscules, ce qui, selon la convention que suit la spécification MCP, signifie recommandation, pas exigence au niveau du protocole. La spécification Tools répète la même structure dans son « User Interaction Model » : « there SHOULD always be a human in the loop with the ability to deny tool invocations », aux côtés de recommandations selon lesquelles les applications « SHOULD… present confirmation prompts to the user for operations ». Recommandé. Pas imposé. Pas quelque chose qu’un serveur MCP peut vérifier que le client fait réellement.

Ce n’est pas une faille unique à MCP — aucun protocole ne peut forcer une application construite au-dessus de lui à se comporter d’une certaine manière. Mais cela signifie que « notre IA est connectée via MCP » ne vous dit rien sur la présence réelle d’un humain dans la boucle. C’est une affirmation sur l’application spécifique, et elle doit être vérifiée là, pas supposée à partir du nom du protocole.

Ce qui se passe quand cette faille est exploitée

Trois incidents documentés montrent ce que la faille coûte en pratique, à trois points différents de la chaîne.

Asana, juin 2025 — l’échec d’isolation. Asana a lancé une intégration MCP le 1er mai 2025. Un bug d’isolation de tenant a été identifié le 4 juin, et l’intégration a été mise hors ligne pendant environ deux semaines pendant la correction. La faille a permis aux données d’une organisation — tâches, métadonnées de projet, détails d’équipe, commentaires et fichiers téléchargés — de devenir visibles au-delà des frontières organisationnelles. Environ 1 000 clients ont été affectés, et la vulnérabilité existait depuis le premier jour de la fonctionnalité. Ce n’était pas spécifiquement un échec human-in-the-loop — c’est un rappel que la frontière d’isolation autour de ce qu’une intégration MCP peut atteindre compte autant que qui approuve l’appel.

GitHub, mai 2025 — le « toxic agent flow ». Des chercheurs en sécurité chez Invariant Labs ont démontré une attaque où un développeur a demandé à un agent IA, connecté via le serveur MCP de GitHub, d’examiner les issues ouvertes sur un dépôt public. Une issue plantée contenait des instructions cachées. L’agent les a lues, puis a utilisé son propre accès déjà autorisé aux dépôts privés du développeur pour extraire des informations sensibles et les publier dans une pull request visible sur le dépôt public. Chaque appel d’outil individuel que l’agent a effectué était un appel que l’utilisateur avait réellement autorisé. Ce qui n’était pas autorisé — et ce qu’aucune invite d’approbation unique n’aurait attrapé — était la combinaison : lire une issue publique, puis agir sur des données privées, puis publier à l’extérieur. La conclusion d’Invariant était sans ambiguïté : « This vulnerability cannot be resolved through server-side patches. » C’est un problème architectural dans la façon dont les permissions se composent à travers les appels d’outils, pas un bug dans le code de GitHub.

Microsoft, 30 juin 2026 — la faille de réapprobation. L’équipe sécurité de Microsoft a publié un avertissement direct sur un mécanisme intégré au modèle de confiance lui-même : la description d’un outil — le texte qu’un utilisateur lit et approuve avant de laisser une IA l’utiliser — peut changer après cette approbation, et rien dans le protocole n’exige que le client redemande. Les propres mots de Microsoft : « In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review. » Un outil qui semblait sûr le premier jour peut être silencieusement redéfini le trentième, et un utilisateur qui l’a approuvé une fois n’a aucune raison de savoir que cela s’est produit. Microsoft a décrit MCP comme « the fastest-growing part of the agentic AI supply chain » — ce qui explique pourquoi cette faille précise compte de plus en plus chaque mois qu’elle reste non traitée.

À côté de cela, deux CVE concrets méritent d’être connus si vous évaluez un outillage MCP : CVE-2025-49596, une faille critique (CVSS 9,4) d’exécution de code à distance dans l’outil MCP Inspector d’Anthropic, et CVE-2025-6514, une vulnérabilité critique (CVSS 9,6) d’injection de commande dans le package largement utilisé mcp-remote, déclenchée par l’URL d’autorisation d’un serveur malveillant. Les deux sont corrigées, mais toutes deux illustrent que l’outillage autour de MCP a eu la même classe de faille que le modèle de confiance du protocole : des choses qu’un utilisateur supposait raisonnablement inertes se sont avérées ne pas l’être.

Ce que « human-in-the-loop » doit signifier, en pratique

Étant donné que le protocole ne l’imposera pas, les questions qui valent la peine d’être posées sur tout outil connecté à l’IA — y compris celui de sSystm — sont celles qui transforment « human-in-the-loop » d’un slogan en quelque chose de vérifiable :

1. Une écriture attend-elle réellement une personne, à chaque fois, ou seulement à la première utilisation ? Une seule approbation au moment de la connexion n’est pas la même garantie qu’une approbation par action.
2. Si la description ou le comportement d’un outil change, cela déclenche-t-il une réapprobation, ou cela prend-il effet silencieusement ? C’est précisément la faille que Microsoft a signalée en juin 2026.
3. Le token ou les identifiants sont-ils limités aux données d’une organisation, ou une session compromise pourrait-elle atteindre plusieurs tenants ? C’est ce qui a échoué chez Asana — pas l’étape d’approbation, mais la frontière d’isolation derrière elle.
4. Existe-t-il une piste d’audit de ce que l’IA a réellement fait, distincte de ce qu’on lui a demandé ? Les attaques composées comme le cas GitHub n’apparaissent qu’a posteriori si les étapes individuelles ont été journalisées.
5. Qui gouverne la spécification, et à quelle vitesse le modèle de sécurité évolue-t-il ? MCP a été donné à l’Agentic AI Foundation sous la Linux Foundation le 9 décembre 2025, avec Anthropic, Block, OpenAI, Google, Microsoft, AWS et Cloudflare tous cités comme impliqués — un signe que l’écosystème se consolide autour d’une gouvernance partagée plutôt que chaque fournisseur corrigeant de son côté.

Le point de terminaison MCP de sSystm émet un token par utilisateur limité à l’organisation de cet utilisateur, et chaque écriture qu’une IA propose — via le Build AI intégré ou un client externe connecté — reste en attente jusqu’à ce qu’une personne l’approuve. Ce n’est pas une affirmation que MCP l’impose ; c’est le point inverse. Parce que le protocole ne le fait pas, cela doit être construit délibérément dans l’application, et cela vaut la peine d’être vérifié explicitement plutôt que supposé à partir de « ça utilise MCP ». En savoir plus sur le fonctionnement de la frontière d’approbation dans comment l’IA et les humains partagent l’espace de travail sSystm, à quoi ressemble le modèle d’isolation dans notre architecture de sécurité, et la mécanique de connexion d’une IA externe via MCP dans comment connecter votre IA à votre agence avec MCP.