Sichere nichtöffentliche Netzwerke für alle: Nutzer, Netzwerkknoten, Agenten und Workers – mit Cloudflare Mesh

Durch KI-Agenten hat sich der Blick auf den nichtöffentlichen Netzwerkzugang verändert: Coding-Agenten müssen Abfragen an Staging-Datenbanken stellen, Produktionsagenten müssen interne API aufrufen und persönliche KI-Assistenten müssen Dienste in Heimnetzwerken erreichen. Clients sind heute nicht mehr nur Menschen oder Dienste, sondern auch autonom laufende Agenten, die nicht explizit genehmigte Anfragen an eine Infrastruktur richten, deren Sicherheit gewährleistet werden muss.

Jeder dieser Workflows wirft das gleiche Problem auf: Agenten müssen auf nichtöffentliche Ressourcen zugreifen, doch die Werkzeuge dafür wurden für Menschen entwickelt, nicht für autonome Software. VPN erfordern eine interaktive Anmeldung. SSH-Tunnel müssen manuell eingerichtet werden. Dienste öffentlich zugänglich zu machen, schafft ein Sicherheitsrisiko. Und bei keinem dieser Ansätze hat man Einblick in das, was der Agent wirklich tut, sobald er die Verbindung einmal hergestellt hat.

Heute stellen wir Cloudflare Mesh zur Vernetzung nichtöffentlicher Netzwerke und zur Ermöglichung eines sicheren Zugriffs durch Agenten vor. Mesh wird auch in die Entwickler-Plattform von Cloudflare integriert. Damit können Workers, Durable Objects und Agenten, die mit dem Agenten-SDK erstellt wurden, nichtöffentliche Infrastruktur direkt erreichen.

Wenn Sie die SASE- und Zero Trust-Produktreihe von Cloudflare One nutzen, steht Ihnen Mesh bereits zur Verfügung. Für die Absicherung von Agenten-Workloads ist kein neues technologisches Konzept erforderlich. Benötigt wird ein für das Agenten-Zeitalter geschaffenes SASE-Modell, und das bietet Cloudflare One. Cloudflare Mesh ist ein neues, einfacher gestaltetes Produkt, das die bereits vertrauten Zugangswege nutzt: den WARP Connector (jetzt Cloudflare Mesh-Netzwerkknoten) und den WARP Client (jetzt Cloudflare One Client). Zusammen bilden diese ein nichtöffentliches Netzwerk für den Traffic von Menschen und Agenten. Mesh wird direkt in Ihre bestehende Cloudflare One-Bereitstellung integriert. Ihre vorhandenen Gateway-Richtlinien, Zugriffsregeln und Gerätestatusprüfungen werden automatisch auf Mesh-Datenverkehr angewandt.

Wenn Sie als Entwickler einfach nur nichtöffentliche Netzwerke für Ihre Agenten, Dienste und Ihr Team benötigen, ist Mesh der Einstiegspunkt. Es dauert nur wenige Minuten, die Lösung einzurichten, Ihre Netzwerke zu verbinden und Ihren Traffic abzusichern. Da Mesh auf der Cloudflare One-Plattform läuft, können im Lauf der Zeit anspruchsvollere Funktionen eingegliedert werden: Gateway-Netzwerk-, DNS- und HTTP-Richtlinien für eine präzise Traffic-Kontrolle, Access for Infrastructure für die Verwaltung von SSH- und RDP-Sitzungen, Browserisolierung für sicheren Webzugriff, DLP, um zu verhindern, dass vertrauliche Daten Ihr Netzwerk verlassen, und CASB für SaaS-Sicherheit. Sie müssen nicht alles vom ersten Tag an genau planen: Sie sind nur einfach nicht gezwungen, eine Migration vorzunehmen, wenn Sie eine dieser Funktionen irgendwann benötigen.

Bei nichtöffentlichen Netzwerken ging es schon immer darum, Clients mit Ressourcen zu verbinden – per SSH zu einem Server, zur Abfrage einer Datenbank oder für den Zugriff auf eine interne API. Was sich geändert hat, ist die Identität der Clients. Vor einem Jahr waren es Ihre Entwickler und Ihre Dienste. Heute sind es zunehmend Ihre Agenten.

