Sécurisez la connectivité réseau privée pour tous : utilisateurs, nœuds, agents, Workers — Lancement de Cloudflare Mesh

Les agents IA ont fait évoluer la manière dont les équipes envisagent l’accès aux réseaux privés. Votre agent de codage doit interroger une base de données en préproduction. Votre agent en production doit faire appel à une API interne. Votre assistant IA personnel doit accéder à un service exécuté sur votre réseau domestique. Les clients ne sont plus simplement des humains ou des services. Ce sont des agents qui s’exécutent en autonomie, qui lancent des requêtes que vous n’avez pas explicitement approuvées, vers une infrastructure que vous devez sécuriser.

Chacun de ces flux de travail présente le même problème sous-jacent : les agents doivent accéder à des ressources privées ; or, les outils qui permettent cet accès été conçus pour les humains, et non pour les logiciels autonomes. Les VPN nécessitent une connexion interactive. Les tunnels SSH nécessitent une configuration manuelle. L’exposition publique des services constitue un risque pour la sécurité. Cependant aucune de ces approches ne vous donne de visibilité sur ce que fait réellement l’agent une fois connecté.

Aujourd’hui, nous lançons Cloudflare Mesh conçu pour connecter vos réseaux privés entre eux et proposer un accès sécurisé à vos agents. Nous intégrons également Mesh à la Plateforme pour développeurs Cloudflare afin que Workers, Durable Objects et les agents développés avec le SDK Agents puissent atteindre directement votre infrastructure privée.

Si vous utilisez la suite SASE et Zero Trust de Cloudflare One, vous avez déjà accès à Mesh. Vous n’avez pas besoin d’un nouveau cadre technologique pour sécuriser les charges de travail des agents. Vous avez besoin d’une solution SASE conçue pour l’ère des agents, et c’est ce que propose Cloudflare One. Cloudflare Mesh est une nouvelle expérience avec une configuration plus simple qui exploite les accès directs (on-ramp) que vous connaissez déjà : WARP Connector (désormais appelé nœud Cloudflare Mesh) et WARP Client (désormais appelé Cloudflare One Client). Ensemble, ces fonctionnalités créent un réseau privé pour le trafic, qu'il provienne d'humains, de développeurs ou d'agents. Mesh est directement intégré à votre déploiement Cloudflare One existant. Vos politiques Gateway, règles d’accès et mesures de contrôle du niveau de sécurité des appareils existants s’appliquent automatiquement au trafic du maillage (Mesh).

Si vous êtes développeur et que vous souhaitez simplement mettre en place des réseaux privés pour vos agents, vos services et votre équipe, le service Mesh est un bon point de départ. Configurez la solution en quelques minutes, connectez vos réseaux et sécurisez votre trafic. Et, Mesh s’exécutant sur la plateforme Cloudflare One, vous pouvez évoluer vers des fonctionnalités plus avancées au fil du temps : réseau Gateway, politiques DNS et HTTP pour un contrôle précis du trafic, Access for Infrastructure pour la gestion des sessions SSH et RDP, isolement de navigateur pour un accès web sécurisé, DLP pour empêcher les données sensibles de quitter votre réseau, et CASB pour la sécurité SaaS. Vous n’aurez pas à planifier tout cela dès le premier jour. Simplement, lorsque vous en aurez besoin, il ne sera pas nécessaire de migrer.

En ce qui concerne la mise en réseau privée, il a toujours été question de connecter des clients à des ressources : SSH vers un serveur, interrogation d’une base de données, accès à une API interne. Ce qui a changé, c’est l’identité des clients. Il y a un an, les clients étaient vos développeurs et vos services. Aujourd’hui, il s’agit de plus en plus de vos agents.

Il ne s'agit plus d'une simple théorie. Observez l’écosystème : l’explosion des serveurs MCP (Model Context Protocol) donnant accès aux outils, des agents de codage qui doivent lire dans des référentiels et des bases de données privés, des assistants personnels fonctionnant sur du matériel domestique. Chacun de ces modèles suppose que l’agent peut accéder aux ressources dont il a besoin. Lorsque ces ressources sont isolées sur des réseaux privés, l’agent est bloqué.

Cette situation donne lieu à trois flux de travail difficiles à sécuriser aujourd’hui :

