Le Model Context Protocol a tout changé. Pour la première fois, les agents IA peuvent lire vos bases de données, appeler vos APIs, exécuter du code, modifier des fichiers et gérer une infrastructure cloud — le tout via une interface unique et standardisée. Anthropic a ouvert le code de MCP fin 2024. En quelques mois, il était partout. Microsoft, Google, Amazon, des centaines d'outils. La courbe d'adoption a été verticale.
Et c'est exactement le problème.
Les MCP servers deviennent la nouvelle couche API — les gardiens entre les agents IA et tout ce qui compte dans votre organisation. Vos données. Votre infrastructure. Votre logique métier. Si vous en construisez un, en déployez un ou en dépendez, vous devez comprendre comment fonctionnent réellement les MCP servers — et à quel point la plupart d'entre eux sont exposés. Car la réponse est inconfortable.
Les chiffres racontent une histoire préoccupante
En 2025, Astrix Security a mené une analyse de plus de 5 200 implémentations open-source de MCP servers. Les résultats ont été alarmants : 53 % reposent sur des secrets statiques de longue durée, tels que des clés API et des jetons d'accès personnel. Seuls 8,5 % utilisent des méthodes d'authentification modernes comme OAuth. Les recherches de HiveTrail ont brossé un tableau encore plus sombre — 43 % des MCP servers open-source analysés présentent des failles d'injection de commandes, 33 % permettent des requêtes URL sans restriction, et 22 % laissent fuir des fichiers en dehors des répertoires prévus.
Près de 2 000 MCP servers sont exposés publiquement sur internet aujourd'hui sans authentification et sans contrôle d'accès. Pas mal configurés — simplement non protégés par conception. La spécification MCP elle-même fournit un minimum d'indications sur l'authentification, ce qui a conduit à une posture de sécurité fragmentée et dangereusement incohérente à travers l'écosystème.
Ce n'est pas un problème théorique. Rien qu'en 2025, des vulnérabilités critiques d'exécution de code à distance ont été divulguées dans des MCP servers en production : CVE-2025-6514, CVE-2025-53967 dans le Framelink Figma MCP Server, et CVE-2025-49596 dans le MCP Inspector d'Anthropic elle-même. Asana a corrigé un bug dans son MCP server qui aurait pu exposer des données clients. Une vulnérabilité d'injection de prompt a été signalée dans le MCP server officiel de GitHub.
Les cinq vecteurs d'attaque que chaque équipe doit connaître
Le cadre émergent OWASP MCP Top 10 identifie plusieurs catégories critiques de menaces. Les comprendre constitue la première étape vers la construction d'une infrastructure résiliente.
1. Injection de prompt
L'OWASP classe l'injection de prompt comme le risque numéro un pour les applications LLM (LLM01:2025). Dans le contexte MCP, cette attaque utilise des entrées manipulées pour amener les agents IA à exécuter des actions non prévues via leurs outils connectés — exfiltration de données, élévation de privilèges, modifications non autorisées. L'injection indirecte de prompt est particulièrement dangereuse : des instructions malveillantes sont intégrées dans un contenu externe que l'agent IA ingère, invisibles pour les opérateurs humains mais fidèlement exécutées par le modèle.
2. Empoisonnement d'outils
L'empoisonnement d'outils est une forme d'injection indirecte de prompt propre à l'écosystème MCP. Les attaquants modifient les métadonnées d'un outil — sa description, son schéma de paramètres ou la documentation de son type de retour — pour y intégrer des instructions cachées que le modèle IA suit. L'outil empoisonné n'a même pas besoin d'être invoqué directement ; sa simple présence dans la fenêtre de contexte du modèle peut modifier la façon dont l'agent interagit avec d'autres outils légitimes.
3. Attaques de la chaîne d'approvisionnement
Les MCP servers suivent un modèle de distribution similaire à npm : les développeurs installent des paquets depuis des registres, les configurent via JSON et les exécutent avec un large accès système. Un seul paquet compromis peut se propager à travers des milliers de déploiements. Contrairement aux écosystèmes de paquets traditionnels, les MCP servers s'exécutent fréquemment avec des privilèges élevés — accès direct aux bases de données, systèmes de fichiers et infrastructure réseau.
4. Shadow MCP
Shadow MCP est l'équivalent MCP du shadow IT. Les ingénieurs lancent des MCP servers non autorisés pour prototyper rapidement ou s'intégrer avec un client IA personnel. Ces serveurs opèrent en dehors du périmètre de sécurité de l'organisation — sans gouvernance, sans supervision, sans surveillance. Ils accèdent aux bases de données de production avec des identifiants de développeur et effectuent des appels API avec des jetons personnels.
5. Failles d'authentification et d'autorisation
La spécification MCP impose des identifiants de session dans les URLs — une pratique qui viole les principes fondamentaux de sécurité et expose les identifiants dans les journaux du serveur, l'historique du navigateur et les en-têtes HTTP referrer. La plupart des serveurs n'implémentent aucune intégration SSO, aucun contrôle d'accès basé sur les rôles, ni aucune rotation de jetons.
Nous avons déjà observé ce schéma auparavant
La dette de sécurité accumulée dans l'écosystème MCP n'est pas sans précédent. Nous l'avons vu avec les APIs REST lancées sans limitation de débit au début des années 2010. Nous l'avons vu avec les bases de données NoSQL distribuées avec des identifiants par défaut exposés sur internet. Nous l'avons vu avec les conteneurs Docker exécutés en root avec des montages du système de fichiers hôte pendant une demi-décennie. À chaque fois, le schéma est le même : une nouvelle technologie offre des capacités incroyables sans aucune protection, l'adoption dépasse la sensibilisation à la sécurité, et l'industrie passe des années à corriger rétroactivement ce qui aurait dû être sécurisé dès le premier jour.
Le MCP se trouve exactement à ce point d'inflexion aujourd'hui. L'écosystème est suffisamment jeune pour bien faire les choses. Mais la fenêtre se ferme.
Si un MCP server peut exécuter du code, accéder aux données et effectuer des appels réseau — alors il doit être isolé, authentifié et surveillé dès le moment où il s'exécute pour la première fois. Pas après la première violation. Pas après le premier audit de conformité. Dès sa naissance.
Ce que signifie réellement la sécurité intégrée au runtime
Vinkius est une plateforme cloud conçue spécialement pour déployer des MCP servers avec la sécurité comme architecture fondamentale — pas comme un interrupteur de configuration. Chaque server déployé sur Vinkius s'exécute dans son propre V8 isolate, la même technologie de sandboxing qui propulse Cloudflare Workers et l'isolation des onglets de Chrome. L'isolate applique 34 règles d'ingénierie qui régissent chaque aspect de l'exécution.
Sandboxing V8 isolate
Chaque MCP server reçoit son propre espace mémoire isolé avec une limite de heap configurable (par défaut : 32 Mo). Aucun accès au système de fichiers. Aucune contamination de mémoire entre serveurs. L'isolate exécute le code du développeur dans un environnement totalement scellé : globalThis.console est un proxy trou noir, process.env est un objet vide, et setInterval est intentionnellement désactivé.
Protection proxy SSRF
Toutes les requêtes réseau sortantes des MCP servers sur Vinkius passent par un SSRF guard avec IP fixée. Avant qu'une requête HTTP ne quitte la plateforme, le DNS est résolu en une adresse IPv4 et validé contre une liste de blocage complète : plages privées RFC 1918, loopback, adresses link-local (y compris le célèbre endpoint de métadonnées AWS à 169.254.169.254).
Prévention de la perte de données (DLP)
Des contrôles DLP configurables inspectent toutes les données sortantes à la recherche de motifs sensibles avant qu'elles ne quittent la plateforme : clés API, jetons d'authentification, informations personnelles identifiables, numéros de cartes bancaires et motifs personnalisés. Lorsqu'une correspondance est détectée, les données sont masquées en transit. Le DLP est activé par défaut sur chaque déploiement.
Authentification HMAC
Chaque requête vers un MCP server hébergé sur Vinkius est signée cryptographiquement via HMAC-SHA256. Aucune clé API statique à faire fuiter et aucune URL à deviner. L'authentification est vérifiée en temps constant — les attaques par canal auxiliaire temporel ne peuvent pas déterminer des correspondances partielles de clé.
La voie à suivre pour l'écosystème MCP
Nous croyons que les MCP servers deviendront aussi omniprésents que les APIs REST dans les deux prochaines années. Chaque entreprise les opérera. Chaque framework d'agents IA — de LangChain à CrewAI en passant par AutoGen — en dépendra. La question n'est pas de savoir si l'écosystème passera à l'échelle, mais s'il le fera de manière sécurisée. C'est pourquoi nous avons construit Vinkius sur un framework MCP open-source conçu pour la production dès le premier jour.
Vinkius existe pour rendre le chemin sécurisé le chemin facile. Lorsque vous déployez un MCP server sur Vinkius, l'isolation V8 n'est pas optionnelle. La protection SSRF n'est pas quelque chose que vous configurez. Le DLP n'est pas un tier premium. L'authentification HMAC n'est pas un flag que vous pensez à activer. C'est l'architecture. C'est ainsi que chaque MCP server sécurisé devrait fonctionner.
C'est le jour un
L'écosystème MCP est encore jeune. Les standards sont encore en cours de rédaction. L'infrastructure est encore en construction. Il y a une fenêtre étroite — maintenant — pour intégrer la sécurité dans les fondations de l'infrastructure des agents IA, plutôt que de passer la prochaine décennie à la rapiécer.
Si vous construisez des MCP servers, si vous déployez des agents IA en production, si l'intégrité de l'infrastructure dont dépendent vos modèles vous importe — il n'y a jamais eu de moment plus critique pour bien faire les choses.