Das ist keine theoretische Überlegung. Man muss sich nur das Ökosystem anschauen, etwa die explosionsartige Zunahme von MCP (Model Context Protocol)-Servern, die Tool-Zugriff ermöglichen, Programmier-Agenten, die Daten aus nichtöffentlichen Repositorys und Datenbanken lesen müssen, oder persönliche Assistenten, die auf Heimhardware laufen. Jeder dieser Fälle setzt voraus, dass der Agent die benötigten Ressourcen erreichen kann. Wenn diese Ressourcen also in nichtöffentlichen Netzwerken isoliert sind, kommt der Agent nicht weiter.

Es sind drei Arten von Workflows zu verzeichnen, die sich aktuell schwer absichern lassen:

1. Zugriff auf einen persönlichen Agenten von einem Mobilgerät aus: Sie nutzen OpenClaw auf einem Mac mini, der sich bei Ihnen zu Hause befindet, und möchten von Ihrem Handy, Ihrem Laptop im Café oder Ihrem Rechner bei der Arbeit darauf zugreifen. Doch wenn Sie den Dienst über das öffentliche Internet zugänglich machen (selbst mit Passwortschutz), könnten dadurch Sicherheitslücken entstehen. Ihr Agent hat in Ihrem Heimnetzwerk Shell-, Dateisystem- und Netzwerkzugriff. Es genügt ein einziger Konfigurationsfehler, und schon ist alles für jedermann zugänglich.

2. Zugriff eines Coding-Agenten auf eine Staging-Umgebung: Sie verwenden Claude Code, Cursor oder Codex auf Ihrem Laptop. Sie weisen den Agenten an, den Implementierungsstatus zu prüfen, Analysedaten aus einer Staging-Datenbank abzufragen oder Daten aus einem internen Objektspeicher zu lesen. Diese Dienste befinden sich jedoch in einer Virtual Private Cloud (VPC), sodass Ihr Agent sie nicht erreichen kann, ohne sie dem Internet auszusetzen oder für Ihren gesamten Laptop einen Tunnel in die VPC herzustellen.

3. Verbindung implementierter Agenten mit nichtöffentlichen Diensten: Sie integrieren mithilfe des Agenten-SDK bei Cloudflare Workers Agenten in Ihr Produkt. Diese Agenten müssen interne API aufrufen, Datenbanken abfragen und auf Dienste zugreifen können, die sich nicht im öffentlichen Internet befinden. Sie benötigen Zugang zu diesen nichtöffentlichen Systemen, aber mit begrenzten Berechtigungen, Prüfprotokollen und ohne, dass dabei Anmeldedaten offengelegt werden.

Cloudflare Mesh ist eine entwicklerfreundliche Lösung für nichtöffentliche Netzwerke. Ein schlanker Connector, eine Binärdatei, verbindet alles: Ihre persönlichen Geräte, Ihre Remote-Server und Ihre Nutzer-Endpunkte. Sie müssen nicht für jedes Szenario separate Tools installieren. Es genügt ein einziger Connector für Ihr Netzwerk, und schon funktioniert jede Art des Zugriffs.

Sobald die Verbindung hergestellt ist, können die Geräte in Ihrem nichtöffentlichen Netzwerk über private IP-Adressen miteinander kommunizieren. Das Routing erfolgt über das Netzwerk von Cloudflare, das sich über mehr als 330 Städte weltweit erstreckt. Das sorgt für höhere Zuverlässigkeit und bietet Ihnen größere Kontrolle über Ihr Netzwerk.

Mit Mesh deckt nun eine einzige Lösung alle gerade beschriebenen Agenten-Zugriffswege ab:

• Mit Cloudflare One Client für iOS auf Ihrem Handy können Sie Ihre Mobilgeräte über ein nichtöffentliches Mesh-Netzwerk sicher mit Ihrem lokalen Mac mini verbinden, auf dem OpenClaw läuft.

• Mit Cloudflare One Client für macOS auf Ihrem Laptop können Sie Ihren Laptop mit Ihrem nichtöffentlichen Netzwerk verbinden, damit Ihre Coding-Agenten auf Staging-Datenbanken oder API zugreifen und Abfragen an diese stellen können.

• Mit Mesh-Netzwerkknoten auf Ihren Linux-Servern können Sie VPC in externen Clouds miteinander vernetzen, sodass Agenten auf Ressourcen und MCP-Server in externen nichtöffentlichen Netzwerken zugreifen können.