1. Accéder à un agent personnel depuis un appareil mobile. Vous exécutez OpenClaw sur un Mac mini chez vous. Vous pouvez y accéder depuis votre téléphone, votre ordinateur portable dans un café ou votre machine de travail. Toutefois, l’exposition de cette application à l’Internet public (même derrière un mot de passe) peut laisser certaines failles ouvertes. Votre agent dispose d’un accès au shell, d’un accès au système de fichiers et d’un accès réseau à votre réseau domestique. Un seul défaut de configuration et n'importe qui peut y avoir accès.

2. Autoriser un agent de codage à accéder à votre environnement de préproduction. Vous utilisez Claude Code, Cursor ou Codex sur votre ordinateur portable. Vous lui demandez de vérifier l’état du déploiement, d’interroger les analyses d’une base de données de préproduction ou de lire des informations issues d’un magasin d’objets interne. Cependant ces services résident dans un VPC cloud privé, par conséquent votre agent ne peut pas les atteindre sans les exposer à Internet ou tunnelliser l’intégralité de votre ordinateur portable vers le VPC.

3. Connecter des agents déployés à des services privés. Vous intégrez des agents à votre produit à l’aide du SDK Agents sur Cloudflare Workers. Ces agents doivent appeler des API internes, interroger des bases de données et accéder à des services qui ne se trouvent pas sur l’Internet public. Ils ont besoin d’un accès privé, mais avec des autorisations limitées, des pistes d’audit et aucune fuite d’identifiants.

Cloudflare Mesh est une connectivité réseau privée conviviale pour les développeurs. Un connecteur léger, binaire, connecte toutes les ressources : vos appareils personnels, vos serveurs distants et vos points de terminaison utilisateur. Il n’est pas nécessaire d’installer des outils distincts pour chaque modèle. Un connecteur sur votre réseau, et chaque modèle d’accès fonctionne.

Une fois connectés, les appareils de votre réseau privé peuvent communiquer entre eux par l’intermédiaire d’adresses IP privées. Le trafic est acheminé par le réseau mondial de Cloudflare, présent dans plus de 330 villes, ce qui améliore la fiabilité et le contrôle sur votre réseau.

Désormais, grâce à Mesh, une solution unique peut résoudre tous les scénarios d’agents que nous avons mentionnés ci-dessus :

• Avec Cloudflare One Client pour iOS sur votre téléphone, vous pouvez connecter en toute sécurité vos appareils mobiles à votre Mac mini local en exécutant OpenClaw via un réseau privé Mesh.

• Avec Cloudflare One Client pour macOS sur votre ordinateur portable, vous pouvez connecter votre ordinateur portable à votre réseau privé afin que vos agents de codage puissent atteindre les bases de données en préproduction ou les API et les interroger.

• Avec les nœuds Mesh sur vos serveurs Linux, vous pouvez connecter les VPC dans des clouds externes, et ainsi permettre aux agents d’accéder aux ressources et aux MCP des réseaux privés externes.

Étant donné que Mesh est optimisé par Cloudflare One Client, chaque connexion hérite des contrôles de sécurité de la plateforme Cloudflare One. Les politiques Gateway s’appliquent au trafic du maillage (Mesh). Les contrôles de niveau de sécurité des appareils valident les appareils connectés. Le filtrage DNS bloque les recherches suspectes. Vous bénéficiez de cette fonctionnalité sans configuration supplémentaire : les mêmes politiques qui protègent votre trafic humain protègent également le trafic de vos agents.

Avec l’introduction de Mesh, vous pourriez vous poser la question suivante : quand devrais-je utiliser Mesh au lieu de Tunnel ? Les deux connectent des réseaux externes de manière privée à Cloudflare, mais ils servent des objectifs différents. Cloudflare Tunnel constitue la solution idéale pour le trafic unidirectionnel, lorsque Cloudflare met en proxy le trafic provenant de la périphérie vers des services privés spécifiques (comme un serveur web ou une base de données). 

Cloudflare Mesh, quant à lui, fournit un réseau entièrement bidirectionnel et de type « plusieurs-à-plusieurs ». Chaque appareil et chaque nœud de votre maillage peuvent accéder les uns aux autres via leur adresse IP privée. Une application ou un agent en cours d’exécution sur votre réseau peut identifier et accéder à n’importe quelle autre ressource située sur le Mesh, sans que chaque ressource ait besoin de son propre Tunnel. 

