Zayo bringt KI-Agenten per MCP-Server direkt in den Netzwerkbetrieb

Zayo macht Netzwerk-Infrastruktur agentenfähig

Am 8. September 2026 hat Zayo, einer der größten unabhängigen Glasfaser- und Netzbetreiber Nordamerikas und Europas, mit „Agentic Networking" eine Erweiterung seiner agentischen Netzwerkplattform DynamicLink vorgestellt. Der Zeitpunkt ist kein Zufall: DynamicLink selbst war im September 2025 als Self-Service-Portal für On-Demand-Netzwerkverbindungen gestartet – Kunden konnten Bandbreite und Konnektivität per Klick statt per Ticket buchen. Ein Jahr später geht Zayo den nächsten Schritt und schaltet nach eigener Darstellung den ersten produktiven MCP-Server, der eigens für Networking gebaut wurde, für den allgemeinen Einsatz frei.

Der Unterschied zu bisherigen KI-Initiativen im Netzwerkbetrieb ist grundlegend. Bislang beschränkten sich die meisten „KI im NOC"-Projekte auf Assistenzfunktionen: Ein Agent fasst Logs zusammen, schlägt eine Diagnose vor, der Mensch tippt den Befehl. Mit Agentic Networking verschiebt sich diese Grenze. Autorisierte Agenten erhalten über den MCP-Server nicht nur Lesezugriff auf Telemetrie und Topologie, sondern auch ausführbare Werkzeuge – sie können produktive Änderungen an der Netzwerkkonfiguration selbst vornehmen, innerhalb der vom Kunden definierten Grenzen. Das ist der Punkt, an dem aus einem Chatbot mit Netzwerkwissen ein Akteur mit echter Handlungsmacht wird.

Für die Einordnung lohnt ein Blick auf Zayos Größe: Das Unternehmen betreibt ein globales Glasfasernetz mit Zehntausenden Streckenkilometern und einer dreistelligen Zahl an Rechenzentrums- und Cloud-Interconnect-Standorten. Wenn ein Betreiber dieser Größenordnung KI-Agenten produktiven Durchgriff auf seine Infrastruktur gibt, ist das mehr als ein Pilotprojekt – es ist ein Signal an den gesamten Markt, dass agentische Systeme in der kritischen Infrastruktur angekommen sind.

Was ein MCP-Server für Netzwerk-Operations überhaupt leistet

Das Model Context Protocol (MCP) ist ein offener Standard, über den Sprachmodell-Agenten strukturiert auf externe Werkzeuge, Datenquellen und Kontext zugreifen – unabhängig davon, mit welchem LLM sie betrieben werden. Statt für jede Kombination aus Modell und System eine eigene Integration zu schreiben, spricht der Agent ein einheitliches Protokoll, und der MCP-Server auf der anderen Seite übersetzt das in systemspezifische Aufrufe: eine Abfrage der aktuellen Verbindungstopologie, das Auslesen von Latenzwerten, das Anlegen eines neuen Interconnects.

Der Unterschied zu einer klassischen REST- oder gRPC-API liegt weniger im Transportmechanismus als in der Semantik. Eine klassische API liefert Daten oder Zustände zurück; ein MCP-Server liefert dem Agenten zusätzlich Kontext darüber, was er mit diesen Daten tun darf – welche Tools verfügbar sind, welche Parameter sie erwarten, welche Nebenwirkungen eine Aktion hat. Das ist die Voraussetzung dafür, dass ein Agent nicht nur Informationen abruft, sondern eigenständig plant, welche Schritte zur Lösung eines Problems nötig sind.

Networking ist dabei ein besonders anspruchsvoller Anwendungsfall für einen generischen MCP-Ansatz. Drei Eigenschaften machen den Unterschied:

• Echtzeitanforderung. Netzwerkzustände ändern sich im Millisekundenbereich. Ein Kontext, der beim Laden fünf Sekunden alt ist, kann für eine Diagnoseentscheidung bereits wertlos sein.
• Hohe Fehlerkosten. Eine falsch konfigurierte Route oder ein versehentlich gekapptes Peering trifft nicht nur ein System, sondern potenziell alle nachgelagerten Dienste, die über diese Verbindung laufen.
• Verteilte Multicloud-Topologien. Ein Vorgang wie „stelle eine Cloud-zu-Cloud-Verbindung her" berührt in der Regel mehrere Domänen gleichzeitig – das eigene Backbone, mindestens einen Cloud-Provider, häufig zusätzlich einen Kundenstandort.