Da Mesh den Cloudflare One Client nutzt, werden auf jede Verbindung die Sicherheitskontrollen der Cloudflare One-Plattform angewandt. Für Mesh-Datenverkehr gelten Gateway-Richtlinien, Gerätestatusprüfungen validieren die verbundenen Geräte und die DNS-Filterung fängt verdächtige Anfragen ab. Eine zusätzliche Konfiguration ist dafür nicht erforderlich: Dieselben Richtlinien, die den von Menschen generierten Datenverkehr absichern, schützen auch den Agenten-Traffic.

Sie könnten sich die Frage stellen, wann es sinnvoller ist, Mesh anstelle von Tunnel zu nutzen. Beide Produkte verbinden externe Netzwerke auf vertrauliche Weise mit Cloudflare, doch sie dienen unterschiedlichen Zwecken. Cloudflare Tunnel ist die ideale Lösung für unidirektionalen Datenverkehr, der von Cloudflare per Proxy von der Edge zu bestimmten nichtöffentlichen Diensten (wie einem Webserver oder einer Datenbank) geleitet wird. 

Cloudflare Mesh dagegen bietet ein vollständig bidirektionales „Many-to-many“-Netzwerk: Alle Geräte und Knoten in Ihrem Mesh-Netzwerk können mithilfe nichtöffentlicher IP-Adressen aufeinander zugreifen. Eine Anwendung oder ein Agent kann jede andere Ressource im selben Mesh-Netzwerk erkennen und darauf zugreifen, ohne dass die einzelnen Ressourcen dafür einen gesonderten Tunnel benötigen. 

Cloudflare Mesh bietet die Vorteile eines Mesh-Netzwerks (Ausfallsicherheit, hohe Skalierbarkeit, geringe Latenz und hohe Performance). Gleichzeitig wird dadurch, dass das Routing über Cloudflare läuft, eine wesentliches Problem von Mesh-Netzwerken beseitigt: NAT-Traversal.

Dem größten Teil des Internets ist NAT (Network Address Translation) vorgeschaltet. Dieses Verfahren ermöglicht es einem ganzen lokalen Netzwerk von Geräten, eine einzige öffentliche IP-Adresse gemeinsam zu nutzen, indem der Datenverkehr zwischen öffentlichen Headern und nichtöffentlichen internen Adressen kartographiert wird. Wenn zwei Geräte NAT nachgeschaltet sind, können direkte Verbindungen fehlschlagen. Dann muss der Traffic auf Relay-Server ausweichen. Verfügt Ihre Relay-Infrastruktur jedoch nur über eine begrenzte Anzahl von Points of Presence, landet ein beträchtlicher Teil Ihres Datenverkehrs bei diesen Relays, was die Latenz erhöht und die Zuverlässigkeit verringert. Um das zu kompensieren, können Sie Ihre Relay-Server selbst hosten. Dann müssen Sie aber zusätzliche Infrastruktur verwalten, nur um Ihr bestehendes Netzwerk zu verbinden.

Cloudflare Mesh geht einen anderen Weg. Der gesamte Mesh-Datenverkehr wird über das globale Netzwerk von Cloudflare geleitet – dieselbe Infrastruktur, über die auch Traffic an einige der größten Websites des Internets übermittelt wird. Bei regionsübergreifendem Datenverkehr oder Multi-Cloud-Traffic liefert dies durchweg bessere Ergebnisse als das Routing über das öffentliche Internet. Weil die Cloudflare-Edge der Pfad ist, gibt es keinen beeinträchtigten Alternativpfad.

Das Routing über Cloudflare bedeutet auch, dass jedes Paket den Sicherheitsstack von Cloudflare durchläuft. Das ist der entscheidende Vorteil davon, dass Mesh auf der Cloudflare One-Plattform aufbaut: Sicherheit wird dem System nicht nachträglich übergestülpt. Und da wir dasselbe globale Backbone nutzen, können wir jedem Team vom ersten Tag an die folgenden Kernelemente bieten:

50 Netzwerkknoten und 50 Nutzer kostenlos. Ihr gesamtes Team und Ihre gesamte Staging-Umgebung in einem einzigen nichtöffentlichen Netzwerk – in jedem Cloudflare-Konto inbegriffen. 

Globales Edge-Routing. Über 330  Städte, optimiertes Backbone-Routing. Keine Relay-Server mit einer begrenzten Zahl von Points of Presence. Keine beeinträchtigten Ausweichpfade.

