Le cas du Model Context Protocol, connu sous le nom de MCP, ne se limite plus à une discussion de niche entre développeurs d’agents. Il s’est transformé en une problématique bien plus sérieuse pour toute l’industrie : quand une couche fondamentale du nouvel écosystème de l’Intelligence Artificielle génère des risques liés à l’exécution de commandes, qui doit assumer la responsabilité réelle ?

Anthropic a présenté le MCP en novembre 2024 comme une norme ouverte visant à connecter modèles d’IA, outils, sources de données et systèmes externes via une interface commune. La promesse était claire : réduire la nécessité d’intégrations sur-mesure et faciliter des connexions bidirectionnelles « sécurisées » entre assistants et logiciels d’entreprise. Depuis, le MCP s’est rapidement étendu auprès de clients, SDK, marketplaces et frameworks tiers.

Cependant, cette expansion a mis en lumière une controverse fondamentale. OX Security soutient que le problème ne se limite pas à un simple bug isolé, mais réside dans une faiblesse architecturale liée à la façon dont les implémentations officielles permettent de lancer des processus locaux via STDIO. Selon leurs recherches, cette logique a conduit à plus de 30 divulgations responsables, plus de 10 CVE de gravité haute ou critique, et une exposition potentielle que la société chiffre à plus de 150 millions de téléchargements et jusqu’à 200 000 serveurs. Bien que ces chiffres proviennent du seul rapport d’OX Security, ils ont suffi à relancer le débat.

Le problème ne réside pas uniquement dans le code, mais dans la conception

Ce qui rend cette situation particulièrement délicate, c’est qu’elle ne correspond pas à la catégorie habituelle de vulnérabilités ponctuelles. Selon OX Security, si une implémentation accepte des configurations non sécurisées ou permet à des entrées utilisateur de lancer un processus STDIO, cette commande peut s’exécuter même si le serveur MCP ne démarre pas correctement. Dans cette optique, le problème n’est pas tant une faille spécifique, mais une architecture trop permissive à un point critique.

Anthropic semble ne pas partager cette interprétation. La spécification officielle du MCP indique que le protocole ne peut pas imposer ces principes de sécurité au niveau du protocole, et que les développeurs doivent mettre en place des flux robustes de consentement, de contrôle d’accès et de protection des données. Leur documentation en matière de sécurité insiste également sur le fait de montrer à l’utilisateur la commande exacte qui sera exécutée, d’avertir sur les patterns dangereux, d’utiliser le sandboxing et de fonctionner avec des privilèges minimaux. Autrement dit, le modèle officiel déplace une grande partie du contrôle de sécurité vers le développeur et l’opérateur de l’intégration.

C’est là que la friction principale apparaît. Pour Anthropic, ce comportement peut être considéré comme attendu si le développeur utilise mal une capacité puissante. Pour OX Security, cette même capacité ne devrait jamais être exposée de façon aussi ouverte dans une composante destinée à devenir une infrastructure commune de l’écosystème agentique. Open Security résume cette opposition en décrivant la polémique comme une différence entre « défaillance de conception » et « comportement attendu basé sur une mauvaise décision de conception ».

Lorsque la norme est ouverte, mais que la sécurité n’est pas intégrée par défaut

Dans le secteur technologique, cette nuance a une importance capitale. Le MCP n’est pas une application spécifique ni une extension marginale ; il constitue une couche de compatibilité visant à faire office de traducteur universel entre modèles et outils. Lorsqu’une telle composante est adoptée rapidement, toute décision permissive à la conception peut se propager via SDK, adaptateurs, marketplaces et IDEs.

Ce phénomène en cascade est précisément l’un des aspects les plus sensibles de cette affaire. OX Security et plusieurs médias ayant relayé ses travaux soutiennent que l’impact ne se limite pas au dépôt principal, mais s’étend à des projets qui réutilisent la logique du SDK officiel ou construisent par-dessus. Parmi les exemples : des adaptateurs LangChain, des plateformes comme LangFlow et Flowise, ainsi que des scénarios d’injection de prompts locaux dans des environnements de développement assisté par IA.

Il faut donc percevoir le problème comme une question de chaîne d’approvisionnement logicielle, et pas uniquement comme une problématique de bonnes pratiques de programmation. Si une bibliothèque ou un patron officiel est massivement adopté, et si son utilisation est facilement sécuritaire inadaptée, la sécurité ne dépend pas seulement du fournisseur du produit final. Elle dépend de tous les acteurs de la chaîne. Plus celle-ci s’allonge rapidement, plus il devient probable qu’un maillon soit mal implanté.

