Nous avons créé le Tunnel MCP sécurisé parce que les serveurs MCP auxquels les équipes tiennent le plus sont souvent ceux qu’elles souhaitent le moins exposer à Internet.
Nous souhaitions expliquer comment nous avons abordé cette contrainte : préserver le caractère privé des serveurs tout en offrant à ChatGPT, à Codex et aux autres produits OpenAI un chemin d’accès standard pour les requêtes MCP.
Le Model Context Protocol a facilité la connexion des systèmes d’IA aux outils et aux données externes. Mais nombre des serveurs MCP les plus utiles fonctionnent dans des réseaux d’entreprise, des maillages de services privés, sur les ordinateurs portables des développeurs et dans d’autres environnements conçus pour refuser le trafic entrant depuis Internet. Pour connecter ces serveurs à des produits d’IA hébergés, les équipes ont souvent dû créer des points de terminaison publics, déployer une infrastructure de proxy supplémentaire ou faire intervenir de nouveaux opérateurs réseau sur des chemins sensibles.
Le Tunnel MCP sécurisé propose une approche plus simple : Les clients exécutent dans leur environnement privé un petit logiciel client qui établit une connexion HTTPS sortante vers OpenAI. Ce logiciel :
- Reçoit les requêtes MCP
- Les transmet à un serveur local approuvé
- Renvoie les réponses et les notifications par la même connexion.
Les produits OpenAI peuvent utiliser le modèle standard de requête et de réponse MCP, tandis que le serveur sous-jacent reste protégé par les contrôles réseau existants du client.
Pour assurer un fonctionnement fiable et sécurisé, il a fallu résoudre plusieurs problèmes d’ingénierie à la fois : préserver la frontière du réseau privé du serveur, prendre en charge les flux de streaming et d’authentification de MCP, et fournir aux équipes un logiciel client qu’elles peuvent examiner et exploiter. Cet article présente les choix que nous avons faits.
Nous avons conçu le tunnel autour de quelques principes : des connexions exclusivement sortantes, une configuration explicite des destinations, la compatibilité avec le streaming et les notifications MCP, et un logiciel client exécuté par les clients, que les équipes peuvent examiner et exploiter elles-mêmes.
Ensemble, ces principes permettent de connecter facilement des outils et des données privés aux produits OpenAI sans transformer les serveurs MCP privés en services publics.
Des choix par défaut inadaptés
Aujourd’hui, les équipes rendent généralement un service privé accessible de l’une des trois manières suivantes : exposer un point de terminaison public, utiliser un tunnel tiers ou étendre le réseau avec un VPN ou une connexion de peering.
- Un point de terminaison public facilite l’accès en affaiblissant la frontière du réseau.
- Un fournisseur de tunnel tiers peut rendre un serveur privé accessible rapidement, mais il ajoute aussi un prestataire sur le chemin de connexion : il faut l’évaluer, conclure un contrat, exploiter sa solution et lui faire confiance. Pour les équipes en entreprise, ce n’est pas un détail : le fournisseur du tunnel entre dans le périmètre de la révision de sécurité, du processus d’achat, des procédures d’exploitation et des métadonnées exposées par un système dont le but est de préserver le caractère privé des outils.
- Les VPN et le peering réseau résolvent le problème d’accès en établissant une connectivité réseau étendue, ce qui représente souvent un dispositif trop lourd pour une intégration MCP ciblée.
Le Tunnel MCP sécurisé adopte une approche plus ciblée. Au lieu de demander aux clients de déplacer le serveur MCP, d’élargir le périmètre réseau ou d’introduire un autre fournisseur de connectivité, il place à côté du serveur privé un petit logiciel client open source, dont le code peut être examiné, et lui laisse le soin d’établir et de contrôler la connexion à OpenAI.
Le Tunnel MCP sécurisé inverse la logique d’accès : c’est le côté privé qui prend l’initiative. Les produits OpenAI envoient leurs requêtes MCP à un point de terminaison de tunnel hébergé par OpenAI. Le service de tunnel met les tâches en file d’attente pour un tunnel précis, et le logiciel client, déjà exécuté à côté du serveur MCP privé dans l’environnement du client, les récupère via une connexion HTTPS sortante. Il transmet la requête localement et renvoie la réponse par le même chemin.
Les produits OpenAI disposent ainsi d’un chemin d’accès standard pour les requêtes MCP, sans obliger le serveur privé à accepter le trafic entrant depuis Internet ni établir une connectivité réseau plus étendue.
Figure 1. Cycle de vie d’une requête du Tunnel MCP sécurisé.
Pourquoi commencer par le long-polling ?
Nous avons délibérément commencé par un transport sans surprise sur le plan opérationnel. Les connexions HTTPS sortantes sont déjà bien connues des pare-feu d’entreprise, des environnements avec proxy et des équipes plateforme. Le long-polling permet au client du tunnel de ne demander que la quantité de travail qu’il peut traiter. La file d’attente côté client dispose ainsi d’un mécanisme naturel de contre-pression, plutôt que d’encourager une mise en mémoire tampon sans limite.
Ce choix a également permis de conserver un fonctionnement facile à comprendre dans la solution livrée :
- Un produit envoie des messages JSON-RPC MCP au point de terminaison hébergé par OpenAI.
- Le service de tunnel maintient cette requête en attente ou la traite en streaming jusqu’à ce que le logiciel client exécuté par le client renvoie une réponse finale
- Lorsque des résultats en streaming sont demandés, le tunnel peut transmettre des événements intermédiaires envoyés par le serveur.
Le produit bénéficie ainsi d’un chemin d’accès standard pour les requêtes et les réponses MCP, tandis que le serveur MCP et son adresse restent privés. Les requêtes, les réponses et les événements intermédiaires sont relayés par le point de terminaison de tunnel hébergé par OpenAI.
Garder une frontière de sécurité explicite
Le tunnel ne sert pas à effacer la frontière du réseau, mais à la rendre explicite. Le client du tunnel, exécuté dans l’environnement du client, s’authentifie auprès du plan de contrôle du tunnel. Le produit utilise le point de terminaison de tunnel hébergé par OpenAI, et l’adresse MCP privée n’est utilisée que depuis l’environnement du client. L’accès au tunnel est lié au contexte existant de l’organisation et de l’espace de travail OpenAI du client, ainsi qu’à l’identité configurée du tunnel, au lieu de constituer un chemin réseau distinct doté de son propre modèle d’accès.
La conception ne se limite pas au choix du sens des connexions réseau. Comme le client du tunnel s’exécute dans l’environnement du client, son comportement doit pouvoir être examiné et son périmètre doit rester volontairement restreint : les clients doivent pouvoir comprendre quel code s’exécute, quelle connexion sortante il ouvre et à quels services privés il est autorisé à accéder.
Figure 2. Le serveur MCP reste à l’intérieur du périmètre du client.
Développer avec MCP comme en local
Nous voulions que le client du tunnel s’utilise comme un outil de développement, sans devenir un projet réseau. Un développeur doit pouvoir exécuter un serveur MCP sur un ordinateur portable, lancer le client du tunnel à ses côtés et connecter ce serveur à ChatGPT ou à Codex sans créer de point de terminaison public ni attendre la mise en place d’un VPN, d’une règle de pare-feu ou d’une modification du peering.
La même démarche doit rester valable lorsque le serveur passe d’un ordinateur portable à Kubernetes, à une machine virtuelle ou à un autre environnement contrôlé par le client. L’essentiel est de conserver la même logique : exécutez le client du tunnel à proximité du serveur MCP privé, vérifiez qu’il peut y accéder et laissez-le établir la connexion vers OpenAI. Les contrôles de santé et de disponibilité, les journaux et l’interface d’administration locale permettent d’examiner ce fonctionnement en cas de problème, sans transformer le tunnel en projet d’exploitation.
L’expérience développeur se joue aussi dans Codex lui-même. Le client du tunnel comprend un plugin Codex qui transforme la configuration en un workflow guidé, sans demander aux développeurs d’apprendre d’emblée toutes les options de ligne de commande, tous les profils et tous les détails du plan de contrôle de tunnel-client. Le but n’est pas de créer un raccourci local à usage unique : le plugin doit produire une configuration dont l’équipe pourra conserver la structure lorsque le serveur passera d’un ordinateur portable à Kubernetes, à une machine virtuelle ou à un autre environnement de production.
La même idée se retrouve dans le workflow d’assistant fourni avec tunnel-client : comme l’assistant peut lire le contexte local du tunnel exposé par tunnel-client, il peut aider un développeur à raisonner à partir de la configuration réelle plutôt que d’instructions génériques. Il peut déterminer quel profil est actif, quelle configuration a été générée, si le serveur MCP local est accessible et où en est le client du tunnel dans son démarrage. Le dépannage fait ainsi partie du cycle de développement, au lieu de passer par une procédure d’escalade distincte.
Figure 3. Le même cycle avec tunnel-client fonctionne de l’ordinateur portable à la production.
L’importance d’un client de tunnel open source
Le client du tunnel est un logiciel open source exécuté par le client dans son propre périmètre, à côté des serveurs MCP privés. Les clients et les personnes chargées de la révision de sécurité peuvent ainsi examiner le code qui s’exécute dans leur environnement. Ils peuvent vérifier ce que fait le logiciel, quelle connexion sortante il ouvre, comment il transmet les requêtes MCP localement et quelle configuration détermine les services auxquels il peut accéder.
Cette transparence maintient la cohérence entre le modèle de confiance et l’architecture : OpenAI héberge le service de tunnel, mais le code qui s’exécute dans l’environnement du client reste de taille réduite, peut être examiné et demeure sous le contrôle du client.
L’authentification d’entreprise sans accès réseau étendu
Les serveurs MCP privés sont rarement de simples points de terminaison HTTP internes accessibles sans authentification. Ils peuvent dépendre d’OAuth, d’autorités de certification privées, de proxys sortants ou de certificats clients sur la connexion au serveur MCP. Pour les prendre en charge, nous avons intégré les contraintes des réseaux d’entreprise à la conception du tunnel, au lieu de les traiter comme des exceptions que les clients doivent contourner.
La contrainte essentielle est que le serveur MCP reste privé. La découverte OAuth du serveur MCP passe par le tunnel : le produit hébergé peut ainsi déterminer comment s’authentifier sans que le serveur MCP ait à écouter sur Internet. Côté client, le logiciel du tunnel peut être configuré en fonction de l’environnement local : ensembles personnalisés de certificats d’autorités de certification, paramètres de proxy et mTLS côté MCP.
Nous avons également conservé une frontière explicite. Le tunnel ne rend pas automatiquement tous les points de terminaison d’entreprise associés accessibles depuis OpenAI. Si un serveur d’autorisation est privé, il doit tout de même être accessible au composant qui exécute le flux OAuth. Cette limite est intentionnelle : le Tunnel MCP sécurisé fournit un chemin d’accès restreint vers les outils privés configurés, pas une passerelle réseau à usage général.
Au-delà de MCP
MCP est le principal format utilisé pour les outils des modèles, mais les premiers tests alpha menés avec des clients ont révélé un problème connexe : tous leurs workflows privés ne sont pas déjà accessibles sous la forme d’un serveur MCP. Certains workflows importants reposent sur des API REST existantes, derrière le même pare-feu. Si le Tunnel MCP sécurisé ne résolvait que l’accès à MCP, les équipes auraient encore besoin d’un point de terminaison public distinct, d’un fournisseur de tunnel, d’un accès VPN ou d’un projet de peering pour ces autres API privées.
Harpoon étend ce même modèle de connectivité restreinte aux cibles REST approuvées. Au lieu d’exposer des URL arbitraires, le client enregistre des cibles associées à des libellés dans le logiciel client du tunnel. Les appelants côté OpenAI utilisent ces libellés via le Tunnel MCP sécurisé, et la requête HTTP réelle part toujours de l’intérieur de l’environnement du client, à côté du service privé.
La contrainte essentielle est que ces libellés ne constituent pas une passerelle réseau à usage général. Les appels restent encadrés par l’enregistrement des cibles sous le contrôle du client, les méthodes autorisées, les limites de taille des réponses, les délais d’expiration, le comportement des redirections et les contrôles d’accès au tunnel. Les workflows OpenAI approuvés disposent ainsi d’un chemin d’accès contrôlé aux API privées du client, sans lui demander d’ouvrir un accès réseau entrant ni attribuer à OpenAI une identité de type VPN.