Ein MCP-Server, der „speziell für Networking gebaut" ist, unterscheidet sich von einem generischen Wrapper genau in diesen drei Punkten: Er bildet die Domänenlogik ab (was ist ein gültiger Konnektivitätszustand, was eine zulässige Änderung), er kennt die Nebenwirkungen typischer Netzwerkoperationen, und er liefert dem Agenten die Fachterminologie, mit der Netzwerktechniker tatsächlich arbeiten – nicht nur rohe API-Endpunkte.

Die vier Bausteine von Agentic Networking

Zayo beschreibt Agentic Networking als Zusammenspiel von vier Komponenten, die erst gemeinsam den Sprung von Self-Service-NaaS (Network-as-a-Service) zu agentengesteuertem NaaS ermöglichen:

1. Die physische Zayo-Netzinfrastruktur – das globale Glasfaserbackbone samt Interconnect-Standorten bildet die Basis, auf der überhaupt etwas geschaltet werden kann.
2. Die DynamicLink-Plattform als Software-Layer, der On-Demand-Konnektivität bereits vor Agentic Networking programmierbar gemacht hatte – Verbindungen lassen sich per API oder Self-Service-Portal buchen, ändern und beenden.
3. Eine dedizierte Networking-„Skill", die dem Agenten domänenspezifisches Fachwissen zur Verfügung stellt – im Kern eine Wissensbasis über DynamicLink-Funktionen, Netzwerkkonzepte und typische Betriebsabläufe, die der Agent per Retrieval abrufen kann, statt aus generischem Trainingswissen zu raten.
4. Der MCP-Server als Vermittler zwischen Agent und System: Er liefert den strukturierten Kontext (aktuelle Topologie, Performance-Daten, offene Tickets) und stellt die ausführbaren Aktionen als Tools bereit, über die der Agent tatsächlich etwas verändern kann.

Der entscheidende Architekturgedanke ist die Trennung von Wissen und Handlung. Die Networking-Skill sorgt dafür, dass der Agent versteht, was ein sinnvoller nächster Schritt wäre; der MCP-Server sorgt dafür, dass er diesen Schritt kontrolliert ausführen kann. Ohne die Skill würde der Agent zwar Tools aufrufen können, aber fachlich unpassende Entscheidungen treffen. Ohne den MCP-Server bliebe alles Wissen folgenlos – der Agent könnte beraten, aber nicht handeln.

Dimension	Klassisches Self-Service-NaaS	Agentic Networking
Auslöser einer Aktion	Mensch erkennt Bedarf, bestellt manuell im Portal	Agent erkennt Bedarf oder Anomalie, initiiert Aktion selbst
Rolle des Menschen	Ausführender bei jeder Einzelaktion	Definiert Ziele, Grenzen und Freigabepunkte vorab
Reaktionsgeschwindigkeit	Abhängig von Verfügbarkeit und Aufmerksamkeit des Teams	Kontinuierlich, auch außerhalb der Geschäftszeiten
Nachvollziehbarkeit	Ticket- und Portalhistorie pro Person	Muss über Audit-Log jeder Agentenaktion abgebildet werden

Vier konkrete Einsatzszenarien im Detail

Zayo benennt vier Anwendungsfälle, für die Agentic Networking in der Praxis eingesetzt wird. Alle vier haben gemeinsam, dass sie klassischerweise manuelles Eingreifen mehrerer Fachrollen erfordert hätten – Netzwerktechnik, Cloud-Team, gegebenenfalls Applikationsverantwortliche.

1. Automatisiertes Herstellen von Cloud-zu-Cloud-Konnektivität

