Zayo Put Network Operations Behind an MCP Server: What Governed Agent Access to the Underlay Means for Deploy-from-Chat

On September 8, 2026, a fiber company did what no platform company had: Zayo launched Agentic Networking for its DynamicLink network-as-a-service platform, built around what it calls the industry's first production MCP server designed specifically for networking. Approved enterprise AI agents can now read network conditions, call network tools, and take authorized action on the underlay — through the same Model Context Protocol their deploy tools already speak.

The press release is dated September 8, with trade coverage landing September 9. Either way, the network layer now has an agent API — and a governance model attached to it.

Why should a team running apps on a self-hosted PaaS care what a backbone provider ships? Because deploy-from-chat has had a blind spot since day one: your agent can redeploy the app, tail the logs, and even run read-only SQL — but it has been completely blind to the path traffic takes to reach those pods. Zayo just showed what closing that gap looks like, and more importantly, what governing it looks like. This post inventories what shipped, works through what an underlay-aware deploy agent can do, and draws the governance boundary your own agent tools should copy.

What Zayo actually shipped​

DynamicLink launched in September 2025 as Zayo's self-service take on software-defined networking, and it has now spent a full year in production — long enough to win a 2026 CRN Tech Innovator Award for enterprise networking. Agentic Networking moves it from self-service control to agent-executable action. The capability has four named components:

Three workflows define the launch, and their ordering is deliberate — each one grants the agent more agency than the last:

1. Respond to unusual network activity. The agent surfaces relevant network context, identifies potential issues, and recommends actions for an engineer to review. Read-heavy, human-decided.
2. Execute approved network changes. The agent invokes authorized DynamicLink tools to carry out network or security actions — but only within enterprise-defined controls. Write-capable, policy-bounded.
3. Extend networking into enterprise AI workflows. Organizations build network operations into their own approved agents and workflows beyond the DynamicLink portal. The MCP server is the integration point, not the portal UI.

The governance sentence in the announcement does the most work: organizations define the information, tools, and actions available to agents, with automation, governance, and human oversight remaining in place. As Zayo enterprise CRO Chris Ranalli put it, instead of simply asking AI questions about the network, enterprises can put AI to work on it. The capability is available immediately, aimed first at data-intensive sectors — retail, financial services, healthcare, and media and entertainment.

Note what Zayo did not do: hand agents raw NOC credentials or an unscoped API token. The MCP server is the narrow, governed waist between the agent and the network. That design choice is the part worth stealing.

Why the network was the missing MCP layer​

By mid-2026 the MCP ecosystem had crossed 10,000 public servers, with the protocol under vendor-neutral governance at the Linux Foundation's Agentic AI Foundation since December 2025. The app layer got its agent interfaces first: Heroku ships an official MCP server covering app lifecycle, Postgres, and add-ons, and Render's official MCP server exposes around 25 tools — including a hardened trigger_deploy and one-click OAuth for Claude Code, Codex, and Cursor. Render even published a Heroku-to-Render migration skill that composes both servers, letting one agent read the source platform and write to the target.

So before this month, an agent holding two MCP connections could already migrate your app between clouds from a chat window. What it could not do was answer — let alone act on — anything below the app: Is this latency spike a bad deploy or a degraded path? Is there enough headroom on this link for the traffic the new release will add?

That context lived in NOC dashboards, carrier portals, and tickets. Every deploy agent operated on the implicit assumption that the network is someone else's problem.

Zayo's move breaks that assumption in the most boring, most important way: the underlay now speaks the same tool protocol as the platform. No custom integration, no screen-scraping a carrier portal, no ticket queue between "the agent noticed" and "the network changed." For a self-hosted PaaS roadmap, the precedent matters more than the vendor: if a regulated, uptime-sensitive carrier trusts governed MCP tools for network mutation, the "agents can't touch infrastructure" line has officially moved from principle to configuration.

The deploy agent that sees the whole path​

Make it concrete. Today, a deploy-from-chat loop on a self-hosted fleet looks like this: the agent pushes code, watches the rollout, tails logs on failure, and either rolls back or escalates. Every diagnosis it can perform ends at the cluster boundary.

"The deploy is green but p99 doubled" is where the agent shrugs and pages a human — because the next three questions are all network questions it cannot ask.

Give that same agent a governed network tool surface and the loop extends:

• Pre-promotion path check. Before promoting a canary, the agent reads current path health and capacity on the routes serving the affected region — the same way it already checks pod readiness. A degraded path becomes a reason to hold the rollout, automatically.
• Correlated incident triage. When error rates spike minutes after a deploy, the agent can distinguish "our new code is slow" from "the underlay changed under us" in one reasoning pass instead of two teams and a war room. The first Zayo workflow — surface context, recommend action, engineer reviews — is exactly this shape.
• Bandwidth and policy changes in the same loop. A launch that needs more headroom, or a security event that needs a policy change, stops being a ticket filed after the deploy conversation and becomes a governed tool call inside it — subject to the same approvals as any other write.

None of this requires the agent to be cleverer. It requires the network to be addressable — readable state, named tools, explicit authorization — which is precisely what an MCP server provides. The deploy agent graduates from "operates the app" to "operates the service," where the service includes the path users actually traverse.

There is a fair objection: most self-hosted PaaS teams don't buy backbone capacity from Zayo; their "underlay" is a Hetzner vSwitch, a Cloudflare tunnel, or a Tailscale mesh. True — but the pattern transfers downward intact. Whatever your network layer is, the question is whether your agent reaches it through governed tools or through nothing at all. Today, for most teams, the answer is nothing at all.

One agent, two blast radii: where the governance boundary sits​

Here is the uncomfortable part. The moment one agent holds both "restart the service" and "reprogram the network," a confused or compromised agent can do damage at two layers simultaneously — and network misconfigurations propagate faster and recover slower than a bad deploy.

Zayo's enterprise-controls framing is the right instinct; here is what it concretely requires, whether the MCP server fronts a carrier backbone or your own fleet:

1. Separate read tools from write tools, and gate them independently. Path health, capacity, and config reads should be broadly available — an agent that can't see can't reason. Every mutation (reroute, reprovision, policy change) goes through an allow-list the enterprise defines, not the union of whatever the API key can reach. MCP's own direction supports this: native OAuth scopes arrived via SEP-835, and the July 2026 spec revision binds tokens to their resource with RFC 8707 indicators, so least-privilege stops being a policy document and starts being enforceable at the protocol layer.
2. Keep a human in the loop for irreversible changes. Zayo's first workflow recommends while the engineer decides; only the second executes, and only within pre-approved controls. Copy that ladder: agent proposes network mutations by default, executes only the pre-authorized class, and everything irreversible waits for a click. Render's MCP server models the same honesty at the app layer — plan and region changes return a dashboard link instead of pretending the agent can do them.
3. Scope every mutation to an explicit tenant or workspace. Ambient session state that a reconnect can silently shift is how agents act on the wrong account. Render deprecated session-based workspace selection in favor of a per-call workspaceId for exactly this reason. A network tool that can reprogram routes must carry its scope in the call, not inherit it from a connection.
4. Annotate destructiveness truthfully and audit everything. MCP tool annotations exist so clients can demand confirmation before destructive calls while letting reads run free. Pair that with a tamper-evident audit trail of every agent-invoked mutation — who authorized it, what changed, and how to reverse it. If you can't answer those three questions per call, the tool isn't governed; it's just available.
5. Treat the agent's tool set as a supply chain. Pin which tools the agent is offered, review additions like dependency upgrades, and never expose a broader surface "temporarily" for debugging. The governance boundary isn't the firewall — it's the tool list.

The throughline: Zayo didn't make the network open to agents; it made the network legible and actionable to agents within boundaries the enterprise draws. Any self-hosted platform exposing agent tools — deploy triggers, restart buttons, DNS edits — needs the same posture before it adds its first network-layer tool.

What a self-hosted PaaS should take from this​

Three takeaways for anyone operating a platform agents will drive:

• Expose platform state as governed MCP tools, the way Zayo did for the network. Reads generous, writes allow-listed, destructive actions annotated and human-gated. If your deploy agent still shells out to kubectl with a cluster-admin kubeconfig, you are where networking was before this month.
• Put network-layer tools behind the same boundary before you need them. You may never buy backbone from a carrier, but your load balancer config, your tunnel routes, and your DNS are all "the network" from the agent's perspective. Design the approval and audit path once, then extend it downward.
• Track the protocol, not just the vendors. Scoped tokens, resource indicators, and tool annotations are what make "governed" a technical property instead of a marketing word. The July 2026 MCP spec gives you the primitives; use them.

The arc is clear: first the app layer got an agent protocol, and now the underlay has one. The next deploy-from-chat incident review that ends with "the agent couldn't see the network" will read like an excuse — the tooling to fix it shipped this month, with a governance model attached.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators there too: star the repo on GitHub or deploy your first app today.