Cloudflare Mesh vous offre les avantages d’un réseau maillé (résilience, évolutivité élevée, faible latence et performances élevées), mais, dans la mesure où il achemine l’ensemble des ressources via Cloudflare, il résout un problème majeur des réseaux maillés : la traversée NAT.

La majeure partie d’Internet se trouve derrière une NAT (Network Address Translation). Ce mécanisme permet à l’intégralité d’un réseau local d’appareils de partager une adresse IP publique unique en mettant en correspondance le trafic entre les en-têtes publics et les adresses internes privées. Lorsque deux appareils sont derrière la NAT, les connexions directes peuvent échouer et le trafic doit se replier sur les serveurs relais. Si votre infrastructure de relais ne comporte que des points de présence limités, une fraction importante de votre trafic passe par ces relais, ce qui ajoute de la latence et réduit la fiabilité. Et s’il est toujours possible d’héberger vos propres serveurs relais pour compenser, l’opération implique de se charger de la gestion d’une infrastructure supplémentaire simplement pour connecter votre réseau existant.

Cloudflare Mesh fonctionne différemment. Tout le trafic Mesh est acheminé par le réseau mondial de Cloudflare, la même infrastructure qui sert le trafic pour certains des plus grands sites web d’Internet. Pour le trafic transrégional ou multicloud, cette approche devance toujours le routage Internet public. Il n’existe pas de chemin de secours dégradé, car c’est la périphérie de Cloudflare qui est le chemin.

Le routage par Cloudflare signifie également que chaque paquet traverse la pile de sécurité de Cloudflare. C’est l’avantage fondamental qu'il y a à développer Mesh sur la plateforme Cloudflare One : la sécurité n’est pas un produit séparé ajouté a posteriori. En mettant à profit ce même réseau d’infrastructure mondial, nous pouvons dès le premier jour proposer ces piliers fondamentaux à chaque équipe :

50 nœuds et 50 utilisateurs gratuits. Toute votre équipe et votre environnement de préproduction se trouvent sur un réseau privé inclus dans chaque compte Cloudflare. 

Routage périphérique mondial. Plus de 330 villes, routage optimisé dans l'infrastructure. Pas de serveurs relais avec points de présence limités. Pas de chemins de secours dégradés.

Des mesures de contrôle de la sécurité dès le premier jour. Mesh s’exécute sur Cloudflare One. Les politiques Gateway, le filtrage DNS, DLP, l’inspection du trafic et les contrôles du niveau de sécurité des appareils sont tous disponibles sur la même plateforme. Commencez par une connectivité privée simple. Activez les politiques Gateway lorsque vous avez besoin de filtrer le trafic. Activez Access for Infrastructure lorsque vous avez besoin de contrôles au niveau de la session pour SSH et RDP. Utilisez la DLP pour empêcher les données sensibles de quitter votre réseau. Chaque fonctionnalité est accessible par un simple bouton.

Disponibilité élevée. Créez un nœud Mesh avec haute disponibilité et déployez plusieurs connecteurs en utilisant le même jeton en mode actif-passif. Ils annoncent les mêmes itinéraires d’adresses IP, donc en cas de défaillance de l’un d’entre eux, le trafic bascule automatiquement.

Mesh connecte vos agents et vos ressources via des clouds externes, mais vous devez également pouvoir vous connecter depuis vos agents développés sur Workers avec le SDK Agents. Pour ce faire, nous avons étendu Workers VPC afin que l’intégralité de votre réseau maillé soit accessible à Workers et Durable Objects.

Cela signifie que vous pouvez vous connecter à votre réseau Cloudflare Mesh depuis Workers, ce qui rend l’ensemble du réseau accessible à partir d’un seul appel fetch() d’une liaison. Cela complète la prise en charge existante de Workers VPC pour Cloudflare Tunnel, et propose un choix supplémentaire pour la manière dont vous souhaitez sécuriser vos réseaux. Vous pouvez désormais spécifier des réseaux entiers auxquels vous souhaitez vous connecter dans votre fichier wrangler.jsonc. Pour établir une liaison vers votre réseau Mesh, utilisez le mot-clé réservé cf1:network qui assure une liaison au réseau Mesh de votre compte :

"vpc_networks": [
  { "binding": "MESH", "network_id": "cf1:network", "remote": true },
  { "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]

Vous pouvez ensuite l’utiliser au sein de votre Worker ou du code de votre agent :

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    // Reach any internal host on your Mesh, no pre-registration required
    const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");

    // Internal hostname resolved via tunnel's private DNS resolver
    const dbResponse = await env.AWS_VPC.fetch("http://internal-db.corp.local:5432");

    return new Response(await apiResponse.text());
  },
};

