MCP en production 2026 : OAuth 2.1, 1 800 serveurs exposés et checklist PME

Le Model Context Protocol n’est plus un protocole expérimental d’Anthropic. Depuis sa donation à l’Agentic AI Foundation sous Linux Foundation, et avec la version de spécification de mars 2025 qui a introduit OAuth 2.1 et Streamable HTTP, MCP est devenu de l’infrastructure d’entreprise. Le problème : la majorité des serveurs déployés ne suivent pas encore les bonnes pratiques de production. Le paper arxiv « Securing the Model Context Protocol » publié en novembre 2025 chiffre l’écart entre l’état de l’art et l’état du terrain, et propose un cadre de contrôles qu’une PME peut appliquer immédiatement. Voici ce qu’il faut retenir pour déployer un serveur MCP sans introduire de surface d’attaque catastrophique.

Les chiffres qui doivent alerter en 2026

Trois statistiques du paper arxiv 2511.20920 décrivent un état de production immature.

Les chiffres-clés du paper :

1 800+ serveurs MCP accessibles publiquement sans authentification. L’inventaire est passif : les chercheurs ont scanné les annuaires publics et les registres MCP communautaires.
437 000+ téléchargements du package mcp-remote touché par la CVE-2025-6514. Cette vulnérabilité permettait à un serveur malveillant d’exécuter du code arbitraire sur la machine client lors d’une connexion remote.
90+ outils exposés par le serveur officiel GitHub MCP, parmi lesquels delete_file accessible sans validation contextuelle.

Pour une PME qui découvre MCP et qui se demande si elle peut « brancher rapidement un serveur », ces chiffres signifient que la voie facile (déploiement par défaut sans configuration) est aussi la voie où se sont concentrées les attaques documentées.

Les quatre catégories d’attaques MCP documentées en 2025-2026

Le paper arxiv classe les vulnérabilités en quatre familles, chacune avec un cas concret.

1. Injection de contenu et lethal trifecta

Le pattern le plus dangereux. Un agent qui combine trois capacités — accès à des données privées, exposition à du contenu non fiable, capacité de communication externe — devient un vecteur d’exfiltration dès qu’une consigne malveillante traverse l’une des entrées. L’exemple type : un client crée un ticket dont le corps contient des instructions cachées pour exfiltrer les logs. Le serveur MCP donne à l’agent à la fois la lecture des logs et l’envoi d’emails ; l’agent obéit à la consigne.

2. Attaques de chaîne d’approvisionnement

Trois sous-catégories :

Supply chain confusion : des packages MCP non officiels sur PyPI/npm imitent les noms de packages légitimes.
Rugpull attacks : le cas Postmark MCP, où un serveur initialement bénin a été modifié dans une mise à jour pour faire du BCC silencieux sur tous les emails sortants. L’utilisateur ne voit rien dans l’interface.
Exécution de code arbitraire : installer un serveur MCP local équivaut à exécuter du code non sandboxé sur la machine de l’utilisateur.

3. Risques de configuration

Over-permissioning : le serveur GitHub MCP officiel expose 90+ outils, dont des opérations destructives (delete_file, force-push). Une PME qui n’applique pas de RBAC granulaire au niveau outil donne l’accès complet à l’agent.
Absence d’authentification OAuth : avant mars 2025, MCP n’avait pas de standard d’authentification. Beaucoup de serveurs déployés à cette époque tournent encore sans auth.

4. Risques opérationnels

Exposition de données personnelles dans les logs MCP, fuites de secrets quand un agent traverse plusieurs serveurs MCP non sandboxés, anomalies comportementales (agent qui appelle 1 000 fois en une heure un outil normalement utilisé 10 fois/jour) non détectées faute de monitoring spécialisé.

OAuth 2.1 et Streamable HTTP : ce que mars 2025 a changé

La mise à jour de spécification du 26 mars 2025 a introduit deux ruptures structurantes.