Sicherheitskontrollen vom ersten Tag an. Mesh läuft auf Cloudflare One. Gateway-Richtlinien, DNS-Filterung, DLP, Traffic-Kontrolle und Prüfung des Gerätestatus sind jeweils auf derselben Plattform verfügbar. Legen Sie jetzt los mit unkomplizierter nichtöffentlicher Konnektivität. Aktivieren Sie die Gateway-Richtlinien, wenn Sie eine Traffic-Filterung benötigen. Aktivieren Sie Access for Infrastructure, wenn Sie Kontrollen auf Sitzungsebene für SSH und RDP benötigen. Fügen Sie DLP hinzu, wenn Sie das Abfließen sensibler Daten aus Ihrem Netzwerk unterbinden müssen. Jede Funktion ist nur einen Klick entfernt.

Hohe Verfügbarkeit. Sie können einen Mesh-Netzwerkknoten mit aktivierter Hochverfügbarkeit erstellen und mehrere Konnektoren mit demselben Token im Aktiv-Passiv-Modus aufsetzen. Diese kündigen dieselben IP-Routen an, sodass bei einem Ausfall einer Route für den Datenverkehr automatisch ein Failover vorgenommen wird.

Mesh verbindet Ihre Agenten und Ressourcen über externe Clouds. Doch Sie müssen auch in der Lage sein, von Agenten aus, die mit dem Agenten-SDK auf Workers erstellt wurden, eine Verbindung herzustellen. Zu diesem Zweck haben wir Workers VPC erweitert, um Ihr gesamtes Mesh-Netzwerk für Workers und Durable Objects zugänglich zu machen.

Somit können Sie sich von Workers aus mit Ihrem Cloudflare Mesh-Netzwerk verbinden. Dadurch ist das gesamte Netzwerk über den fetch()-Aufruf einer einzigen Bindung zugänglich. Dies ergänzt die bestehende Unterstützung von Workers VPC für Cloudflare Tunnel und bietet Ihnen mehr Wahlmöglichkeiten bei der Absicherung Ihrer Netzwerke. Sie können jetzt in Ihrer wrangler.jsonc-Datei vollständige Netzwerke angeben, mit denen Sie eine Verbindung herstellen möchten. Um eine Bindung zu Ihrem Mesh-Netzwerk herzustellen, können Sie das diesem Zweck vorbehaltene Schlüsselwort cf1:network nutzen, das mit dem Mesh-Netzwerk Ihres Kontos verknüpft ist:

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

Danach können Sie es in Ihrem Worker oder Ihrem Agenten-Code verwenden:

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());
  },
};

Durch die Verbindung der Entwicklerplattform mit Ihren Mesh-Netzwerken können Sie Workers erstellen, die sicheren Zugang zu Ihren nichtöffentlichen Datenbanken, internen API und MCP-Servern haben. So lassen sich Cloud-übergreifende Agenten und MCP-Server erstellen, die Ihre Anwendung mit Agenten-Funktionen ausstatten. Damit eröffnet sich auch die Möglichkeit, dass Agenten autonom Ihren gesamten Stack lückenlos beobachten, Protokolle mit Querverweisen versehen und in Echtzeit Optimierungsmaßnahmen vorschlagen.

Gemeinsam bilden Cloudflare Mesh, Workers VPC und das Agenten-SDK ein einheitliches nichtöffentliches Netzwerk für Ihre Agenten, das sowohl Cloudflare als auch Ihre externen Clouds abdeckt. Wir haben Konnektivität und Rechenleistung zusammengeführt, damit Ihre Agenten die benötigten Ressourcen sicher erreichen können, wo auch immer auf der Welt sie sich befinden.

Mesh-Netzwerkknoten sind Ihre Server, VM und Container. Sie führen eine Headless-Version von Cloudflare One Client aus und erhalten eine Mesh-IP-Adresse. Dienste kommunizieren bidirektional über nichtöffentliche IP-Adressen untereinander und werden über die Cloudflare-Edge geroutet. 

Geräte sind Ihre Laptops und Telefone. Sie führen den Cloudflare One Client aus und erreichen die Mesh-Netzwerkknoten direkt – ob per SSH, für Datenbankabfragen oder API-Aufrufe: alles läuft über nichtöffentliche IP-Adressen. Ihre lokalen Coding-Agenten nutzen diese Verbindung für den Zugriff auf nichtöffentliche Ressourcen. 