Statt dass ein Techniker eine Anfrage über das DynamicLink-Portal stellt oder ein Ticket eröffnet, formuliert ein Fachanwender oder ein übergeordneter Orchestrierungs-Agent das Ziel in natürlicher Sprache – etwa: „Richte eine dedizierte Verbindung zwischen unserem AWS-Workload und der Azure-Instanz für das neue Analytics-Projekt ein." Der Netzwerk-Agent übersetzt das in die notwendigen DynamicLink-Aktionen, prüft Kapazität und Kompatibilität der Endpunkte und stellt die Verbindung her, sofern sie innerhalb der freigegebenen Policy-Grenzen liegt.

2. Untersuchung von Performance-Problemen über mehrere Ebenen

Eine Applikation ist langsam – aber liegt es am Netzwerk, an der Cloud-Instanz oder an der Anwendung selbst? Genau diese Ebenen-übergreifende Diagnose ist traditionell aufwendig, weil sie unterschiedliche Monitoring-Systeme und Zuständigkeiten zusammenführt. Der Agent kann Netzwerktelemetrie, Cloud-Metriken und – wo angebunden – Applikationskennzahlen korrelieren und eine Ursachenhypothese liefern, statt dass drei Teams nacheinander ihre jeweilige Ebene ausschließen müssen.

3. Koordination von Multicloud-Verbindungen

Unternehmen, die Workloads über mehrere Cloud-Anbieter verteilen, müssen Konnektivität, Routing und Failover-Pfade zwischen diesen Umgebungen konsistent halten. Der Agent übernimmt hier eine koordinierende Funktion: Er hält den Sollzustand der Multicloud-Topologie im Blick und passt Verbindungen an, wenn sich Anforderungen ändern – etwa wenn ein Workload in eine andere Region verschoben wird.

4. Reaktion auf ungewöhnliche Netzwerkaktivität

Das sicherheitskritischste Szenario: Bei einer erkannten Anomalie – etwa einem ungewöhnlichen Verkehrsmuster, einem plötzlichen Latenzsprung oder einem Verbindungsabbruch – untersucht der Agent die Ursache und kann, sofern die Änderung vorab als zulässig definiert wurde, selbst Gegenmaßnahmen ausführen: etwa einen Failover auf einen redundanten Pfad oder das temporäre Sperren einer auffälligen Verbindung. Nicht vorab freigegebene Aktionen werden stattdessen zur menschlichen Entscheidung eskaliert.

Szenario	Traditionell zuständig	Agentenrolle
Cloud-zu-Cloud-Konnektivität	Netzwerktechnik + Cloud-Team	Führt Bestellung end-to-end aus
Performance-Diagnose	Mehrere Teams nacheinander	Korreliert Ebenen, liefert Ursachenhypothese
Multicloud-Koordination	Cloud-Architekten	Hält Sollzustand nach, passt an
Reaktion auf Anomalien	NOC-Bereitschaftsdienst	Untersucht, führt freigegebene Gegenmaßnahme aus

Granulare Policy-Governance als Kernversprechen

Zayo ist sich bewusst, dass produktiver Durchgriff auf Netzwerkinfrastruktur die sensibelste Kategorie von Agentenrechten überhaupt ist – sensibler als etwa Lesezugriff auf ein CRM. Entsprechend liegt der Schwerpunkt der Kommunikation nicht auf den Fähigkeiten des Agenten, sondern auf den Guardrails, die diese Fähigkeiten einhegen:

• Kundendefinierte Policy-Grenzen. Jeder Kunde legt selbst fest, welche Aktionen ein Agent in seiner Umgebung ausführen darf – von reiner Beobachtung bis zur autonomen Ausführung bestimmter Änderungsklassen.
• Granulare Sichtbarkeit von Informationen, Tools und Aktionen. Nicht jeder Agent sieht die gesamte Topologie oder hat Zugriff auf jedes Tool. Der Zuschnitt erfolgt pro Anwendungsfall.
• Human-in-the-Loop bei kritischen Änderungen. Für Aktionen mit hohem Risikopotenzial bleibt eine menschliche Freigabe vorgesehen, statt dass der Agent vollständig autonom entscheidet.
• Enterprise-Sicherheitsmodelle und Audit. Zugriffskontrolle, Protokollierung und Nachvollziehbarkeit jeder Agentenaktion sind laut Zayo integraler Bestandteil der Plattform, nicht nachträglich aufgesetzt.