1. Framework d’autorisation OAuth 2.1. Les serveurs MCP agissent comme resource servers OAuth 2.1, les clients comme OAuth 2.1 clients. Les autorisations sont déléguées à un authorization server qui implémente les flows OAuth 2.1 avec PKCE pour les clients publics. C’est cette migration qui permet aujourd’hui à un connector Claude de demander à l’utilisateur de signer dans une app tierce sans que Claude ne voie son mot de passe.

2. Streamable HTTP en remplacement de HTTP+SSE. Le nouveau transport autorise les serveurs MCP à tourner comme services remote plutôt que comme processus locaux. C’est ce qui a débloqué la vague de déploiements production observée depuis juin 2025. Limitation : les sessions stateful entrent en conflit avec les load balancers, et la scalabilité horizontale demande des workarounds (sticky sessions, externalisation d’état type Redis ou KV store).

Pour une PME qui démarre en 2026, ces deux choix sont non négociables : tout serveur MCP exposé à plus d’un utilisateur doit utiliser OAuth 2.1 et Streamable HTTP. Si on a déjà un MCP en HTTP+SSE sans OAuth, c’est l’équivalent d’un service web sans HTTPS — il faut migrer.

La checklist 5 contrôles pour PME

Le paper arxiv propose une grille en défense en profondeur. Voici la version condensée pour une PME francophone qui déploie un ou deux serveurs MCP en production.

#	Contrôle	Outil ou pattern recommandé	Effort
1	OAuth 2.1 par utilisateur + RBAC outil	Authorization server type Auth0/Clerk + scopes au niveau MCP tool, tokens partagés interdits	2-3 jours d’intégration
2	Provenance logging	Journaliser : user_id, timestamp, prompt original, trace outils, réponses, sources de données — exporter vers SIEM	1 jour si stack logs déjà en place
3	Containerisation + sandbox	Docker ou serverless avec FS read-only par défaut, filtrage entrée/sortie pour secrets/PII	1-2 jours par serveur MCP
4	DLP inline + détection secrets	Pattern matching côté gateway (Presidio, DLP cloud provider) sur prompts et réponses	2-3 jours setup initial
5	Gouvernance via gateway MCP	Registre interne privé des serveurs MCP autorisés + listes blanches/noires outils par rôle, prohibition serveurs locaux non vetting	3-5 jours architecture

Le total cumulé tourne autour de 8 à 15 jours-homme pour une PME qui démarre proprement avec un ou deux serveurs MCP. C’est moins que le coût d’un incident type rugpull ou exfiltration documenté dans le paper.

L’architecture passerelle MCP

Le paper arxiv propose explicitement une gateway MCP centralisée comme point d’application des contrôles. Schéma logique :

flowchart LR
    A[Agent IA] -->|OAuth 2.1 + RBAC| G[Gateway MCP]
    G -->|Streamable HTTP| S1[Serveur MCP CRM]
    G -->|Streamable HTTP| S2[Serveur MCP DB]
    G -->|Streamable HTTP| S3[Serveur MCP emails]
    G -->|logs| L[SIEM / SOAR]
    G -->|filter| D[DLP inline]

Tout passe par la gateway : authentification, autorisation, logging, filtrage. Les serveurs MCP individuels deviennent des backends qui n’ont jamais à gérer leur propre couche de sécurité — concentrée au niveau gateway. Cette architecture aligne MCP sur le pattern API Gateway largement adopté dans les services REST/gRPC.

Pour une PME qui a déjà déployé un MCP local (Claude Desktop ou Cursor), le déploiement initial sans gateway est acceptable tant que le serveur reste strictement local et qu’il ne traite que des données utilisateur. Dès qu’on passe en remote (équipe distribuée, clients externes), la gateway devient indispensable.

Alignement réglementaire 2026

Les contrôles s’alignent avec trois cadres normatifs explicitement cités dans le paper arxiv :

NIST AI RMF : les quatre fonctions Govern, Map, Measure, Manage couvrent toutes les catégories de risque MCP.
ISO/IEC 27001 : sections 5.15-5.18 sur l’authentification et 8.11-8.12 sur le masquage des données — directement applicables à OAuth 2.1 + DLP inline.
ISO/IEC 42001 : section A.7.5 sur la provenance des données — exigence cœur d’un logging MCP complet.

