MCP tunnels : connecter Claude à un réseau privé sans ouvrir le moindre port

Il existe un blocage très banal dans les projets d'IA en entreprise. Le modèle est choisi, les cas d'usage sont cadrés, et puis quelqu'un pose la question qui arrête tout : pour que l'assistant interroge notre ERP, notre base de connaissance interne ou notre outil métier, il faut bien que ces systèmes soient joignables depuis l'extérieur ?

Historiquement, la réponse était oui, et elle coûtait cher. Publier un serveur MCP interne sur internet, ouvrir un port entrant dans le pare-feu, ou à défaut inscrire en liste blanche les plages d'adresses IP du fournisseur d'IA. Trois options que les équipes sécurité acceptent rarement de gaieté de cœur.

Anthropic a publié une réponse à ce problème, les MCP tunnels. J'ai lu la documentation officielle en détail, parce que le sujet mélange deux choses que je vois souvent confondues : ce que la technique permet, et ce que l'engagement contractuel garantit. Ici, l'écart entre les deux est important.

Le problème que ça résout vraiment

Le Model Context Protocol permet à un modèle d'appeler des outils exposés par un serveur MCP. Tant que ce serveur tourne sur le poste du développeur, tout va bien. Dès qu'on veut le faire tourner dans le système d'information d'une entreprise, et le rendre accessible à un modèle hébergé chez un fournisseur, on retombe sur un problème de réseau vieux comme les extranets.

Les MCP tunnels prennent le contre-pied de l'exposition. La documentation le formule ainsi : le trafic circule sur une connexion sortante uniquement, ce qui évite d'ouvrir des ports entrants dans le pare-feu, d'exposer des services sur l'internet public, ou d'inscrire les plages IP d'Anthropic en liste blanche sur l'origine.

C'est le même principe que les tunnels inversés utilisés depuis longtemps pour la supervision ou l'accès distant : c'est le réseau interne qui initie la connexion vers l'extérieur, jamais l'inverse. Le pare-feu périmétrique n'a rien à changer sur son flux entrant, qui reste fermé.

L'architecture, en deux composants

Le montage est plus simple qu'il n'y paraît. Deux composants tournent à l'intérieur du réseau de l'entreprise.

Le premier est cloudflared, le connecteur de tunnel open source de Cloudflare. C'est lui qui initie les connexions sortantes vers ce que la documentation appelle le tunnel edge, et qui transporte le trafic chiffré depuis Anthropic jusqu'au second composant.

Le second est un proxy fourni par Anthropic. Il termine le TLS interne, vérifie que les adresses IP amont sont dans une plage autorisée, et route chaque requête vers le bon serveur MCP en fonction du nom d'hôte.

Chaque serveur MCP exposé reçoit un sous-domaine sous le domaine de tunnel de l'organisation. Ces noms d'hôtes sont ensuite attachés à une session Managed Agent dans la console, ou passés à l'API Messages via le connecteur MCP.

Côté réseau, les besoins en sortie sont documentés précisément : le composant de configuration parle à api.anthropic.com sur le port 443, cloudflared parle au tunnel edge sur le port 7844 en TCP et UDP, vers les plages 198.41.192.0/19 et 2606:4700:a0::/44. C'est le genre de tableau qu'une équipe réseau peut instruire en une réunion, ce qui est en soi un point positif.

Les trois couches de sécurité, et ce qu'elles protègent chacune

C'est la partie du modèle qui mérite d'être comprise, parce que c'est elle qui répond à l'objection immédiate : si mon trafic passe par Cloudflare, Cloudflare lit mes données internes ?

La documentation décrit trois couches indépendantes qui protègent chaque requête.

Le mTLS externe, entre Anthropic et le fournisseur de transport, avec validation d'adresse IP. Il protège contre des clients non autorisés qui chercheraient à atteindre le tunnel.

Le TLS interne, depuis le back end d'Anthropic jusqu'au proxy de l'entreprise. Il protège contre l'inspection des contenus par le fournisseur de transport ou tout intermédiaire réseau. C'est la réponse directe à l'objection : le proxy termine ce TLS interne avec un certificat que seule l'entreprise détient, donc Cloudflare ne peut lire ni les requêtes ni les réponses. Anthropic précise ne pas se connecter à un tunnel tant qu'un certificat d'autorité de certification n'est pas enregistré, ce qui garantit que les charges utiles sont toujours chiffrées quand elles traversent le réseau de Cloudflare.

L'OAuth propre à chaque serveur MCP. Il protège contre l'usage non autorisé des outils MCP par du trafic pourtant authentifié au niveau du tunnel. Ce point est le plus facile à sous-estimer : le tunnel transporte le trafic vers le serveur MCP, il ne s'authentifie pas auprès de lui. Si le serveur amont exige sa propre authentification, il faut la fournir comme pour n'importe quel serveur MCP distant.

Un point d'honnêteté que la documentation ne cache pas : Cloudflare voit malgré tout des métadonnées de connexion. L'adresse IP de sortie de l'hôte qui fait tourner cloudflared, une empreinte de cet hôte, la chronologie et le volume en octets des connexions, et le sous-domaine *.tunnel.anthropic.com attribué au tunnel. Anthropic indique que son accord avec Cloudflare restreint l'usage de cette télémétrie et que Cloudflare agit comme sous-traitant pour cette research preview. Ce n'est pas rien dans une analyse d'impact, mais c'est effectivement de la métadonnée, pas du contenu.

La documentation assortit d'ailleurs le modèle d'un avertissement explicite : si un attaquant obtient à la fois le jeton de tunnel et une des clés privées TLS, il peut usurper le proxy et lire les charges utiles des requêtes MCP. Les deux secrets sont à traiter comme critiques.