Diese Struktur folgt einem Prinzip, das sich als Leitlinie für jede produktive Agenteneinführung eignet: Menschen definieren Ziele und Leitplanken, KI koordiniert und führt innerhalb dieser Leitplanken aus. Die Autonomie des Agenten ist damit kein Alles-oder-Nichts-Schalter, sondern ein Spektrum, das der Kunde pro Aktionstyp einstellt – von „nur vorschlagen" über „ausführen mit Freigabe" bis „autonom ausführen und melden".

Warum Sicherheitsexperten trotzdem warnen

Die Reaktionen aus der Sicherheits-Community sind trotz der beschriebenen Governance-Maßnahmen nicht durchweg euphorisch. Zwei Sorgen dominieren die Fachdiskussion, unter anderem dokumentiert bei SDxCentral:

Erstens: das Risiko versehentlicher Ausfälle. Ein Agent, der auf Basis einer fehlinterpretierten Anomalie einen Failover auslöst, der eigentlich nicht nötig gewesen wäre, kann selbst den Vorfall erzeugen, den er verhindern sollte. Anders als bei einem menschlichen Techniker gibt es bei einem Agenten kein intuitives „das fühlt sich falsch an" als letzte Bremse – er handelt exakt innerhalb der Logik, die ihm mitgegeben wurde, auch wenn diese Logik im konkreten Fall unpassend ist.

Zweitens: Prompt-Injection und Tool-Poisoning gegen MCP-Werkzeuge. Ein MCP-Server macht Aktionen als Tools verfügbar, die der Agent auf Basis von Kontext auswählt und parametrisiert. Wird dieser Kontext – etwa über manipulierte Log-Einträge, kompromittierte Metadaten oder präparierte Ticket-Texte – gezielt vergiftet, kann ein Angreifer den Agenten dazu bringen, ein legitimes Tool mit schädlichen Parametern aufzurufen, ohne dass eine klassische Zugriffskontrolle anschlägt. Diese Angriffsklasse ist für MCP-Integrationen generell dokumentiert, nicht spezifisch für Zayo – aber die Konsequenzen sind bei Netzwerkinfrastruktur besonders gravierend.

Netzwerkinfrastruktur ist als Ziel deshalb besonders sensibel, weil Fehler dort kaskadieren: Ein einzelner falsch konfigurierter Interconnect kann alle Dienste treffen, die über ihn laufen – oft ohne dass die betroffenen Teams den Zusammenhang sofort erkennen. Die Kritikalität ist damit strukturell höher als bei den meisten anderen Agenten-Anwendungsfällen, die derzeit in Unternehmen pilotiert werden.

Aus dieser Kritik folgt eine klare Handlungsanweisung: Herstellerzusagen zu Governance sind ein notwendiger, aber kein hinreichender Baustein. Wirksam wird das Modell erst durch technisches Sandboxing der Aktionsräume, Rate-Limits pro Agent und Zeiteinheit, automatisierte Rollback-Mechanismen für jede ausgeführte Änderung sowie regelmäßige externe Audits – nicht nur interne Kontrollen des Anbieters.

Einordnung: Ein Trend, der über Telekom-Anbieter hinausgeht

Zayo steht exemplarisch für eine Entwicklung, die sich 2026 branchenübergreifend beschleunigt: Agentische KI erhält reale Durchgriffsrechte auf produktive Infrastruktur – nicht mehr nur auf Netzwerke, sondern zunehmend auch auf Server, Speichersysteme und Cloud-Ressourcen. Parallel zu Agentic Networking etabliert sich unter dem Stichwort Agentic SRE ein vergleichbares Muster für den Server- und Applikationsbetrieb: Agenten überwachen, diagnostizieren und beheben Störungen selbstständig, innerhalb definierter Grenzen.