En connectant la plateforme Developer à vos réseaux Mesh, vous pouvez créer des instances Workers avec accès sécurisé à vos bases de données privées, ainsi qu’à vos API internes et MCP, ce qui vous permet de concevoir des agents multicloud et des MCP fournissant des capacités d’agent à votre application. Mais cela ouvre également la voie à un monde dans lequel les agents peuvent observer de manière autonome l’intégralité de votre pile de bout en bout, comparer les journaux et suggérer des optimisations en temps réel.

Ensemble, Cloudflare Mesh, Workers VPC et le SDK Agents fournissent à vos agents un réseau privé unifié couvrant à la fois Cloudflare et vos clouds externes. Nous avons fusionné la connectivité et la puissance de calcul afin que vos agents puissent accéder en toute sécurité aux ressources dont ils ont besoin, quel que soit l'endroit où ils se trouvent dans le monde.

Les nœuds de maillage sont vos serveurs, vos machines virtuelles et vos conteneurs. Ils exécutent une version headless de Cloudflare One Client et obtiennent une adresse IP Mesh. Les services communiquent avec des services via des adresses IP privées, dans les deux sens, acheminés via la périphérie de Cloudflare. 

Les appareils sont vos ordinateurs portables et vos téléphones. Ils exécutent le Cloudflare One Client et accèdent directement aux nœuds Mesh : SSH, requêtes de base de données, appels d’API, le tout via des adresses IP privées. Vos agents de codage locaux utilisent cette connexion pour accéder aux ressources privées. 

Les agents sur Workers accèdent aux services via des liaisons réseau VPC de Workers. Ils bénéficient d’un accès limité aux réseaux entiers, assisté par MCP. Le réseau contrôle ce que l’agent peut atteindre. Le serveur MCP régule ce que l’agent peut faire. 

La version actuelle de Mesh établit les fondations d’une connectivité sécurisée et unifiée. Cependant, à mesure que les flux de travail agentiques gagnent en complexité, nous travaillons à aller au-delà de la simple connectivité vers un réseau plus intuitif à gérer et capable de savoir plus en détail qui, ou ce qui, s’adresse à vos services. Voici ce que nous développons pour le reste de l’année.

Nous étendons le routage des noms d’hôtes de Cloudflare Tunnel à Mesh cet été. Vos nœuds Mesh pourront ainsi attirer le trafic de noms d’hôtes privés, comme wiki.local ou api.staging.internal, sans que vous ayez à gérer de listes d’adresses IP ni à vous soucier de la résolution de ces noms d’hôtes à la périphérie de Cloudflare. Acheminez le trafic vers les services par nom, et non par adresse IP. Si votre infrastructure utilise des adresses IP dynamiques, des groupes à évolution automatique ou des conteneurs éphémères, vous êtes débarrassé d'une catégorie entière de problèmes de routage.

Aujourd’hui, vous accédez aux nœuds Mesh par leur adresse IP Mesh : ssh 100.64.0.5. Cela fonctionne, mais ce n’est pas ainsi que vous concevez votre infrastructure. Vous pensez en noms : postgres-staging, api-prod, nikitas-openclaw.

Plus tard dans l'année, nous allons développer Mesh DNS afin que chaque nœud et appareil rejoignant votre maillage obtienne automatiquement un nom d’hôte interne routable. Pas de configuration DNS ni d’enregistrement manuel. Ajoutez un nœud nommé postgres-staging, et postgres-staging.mesh est traduit en adresse IP Mesh correcte depuis n’importe quel appareil présent sur votre maillage.

En complément du routage par nom d’hôte, vous pourrez utiliser la commande ssh postgres-staging.mesh ou curl http://api-prod.mesh:3000/health sans jamais connaître ni gérer d’adresse IP.

Aujourd’hui, les nœuds Mesh s’authentifient auprès de la périphérie de Cloudflare, mais ils partagent une identité au niveau de la couche réseau. Les appareils s’authentifient avec l’identité de l’utilisateur via le Cloudflare One Client, mais les nœuds ne disposent pas encore d’identités distinctes et routables que les politiques de Gateway peuvent différencier.