À ces cadres s’ajoute l’AI Act européen : la plupart des serveurs MCP utilisés par une PME tombent dans le périmètre des general-purpose AI systems intégrés à des produits. Les obligations de transparence et de logging deviennent applicables à partir du 2 août 2026 pour les modèles fondamentaux ; l’agent qui orchestre les MCP hérite indirectement de ces exigences via l’article 50 (disclosure utilisateur). On a détaillé l’angle PME française dans notre dossier AI Act PME obligations 2026.

Trois actions immédiates pour une PME en 2026

Si vous démarrez avec MCP ou si vous avez déjà un serveur tournant en production sans avoir réévalué la sécu depuis l’été 2025 :

Auditer vos serveurs MCP actuels : présence d’OAuth 2.1, transport (HTTP+SSE = à migrer, Streamable HTTP = OK), tools exposés. Si un serveur expose un outil destructif (delete_*, force_*, send_email sans whitelist destinataires), restreindre par RBAC ou retirer.
Mettre en place un logging de provenance minimal : a minima {user, timestamp, tool_name, args_hash, response_size} exporté vers un SIEM ou même un simple bucket S3 avec parsing différé. Sans ce log, un incident sera impossible à investiguer.
Containeriser tout nouveau MCP dès la première itération. Docker + FS read-only + filesystem temporaire éphémère. Coût marginal négligeable, gain défensif énorme face aux rugpulls et supply chain compromise.

Pour un guide opérationnel de déploiement initial (sans focus sécurité), on a tracé un parcours minimal dans notre article sur le déploiement d’un serveur MCP en production. Pour la couche prompt injection au niveau application (différente de la couche serveur MCP traitée ici), le dossier prompt injection Claude MCP couvre les vecteurs côté agent.

FAQ

OAuth 2.1 est-il obligatoire pour exécuter un serveur MCP en production en 2026 ?

OAuth 2.1 n’est pas strictement obligatoire au sens spécification — un serveur MCP peut techniquement tourner sans authentification, comme le démontrent les 1 800+ instances publiques recensées par le paper arxiv 2511.20920. Mais c’est devenu la norme de fait pour tout déploiement production sérieux depuis la mise à jour de spécification de mars 2025 qui a introduit le framework d’autorisation OAuth 2.1 pour les serveurs remote. Tout serveur destiné à des utilisateurs externes doit appliquer OAuth 2.1 par utilisateur — les tokens partagés sont l’antipattern principal identifié dans les attaques de supply chain documentées (Postmark MCP, mcp-remote CVE-2025-6514).

Streamable HTTP a-t-il vraiment remplacé HTTP+SSE pour MCP ?

Oui, depuis la mise à jour de spécification de mars 2025. Streamable HTTP permet aux serveurs MCP de fonctionner comme services remote plutôt que comme processus locaux — c’est ce qui a débloqué la vague de déploiements en production. La contrepartie : les sessions stateful entrent en conflit avec les load balancers, et la scalabilité horizontale demande des workarounds (sticky sessions, externalisation d’état). HTTP+SSE reste supporté pour la compatibilité, mais la spec actuelle privilégie Streamable HTTP pour tout déploiement remote.

Quel est le risque concret du « lethal trifecta » dans un déploiement MCP PME ?

Le lethal trifecta combine trois capacités d’un agent IA : accès à des données privées, exposition à du contenu non fiable, et capacité de communication externe. Quand un serveur MCP coche les trois, une simple instruction malveillante cachée dans un ticket client peut déclencher une exfiltration. L’exemple documenté dans le paper arxiv : un client crée un ticket dont le contenu contient des instructions cachées pour exfiltrer des logs. L’agent, équipé d’un MCP qui peut lire les logs internes et envoyer des emails, exécute la consigne sans alerte. Trois protections pour une PME : (1) sandboxer chaque serveur MCP en container isolé, (2) restreindre via RBAC les outils accessibles par contexte, (3) journaliser la trace complète (provenance) pour permettre la détection a posteriori.