Für deutsche Unternehmen – insbesondere für regulierte Branchen wie KRITIS-Betreiber und den Finanzsektor – wirft dieser Trend eine Frage auf, die über die reine Governance-Frage hinausgeht: Wo laufen die Agentenentscheidung, der Kontext und die Protokolle physisch, und wer hat Zugriff darauf? Ein Agent, der produktive Änderungen an kritischer Infrastruktur vornimmt, verarbeitet dabei zwangsläufig sensible Betriebsdaten – Topologiepläne, Sicherheitskonfigurationen, im Zweifel auch Hinweise auf Schwachstellen. Läuft dieser Agent über einen cloudbasierten Dienst eines Anbieters außerhalb der EU, entsteht ein zusätzliches Abhängigkeits- und Kontrollrisiko, das über die klassische DSGVO-Betrachtung hinausgeht.

Für regulierte Branchen ist deshalb ein On-Premise- oder zumindest EU-hoheitlich betriebenes Pendant zu einem Agentic-Networking-Ansatz kein Nice-to-have, sondern eine Voraussetzung für die Freigabe durch Compliance und Aufsicht. Das gilt umso mehr, je näher der Agent an tatsächlicher Ausführungsmacht über kritische Systeme steht – Beratungsfunktionen sind unkritischer als Aktionsrechte.

Was Mittelständler aus Zayos Ansatz für eigene KI-Agenten-Projekte lernen können

Man muss kein globaler Netzbetreiber sein, um von diesem Governance-Modell zu profitieren. Die folgenden Prinzipien lassen sich unmittelbar auf eigene Agentenprojekte in der Unternehmens-IT übertragen, unabhängig davon, ob es um Netzwerk, Server oder Fachanwendungen geht:

• Geringstmögliche Rechte pro Agent. Jeder Agent erhält nur die Tools und Datenzugriffe, die für seine konkrete Aufgabe nötig sind – kein pauschaler Admin-Zugriff „für alle Fälle".
• Klar definierte Aktionsräume statt Vollzugriff. Statt einem Agenten Zugriff auf „das Netzwerk" oder „den Server" zu geben, wird jede erlaubte Aktion einzeln benannt und dokumentiert.
• Freigabeprozesse für kritische Änderungen. Ein Human-in-the-Loop-Schritt für alles, was potenziell kaskadierende Auswirkungen hat, ist keine Bremse, sondern die Voraussetzung für Vertrauen in das System.
• Lückenloses Monitoring und Logging aller Agentenaktionen. Jede Aktion, jeder Kontext, jede Entscheidung muss im Nachhinein rekonstruierbar sein – nicht nur, ob etwas passiert ist, sondern warum der Agent so entschieden hat.
• Schrittweise Einführung. Erst beobachten und Empfehlungen geben lassen, dann kontrolliert mit Freigabe ausführen lassen, erst danach – wenn überhaupt – vollständige Autonomie für eng umrissene, risikoarme Aktionsklassen zulassen.

Wer diesen Weg strukturiert gehen will, sollte das nicht allein der IT-Abteilung überlassen. Ein Workshop, der Geschäftsführung, IT-Sicherheit und Fachbereich zusammenbringt, um Aktionsräume und Freigabeprozesse gemeinsam festzulegen, spart in der Praxis mehr Zeit, als er kostet – weil er verhindert, dass ein Agentenprojekt nach der ersten Fehlaktion komplett gestoppt wird.

Fazit: Von der Assistenz zur echten Handlungsmacht – mit Leitplanken

Zayos Agentic Networking zeigt exemplarisch, wohin sich agentische KI in der Infrastruktur entwickelt: weg von der reinen Beratungsfunktion, hin zu echter, produktiver Handlungsmacht. Der erste produktive MCP-Server speziell für Networking ist dabei weniger eine technische Neuheit – MCP-Server für andere Domänen existieren bereits – als ein Signal, dass ein etablierter Infrastrukturanbieter bereit ist, Agenten Schreibzugriff auf sein Kernsystem zu geben.