Le modèle de responsabilité partagée, à lire avant de signer quoi que ce soit

C'est la section que je conseille de mettre sous les yeux du RSSI avant toute discussion de calendrier, parce qu'elle dit très clairement où s'arrête le service.

Anthropic prend en charge le contrôle d'accès au tunnel, la validation du certificat d'autorité avant de se connecter au proxy, et le fait que Claude n'envoie de requêtes que vers des tunnels appartenant à l'organisation.

L'organisation cliente prend en charge tout le reste, et le reste est substantiel : l'ensemble des contenus et du trafic qui transitent par son tunnel, le respect des conditions d'usage des tiers dont celles de Cloudflare, la conformité aux recommandations de déploiement, la protection des jetons de tunnel et des clés privées TLS, la gestion du certificat serveur et son renouvellement avant expiration, la configuration OAuth sur chaque serveur MCP, la restriction des accès réseau du proxy et des serveurs MCP, et la notification d'Anthropic en cas de suspicion de compromission.

Traduit en langage de projet : le tunnel n'est pas un service géré qui absorbe la charge d'exploitation. C'est un composant d'infrastructure supplémentaire à exploiter, avec sa propre gestion de certificats et sa propre rotation de secrets. Quelqu'un, dans l'organisation, doit en porter la responsabilité opérationnelle nominativement.

Les limites qu'il faut assumer

Je ne vois aucune raison de minorer les réserves, d'autant que la documentation elle-même les énonce sans détour.

C'est une research preview. Le service est fourni « as-is », sans aucun engagement de disponibilité, de support ou de continuité. Anthropic se réserve le droit de le modifier ou de l'arrêter à tout moment. L'accès se fait sur demande, pas en libre-service.

Il y a une dépendance à un tiers qui ne s'engage pas non plus. Le transport repose sur Cloudflare, dont la documentation précise qu'il ne prend aucun engagement de disponibilité pour le transport sous-jacent. On empile donc deux absences d'engagement.

Le déploiement n'est pas une affaire de cinq minutes. Il faut une cible de déploiement, c'est-à-dire un cluster Kubernetes ou une machine virtuelle avec Docker et Docker Compose. Il faut créer un tunnel dans la console ou par l'API. Et il faut une méthode d'authentification à l'API Tunnels : soit l'accès programmatique recommandé, qui suppose de mettre en place une fédération d'identité de charge de travail (Workload Identity Federation) avec un émetteur OIDC enregistré et une règle de fédération portant la portée workspace:manage_tunnels, soit des identifiants statiques fournis à la main, avec un certificat serveur signé par une autorité enregistrée dans la console.

Le périmètre d'usage est restreint. La documentation note que les tunnels créés via la console ne sont pas disponibles comme connecteurs dans claude.ai. On parle des Managed Agents et de l'API Messages, donc d'un usage applicatif construit par une équipe, pas d'un branchement pour utilisateurs finaux.

Comment je cadrerais la décision chez un client

Voilà où l'exercice devient un sujet de delivery management plutôt qu'un sujet d'architecture. La question n'est pas « est-ce que la technologie est bonne », elle a l'air solide. La question est « est-ce que le niveau de maturité du produit correspond au niveau d'engagement de mon projet ».

Je poserais trois filtres, dans cet ordre.

Premier filtre, la criticité de l'usage cible. Un tunnel en research preview peut porter une exploration, un prototype interne, une preuve de valeur sur un périmètre restreint. Il ne peut pas porter un service dont l'indisponibilité se traduit par une dégradation visible pour un client final ou pour une opération métier. L'absence d'engagement de disponibilité n'est pas une formalité juridique, c'est une contrainte de conception.

Deuxième filtre, l'existence d'un besoin de conformité qui justifie le détour. Le cas où les tunnels prennent tout leur sens, c'est celui où la donnée ne peut pas sortir du réseau, où l'exposition d'un service sur internet est simplement exclue, et où le projet a par ailleurs des exigences de type Zero Data Retention ou de couverture HIPAA. Si le serveur MCP peut légitimement être publié derrière une authentification classique, le tunnel ajoute de la complexité pour un gain de sécurité marginal.

Troisième filtre, la capacité d'exploitation réelle. Une équipe qui gère déjà Kubernetes, une fédération d'identité OIDC et une rotation de certificats absorbera ce composant sans drame. Une équipe qui découvrirait ces trois sujets à cette occasion ne devrait pas les découvrir sur ce chemin critique. C'est exactement le mécanisme par lequel les pilotes d'agents IA échouent en entreprise : pas sur la qualité du modèle, mais sur une charge d'intégration sous-estimée au cadrage.

Une remarque de fond pour finir. Les MCP tunnels vont dans le même sens que ce que j'observais en analysant le coût réel d'une IA déployée en local : la question « faut-il tout rapatrier chez soi » est souvent mal posée. Ce que les entreprises veulent vraiment, ce n'est pas héberger le modèle, c'est garder la donnée là où elle est et contrôler qui la voit. Un tunnel sortant chiffré de bout en bout répond à ce besoin sans imposer d'exploiter un modèle. C'est une réponse plus économique au vrai problème, quand elle est disponible avec les garanties suffisantes. Aujourd'hui, elle ne l'est pas encore.

C'est aussi, accessoirement, une alternative officielle au contournement que je décrivais à propos du Shadow AI. Quand la voie officielle n'existe pas, les équipes en inventent une, généralement moins sûre. Offrir un chemin cadré vers les systèmes internes est une réponse de gouvernance autant que de technique.

Sources : Anthropic, MCP tunnels overview · Anthropic, MCP tunnels concepts · Anthropic, MCP tunnels security · Anthropic, MCP connector · Anthropic, Workload Identity Federation