Nous voulons y remédier. L’objectif est de parvenir à un routage sensible à l’identité pour Mesh, dans lequel chaque nœud, chaque appareil et enfin chaque agent reçoit une identité distincte que les politiques peuvent évaluer. Au lieu d’écrire des règles basées sur des plages d’adresses IP, vous écrivez des règles basées sur qui ou ce qui se connecte.

En ce qui concerne les agents, c’est ce qui importe le plus. Aujourd’hui, lorsqu’un agent exécuté sur Workers appelle un outil via une liaison VPC, le service cible voit un Worker effectuer une requête. Il ne sait pas quel agent appelle, qui l’a autorisé, ni le champ d'action qui lui a été accordé. Du côté de Mesh, lorsqu’un agent de codage local présent sur votre ordinateur portable accède à un service de préproduction, Gateway voit l’identité de votre appareil, mais pas celle de l’agent.

Nous travaillons à la mise en place d’un modèle dans lequel les agents seront caractérisés par leur propre identité sur le réseau :

• Donneur d'ordre/commanditaire : l’humain qui a autorisé l’action (Nikita de l’équipe chargée de la plateforme)

• Agent : le système IA qui exécute l'action (l’assistant de déploiement, session #abc123)

• Champ d’application : ce que l’agent est autorisé à faire (lire les déploiements, déclencher des restaurations, rien d’autre)

Ce modèle permettrait ainsi de rédiger des politiques telles que : les lectures issues des agents de Nikita sont autorisées, mais les écritures nécessitent directement Nikita. Le trafic des agents peut être filtré indépendamment du trafic humain. L’accès au réseau d’un agent peut être révoqué sans toucher à ceux de Nikita.

L’infrastructure nécessaire à cela est en place. Les nœuds Mesh assurent le provisionnement avec des jetons par nœud, les appareils s’authentifient avec l’identité de chaque utilisateur et les liaisons VPC Workers définissent l’accès par service. Il ne reste plus désormais qu'à rendre ces identités visibles à la couche de politique, afin que Gateway puisse prendre des décisions de routage et d’accès en fonction de ces identités. Nous y travaillons.

Aujourd’hui, les nœuds Mesh fonctionnent sur des machines virtuelles et des serveurs Linux dédiés. Cependant, les infrastructures modernes fonctionnent de plus en plus dans des conteneurs : pods Kubernetes, piles Docker Compose, instances d’exécution de code CI/CD éphémères. Nous sommes en train de créer une image Docker Mesh qui vous permettra d’ajouter un nœud Mesh à n’importe quel environnement conteneurisé.

Cela signifie que vous serez en mesure d’inclure un kit d’extension Mesh dans votre pile Docker Compose et de prévoir un accès au réseau privé pour chaque service de cette pile. Un microservice exécuté dans un conteneur de votre cluster de préproduction pourrait accéder à une base de données de votre VPC de production via Mesh, sans qu’aucun des deux services n’ait besoin d’un point de terminaison public.

Cette possibilité est également utile pour les pipelines CI/CD qui peuvent accéder à l’infrastructure privée pendant les générations et les tests : votre exécuteur GitHub Actions extrait l’image du conteneur Mesh, accède à votre réseau, exécute des tests d’intégration dans votre environnement de préproduction, puis se déconnecte. Le tout sans identifiants VPN à gérer ni tunnels persistants à entretenir : le nœud disparaît au départ du conteneur.

Nous estimons que l’image Mesh Docker sera disponible plus tard dans l’année.

Tandis que nous continuons à faire évoluer ces fonctionnalités de gestion de l’identité et du routage, les fondations d’une connectivité réseau sécurisée et unifiée sont disponibles dès aujourd’hui. Vous pouvez commencer à relier vos clouds et à sécuriser vos agents en quelques minutes seulement.

Démarrez Cloudflare Mesh : accédez à Networking > Mesh dans le tableau de bord Cloudflare. Gratuit jusqu’à 50 nœuds et 50 utilisateurs.

Développez des agents avec le SDK Agents et le VPC Workers : installez le SDK Agents (`npm i agents`), suivez le guide de démarrage rapide Workers VPC et développez un serveur MCP distant avec un accès backend privé.

Vous êtes déjà sur Cloudflare One ? La solution Mesh s’intègre à votre configuration existante. Vos politiques Gateway, vos mesures de contrôle du niveau de sécurité des appareils et vos règles d’accès s’appliquent automatiquement au trafic Mesh. Consultez la documentation de Mesh pour ajouter votre premier nœud.