Governance ist dabei kein Nice-to-have, sondern die eigentliche Innovation. Wer Agenten produktive Aktionsrechte gibt, ohne granulare Policy-Grenzen, Freigabeprozesse und Audit-Fähigkeit gleichzeitig mitzudenken, baut ein Risiko auf, das die gewonnene Geschwindigkeit schnell wieder auffrisst. Es ist absehbar, dass weitere Anbieter – bei Cloud-Infrastruktur, bei Server- und Applikationsbetrieb, perspektivisch auch bei Gebäudetechnik und Produktionsanlagen – ähnliche MCP-Integrationen für ihre jeweils kritischen Systeme bringen werden.

Für Unternehmen, die heute über den Einsatz agentischer KI in ihrer eigenen Infrastruktur entscheiden, sollte genau das der Maßstab bei der Anbieterauswahl sein: nicht die Frage, wie viel ein Agent kann, sondern wie präzise sich festlegen lässt, was er darf – und wie belastbar sich das im Ernstfall nachweisen lässt.

Quellen & Primärbelege

Alle Zahlen, Daten und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. Converge Digest: Zayo Brings MCP-Based AI Agents into Live Network Operations Existiert und ist inhaltlich passend – bestätigt MCP-Server, DynamicLink-Kombination und Use Cases.
2. Zayo Newsroom: Zayo Launches Agentic Networking Primärquelle (Hersteller-Pressemitteilung) – bestätigt alle vier Kernfakten inkl. Governance-Aussagen.
3. TelecomTV: Zayo Launches Agentic Networking, Bringing AI Agents Directly into Network Operations Unabhängige Fachpresse-Bestätigung der Ankündigung.
4. ComputerWeekly: Zayo advances network-as-a-service with agentic networking Liefert zusätzliche Details zu Use Cases und Governance-Modell.
5. SDxCentral: Zayo disrupts networking with AI agent service Deckt explizit die Sicherheitsexperten-Warnung vor „accidental outages" ab.

Häufig gestellte Fragen zu Zayo Agentic Networking

Was genau ist der neue MCP-Server von Zayo?

Zayo bezeichnet ihn als den ersten produktiven MCP-Server (Model Context Protocol), der speziell für Netzwerk-Operations entwickelt wurde. Er ist Teil der "Agentic Networking"-Erweiterung der DynamicLink-Plattform und wurde am 8. September 2026, genau ein Jahr nach dem DynamicLink-Start, allgemein verfügbar gemacht. Der Server stellt autorisierten KI-Agenten Netzwerkkontext (z. B. Topologie, Performance-Daten) sowie ausführbare Aktionen als Tools bereit.

Welche Aufgaben können KI-Agenten mit Zayo Agentic Networking konkret übernehmen?

Laut Zayo und unabhängiger Fachpresse (u. a. ComputerWeekly, TelecomTV) gehören dazu: das Herstellen von Cloud-zu-Cloud-Konnektivität, die Untersuchung von Performance-Problemen über Netzwerk-, Cloud- und Applikationsebenen hinweg, die Koordination von Multicloud-Verbindungen sowie die Reaktion auf ungewöhnliche Netzwerkaktivitäten (Anomalien) bis hin zur Ausführung freigegebener Änderungen.

Wie verhindert Zayo, dass ein KI-Agent versehentlich einen Netzwerkausfall verursacht?

Zayo betont, dass Automatisierung, Governance und menschliche Aufsicht durchgängig erhalten bleiben. Unternehmen definieren selbst, welche Informationen, Tools und Aktionen für Agenten zugänglich sind, und die Agenten operieren innerhalb strikter, kundendefinierter Policy-Grenzen. Diese granulare Steuerung ist eine direkte Antwort auf Warnungen von Sicherheitsexperten vor "accidental outages" durch fehlerhaftes Agentenverhalten.

Ist ein MCP-Server für kritische Infrastruktur wie das Firmennetzwerk überhaupt sicher genug?

Das hängt maßgeblich vom Deployment-Modell und der Governance ab – MCP selbst definiert nur das Protokoll, nicht automatisch Sicherheit. Gerade bei sicherheitskritischen Aktionen wie Netzwerkänderungen empfiehlt sich ein On-Premise- oder zumindest streng policy-gebundenes Setup mit Human-in-the-Loop-Freigaben, granularen Guardrails und lückenlosem Audit-Log, statt Agenten ungeprüft produktive Änderungen ausführen zu lassen.