La grande question : sécurité par défaut ou prudence par défaut ?

Ce qui est réellement en jeu, c’est une question de philosophie d’ingénierie. Dans une technologie qui vise à connecter des modèles à des systèmes externes, doit-on privilégier une approche par défaut fermée en tout ce qui peut impliquer une exécution locale, ou suffit-il de documenter les risques et de recommander la prudence ?

Anthropic semble plutôt pencher vers la seconde option. Sa spécification et ses guides de sécurité indiquent que le protocole habilite des capacités, mais ne peut pas obliger chaque implémentant à concevoir une intégration sécurisée. En revanche, OX Security pense qu’un changement architectural dès l’origine aurait permis de réduire fortement ce risque pour tous les projets dérivés. Ces deux positions ont une cohérence interne, mais leur coût diffère : la première laisse la sécurité à la responsabilité de milliers d’équipes, tandis que la seconde demande de limiter davantage dès la conception.

Pour un média technologique, cela représente l’aspect le plus essentiel de cette histoire. L’IA ne se limite plus à répondre à des questions ; elle commence à exécuter des actions, lancer des processus, modifier des configurations et manipuler des systèmes réels. Dès que cela se produit, la discussion dépasse le simple cadre algorithmique pour se projeter vers l’architecture, la gouvernance et la responsabilité opérationnelle.

Ce n’est pas un cas isolé : le secteur se couvre légalement tout en accélérant commercialement

L’incident du MCP s’inscrit dans une tendance plus large. Les entreprises d’intelligence artificielle façonnent ces systèmes comme le nouveau centre de la productivité numérique, tout en limitant leur responsabilité via des avertissements, des contraintes d’usage ou en transférant le risque vers les utilisateurs, entreprises et développeurs. Le cas de Copilot et ses conditions d’utilisation, qui avaient suscité une polémique en raison d’un langage recommandant de ne pas se fier aux décisions importantes, en est un exemple récent.

La paradoxe est évident : l’industrie veut faire de l’IA une infrastructure crédible, mais continue à gérer ces enjeux comme s’il s’agissait de simples incidents produits. Pourtant, une infrastructure centrale défaillante ou perçue comme non sécurisée par défaut ne se limite pas au laboratoire : elle se diffuse dans tout ce qui s’y appuie.

C’est pourquoi le débat autour du MCP est si crucial. Non pas parce qu’il risque seul de freiner l’adoption des agents, mais parce qu’il force à aborder une question que le secteur repousse depuis trop longtemps : si l’IA doit opérer sur des systèmes réels, manipuler des données sensibles et exécuter des tâches critiques, elle ne peut plus laisser la sécurité à la seule responsabilité de l’intégrateur. À un moment donné, quelqu’un devra reconnaître que l’ouverture seule ne suffit pas, et que la responsabilité doit être intégrée par défaut.

Questions fréquentes

Qu’est-ce que le MCP et pourquoi est-il devenu si important dans l’intelligence artificielle ?
Le MCP est une norme ouverte impulsée par Anthropic pour connecter modèles et assistants avec des outils, données et systèmes externes. Son importance croît car elle diminue la dépendance aux intégrations sur-mesure et facilite l’interopérabilité avec des logiciels existants.

Que critique précisément OX Security à propos du MCP ?
OX Security affirme que la logique de lancement de processus via STDIO dans les implémentations officielles peut permettre l’exécution arbitraire de commandes lorsqu’elle est combinée à des configurations non sécurisées ou à des entrées non filtrées. La société considère ce problème comme une faiblesse d’architecture plutôt qu’un simple bug isolated.

Anthropic a-t-elle reconnu une faille dans le protocole ?
Pas dans les termes précis avancés par OX Security. La position officielle, soutenue par la documentation de sécurité, est que le protocole ne peut pas imposer tous les contrôles et que c’est au développeur de mettre en place consentement, isolement et protection d’accès.

Pourquoi ce cas dépasse-t-il Anthropic ?
Parce que MCP s’est rapidement diffusé comme couche d’intégration pour de nombreux tiers, SDK et outils. Si une décision de conception dans cette couche de base introduit un risque, l’impact peut se propager à travers frameworks, marketplaces et IDEs qui réutilisent le même pattern.

source : ox.security