Agenten auf Workers erreichen nichtöffentliche Dienste über Workers VPC Network-Bindungen. Vermittelt durch MCP erhalten sie begrenzten Zugriff auf vollständige Netzwerke. Das Netzwerk setzt durch, wozu der Agent Zugang hat, und der MCP-Server setzt durch, was der Agent tun kann. 

Die aktuelle Version von Mesh bildet die Grundlage für eine sichere, einheitliche Konnektivität. Doch Agenten-Workflows werden immer komplexer. Deshalb konzentrieren wir uns nun darauf, über die einfache Konnektivität hinaus ein Netzwerk zu schaffen, das intuitiver zu verwalten ist und eine klarere Vorstellung davon hat, wer oder was mit Ihren Diensten kommuniziert. Dies sind unsere Projekte für den Rest des Jahres:

Diesen Sommer erweitern wir das Hostnamen-Routing von Cloudflare Tunnel auf Mesh. Ihre Mesh-Netzwerkknoten sind in der Lage, Datenverkehr für nichtöffentliche Hostnamen wie wiki.local oder api.staging.internal anzuziehen, ohne dass Sie IP-Listen verwalten oder sich Gedanken darüber machen müssen, wie diese Hostnamen an der Cloudflare-Edge aufgelöst werden. Der Traffic kann anhand von Namen anstelle von IP-Adressen zu den gewünschten Diensten geleitet werden. Wenn Ihre Infrastruktur dynamische IP-Adressen, automatisch skalierende Gruppen oder kurzlebige Container nutzt, werden dadurch eine ganze Reihe von Routing-Problemen beseitigt.

Aktuell erreichen Sie Mesh-Netzwerkknoten über ihre Mesh-IP-Adressen: ssh 100.64.0.5. Das funktioniert zwar, aber Sie sollten Ihre Infrastruktur nicht auf diese Weise betrachten. Sie denken in Namen: postgres-staging, api-prod oder nikitas-openclaw.

Im weiteren Jahresverlauf werden wir Mesh DNS entwickeln, sodass allen Netzwerkknoten und Geräten, die in Ihr Mesh-Netzwerk aufgenommen werden, automatisch ein für das Routing nutzbarer interner Hostname zugewiesen wird. Eine DNS-Konfiguration oder manuelle Einträge sind nicht erforderlich. Wenn Sie einen Knoten namens postgres-staging hinzufügen, kann postgres-staging.meshfür jedes Gerät in Ihrem Mesh-Netzwerk die Auflösung zur richtigen Mesh-IP-Adresse durchführen.

In Kombination mit dem Hostnamen-Routing können Sie ssh postgres-staging.mesh oder curl http://api-prod.mesh:3000/health nutzen, ohne jemals eine IP-Adresse kennen oder verwalten zu müssen.

Heute authentifizieren sich Mesh-Netzwerkknoten individuell gegenüber der Cloudflare-Edge, aber auf Netzwerkschicht nutzen sie eine gemeinsame Identität. Geräte authentifizieren sich mit einer Nutzeridentität über den Cloudflare One Client, aber die Netzwerkknoten verfügen noch nicht über eindeutige, für das Routing nutzbare Identitäten, die durch Gateway-Richtlinien auseinander gehalten werden können.

Wir wollen das ändern. Das Ziel ist ein identitätsbezogenes Routing für Mesh, bei dem jeder Netzwerkknoten, jedes Gerät und schließlich jeder Agent eine eindeutige Identität erhält, die von Richtlinien ausgewertet werden kann. Anstatt Regeln auf Grundlage von IP-Adressbereichen zu schreiben, werden Sie Regeln basierend darauf verfassen können, wer oder was sich verbindet.

Am relevantesten ist das für Agenten. Wenn heute ein auf Workers laufender Agent ein Tool über eine VPC-Bindung aufruft, sieht der angesteuerte Dienst, dass ein Worker eine Anfrage stellt. Er weiß jedoch nicht, von welchem Agent der Aufruf kommt, wer ihn autorisiert hat oder welcher Handlungsspielraum gewährt wurde. Wenn auf Mesh-Seite ein lokaler Coding-Agent auf Ihrem Laptop einen Staging-Dienst erreicht, sieht Gateway die Identität Ihres Geräts, aber nicht die des Agenten.

