Cloudflare erkennt Schatten-MCP im Netzwerk
Cloudflare Gateway erkennt MCP-Verkehr über Protokollsignale und kann ungenehmigte Verbindungen blockieren – mit klaren Grenzen.
Cloudflare will das Problem lösen, das jedes Sicherheitsteam mit Agenten hat: Niemand weiß, welche MCP-Verbindungen im eigenen Netz überhaupt laufen. Neue Funktionen in Cloudflare One erkennen inspizierten MCP-Verkehr, machen die erzeugenden Nutzer und Server sichtbar und kontrollieren direkte Verbindungen auf verwalteten Netzwerkpfaden. MCP steht für Model Context Protocol – die Schnittstelle, über die KI-Agenten Werkzeuge und Datenquellen ansprechen.
Damit wandert ein Kontrollpunkt für Agentenverkehr dorthin, wo Unternehmen ihre Netzwerkregeln ohnehin durchsetzen.
Ein Protokoll ohne feste Adresse
Das Unbequeme an MCP benennt Cloudflare selbst: Verbindungen nutzen weder einen garantierten Hostnamen noch zwingend /mcp im Pfad. Eine Domainliste reicht deshalb nicht. Gateway greift stattdessen auf Protokollsignale zurück und inspiziert protokollspezifische Header und Payload-Merkmale, um Schattenverkehr aufzuspüren.
Der Ansatz setzt früher an als eine Inventur bekannter MCP-Server. Statt nur genehmigte Ziele aufzulisten, sieht das Security-Team zunächst, welche Nutzer und Server überhaupt MCP-Verkehr erzeugen. Das ist ein brauchbarer Kontrollpunkt gegen Verbindungen, die außerhalb des vorgesehenen Zugangswegs entstehen.
Sehen, blockieren oder isolieren
Sichtbarkeit allein ändert wenig. Das AI-Security-Dashboard zeigt deshalb das gesamte MCP-Anfragevolumen, eindeutige Nutzer und eindeutige MCP-Server – drei Kennzahlen, mit denen sich das Ausmaß einer Schattenlandschaft abschätzen lässt.
Zur Durchsetzung kommt in HTTP-Richtlinien der neue Is-MCP-Selektor hinzu, im Feld experimental.is_mcp. Eine Regel kann MCP-Verkehr damit erlauben, blockieren oder isolieren. Der Selektor ist Beta und kann sich vor der allgemeinen Verfügbarkeit ändern; harte produktive Regeln brauchen deshalb eine kontrollierte Einführung. Cloudflare nennt als Beispiel eine Richtlinie, die MCP-Verkehr blockiert, sobald er nicht über ein genehmigtes MCP-Portal läuft.
Auf der Serverseite ergänzt WriteGuard die Kontrolle differenzierter: Lesezugriffe passieren unverändert, während zugelassene Schreibzugriffe eine Agenten-Zuordnung und ein Audit-Ereignis erhalten. Diese serverseitigen Kontrollen lassen sich laut Cloudflare nicht durch einen Clientwechsel oder das Abschalten eines lokalen Hooks umgehen. Die Trennung von Lesen und Schreiben setzt dort an, wo ein Agent tatsächlich Daten oder Systeme verändert.
Der Netzwerkpfad bleibt eine Grenze
Cloudflare beschreibt ausdrücklich inspizierten Verkehr auf verwalteten Netzwerkpfaden. Die neuen Anzeigen sind daher kein vollständiges Inventar jedes Agenten und jeder MCP-Verbindung. Wer aus dem Dashboard eine Vollständigkeitsaussage ableitet, überdehnt die Zahlen.
Auch erlaubter MCP-Verkehr ist nicht automatisch korrekt. Die Protokollerkennung beantwortet, welcher Nutzer mit welchem Server spricht und ob der gewählte Weg zugelassen ist. Ob eine Agentenaktion fachlich sinnvoll ist, prüft sie nicht.
Das ist die entscheidende Grenze des Releases: Gateway kann Schatten-MCP sichtbar machen und einen genehmigten Zugangspfad erzwingen, ersetzt aber keine Kontrolle der Aktionen hinter diesem Pfad. Security- und Plattformteams sollten den Beta-Selektor zuerst zum Messen nutzen, dann Ausnahmen prüfen und erst danach blockierende Regeln scharf stellen.
Transparenz
agentenlog.de nutzt KI-Assistenz für Recherche, Struktur und Entwurf. Inhaltliche Auswahl, Einordnung und Veröffentlichung liegen redaktionell bei agentenlog.de; Quellen und Fakten werden vor Veröffentlichung automatisiert geprüft.
Quellen
Das könnte dich auch interessieren
Anthropic zeigt die Konfliktrisiken von Agentenschwärmen
Anthropics Multiagenten-Versuche zeigen: Gemeinsame Schreibrechte brauchen klare Zielhierarchien, begrenzte Berechtigungen und einen Rollback-Pfad.
MCP wird zustandslos: Was sich für Agenteninfrastruktur verschiebt
Die MCP-Spezifikation vom 28. Juli löst sich von transportgebundenen Sitzungen. Das verändert den Betrieb verteilter Tool-Server.
Eigene Tools & Skills bauen – Teil 3 der Serie KI-Agenten in der Praxis
Wie du sichere Tools und Skills für KI-Agenten entwickelst – mit nachvollziehbaren Beispielen für OpenClaw, LangChain und MCP.