Wir arbeiten an einem Modell, bei dem die Agenten ihre eigene Identität auf ihrem Weg durch das Netzwerk mitführen:

• Verantwortliche/r: Die Person, die den Vorgang autorisiert hat (Nikita aus dem Plattform-Team)

• Agent: Das KI-System, das diesen Vorgang ausführt (der Bereitstellungsassistent, Sitzung #abc123)

• Handlungsbereich: Was der Agent tun darf (ausschließlich Bereitstellungen lesen und Rollbacks auslösen)

Damit lassen sich Richtlinien schreiben wie: „Lesevorgänge von Nikitas Agenten sind erlaubt, aber Schreibvorgänge sind nur Nikita selbst gestattet.“ Der Agenten-Traffic kann unabhängig von dem Datenverkehr gefiltert werden, der von Menschen generiert wurde. Folglich lässt sich der Netzwerkzugang eines Agenten widerrufen, ohne dass davon Nikitas Netzwerkzugang berührt wird.

Die Infrastruktur dafür ist vorhanden. Mesh-Netzwerkknoten stellen individuelle Token bereit, Geräte authentifizieren sich mit einer Identität pro Nutzer und Workers VPC-Bindungen legen den Zugriff für jeden Dienst separat fest. Zurzeit ist es aber nicht möglich, diese Identitäten für die Richtlinienebene sichtbar zu machen, damit Gateway darauf basierend Routing- und Zugriffsentscheidungen treffen kann. Genau daran arbeiten wir gerade.

Derzeit laufen Mesh-Netzwerkknoten auf VM und Bare Metal-Linux-Servern. Doch moderne Infrastruktur wird zunehmend in Containern betrieben – ob Kubernetes-Pods, Docker Compose-Stacks oder kurzlebige CI/CD-Runner. Wir entwickeln ein Mesh-Docker-Image, mit dem Sie jeder containerisierten Umgebung einen Mesh-Netzwerkknoten hinzufügen können.

Das bedeutet, dass Sie einen Mesh-Sidecar in Ihren Docker Compose-Stack aufnehmen und jedem Dienst in diesem Stack nichtöffentlichen Netzwerkzugriff gewähren können. Ein Microservice, der in einem Container in Ihrem Staging-Cluster läuft, könnte über Mesh eine Datenbank in Ihrer Produktions-VPC erreichen, ohne dass einer der Dienste einen öffentlichen Endpunkt benötigt.

Das ist auch für CI/CD-Pipelines nützlich, die während Builds und Tests auf nichtöffentliche Infrastruktur zugreifen können: Ihr GitHub Actions Runner ruft das Mesh-Container-Image ab, verbindet sich mit Ihrem Netzwerk, führt Integrationstests unter Abgleich mit Ihrer Staging-Umgebung durch und fährt danach wieder herunter. All dies erfolgt ohne VPN-Anmeldedaten, die verwaltet werden müssen, oder dauerhaft zu pflegende Tunnel: Der Netzwerkknoten verschwindet, wenn der Container beendet wird.

Wir erwarten, das Mesh Docker-Image noch in diesem Jahr bereitstellen zu können.

Wir entwickeln diese Identitäts- und Routingfunktionen kontinuierlich weiter, doch die Grundlage für sichere, einheitliche Netzwerke ist bereits heute verfügbar. Sie können in wenigen Minuten damit beginnen, Ihre Clouds zu verbinden und Ihre Agenten zu schützen.

Erste Schritte mit Cloudflare Mesh: Rufen Sie im Cloudflare-Dashboard „Networking“ (Netzwerke) > „Mesh“ auf. Kostenlos für bis zu 50 Netzwerkknoten und 50 Nutzer.

Agenten erstellen mit dem Agenten-SDK und Workers VPC: Installieren Sie das Agenten-SDK (`npm i agents`), folgen Sie dem Workers VPC-Quickstart und erstellen Sie einen Remote-MCP-Server mit nichtöffentlichem Backend-Zugriff.

Sie nutzen Cloudflare One bereits? Mesh funktioniert mit Ihrem bestehenden Setup. Ihre Gateway-Richtlinien, Gerätestatus-Prüfungen und Zugriffsregeln werden automatisch auf Mesh-Traffic angewandt. Wie Sie Ihren ersten Netzwerkknoten erstellen, können Sie der Mesh-Dokumentation entnehmen.