MCP Connects the Agent. What Governs the Change?

The Question Changed

For two days in early October, the people building and operating the Model Context Protocol gathered in Toronto for MCP Dev Summit, hosted by the Agentic AI Foundation (AAIF) under the Linux Foundation. The organizers framed the event around enterprise and regulated environments, which meant the agenda was less about hello-world demos and more about the unglamorous work of production: identity, authorization, auditability, gateways, registries, evaluation and reliability.

What the Keynotes Said & What It Means for Infrastructure

Anthropic: MCP Is the Agentic Substrate

Den Delimarsky, MCP lead maintainer at Anthropic, opened day one with a history lesson. Before MCP, every AI integration was custom work and the ecosystem was a patchwork. Since its late-2024 release, the protocol has become the default way agents reach the outside world, backed by mature SDKs that spare teams from rebuilding integrations for each model provider.

The roadmap he published with fellow lead maintainer David Soria Parra in August sets the next agenda: agent identity and enterprise-ready security built on existing standards such as proof-of-possession tokens, workload identity federation and token exchange; progressive discovery, so clients learn tools as they need them rather than swallowing an entire catalog; a single HTTP-native transport following the stateless 2026-07-28 specification; and messaging primitives for long-running agentic work.

A substrate is not a control plane. As MCP becomes the common way agents reach tools, the enterprise question becomes what sits between the agent and the infrastructure it acts on.

The protocol’s roadmap and those capabilities address related production concerns. Transport, identity, and discovery make tools accessible. The execution layer still has to decide what an agent is allowed to do with them.

TELUS: One Year of MCP in the Enterprise

Kevin Ng and Dana Harrison of TELUS, the Canadian telecommunications provider, showed what a complete enterprise MCP practice looks like after a full year in production. Their walkthrough covered an operations agent called IRIS that handles real operational requests from Slack and is itself exposed as an MCP server; automation workflows that call MCP tools to take routine platform chores off engineers’ plates; an internal registry where teams find existing connectors before building duplicates; and remote hosting on their Cloudflare Workers-based platform.

They also took on enterprise OAuth directly, explaining why they chose Client ID Metadata Documents over Dynamic Client Registration.

The useful lesson for infrastructure teams is how those pieces work together. Workflows consume tools, agents are reachable through the same protocol, and a shared catalog gives teams somewhere to look before building another connector.

Those relationships also exist in Itential FlowAI. Tools registered through the FlowMCP Gateway surface as native gateway services that Studio workflows and FlowAgents can invoke alongside Ansible or Python. In the other direction, the Itential MCP Server lets an external MCP client trigger FlowAgents and follow their sessions. Gateway Manager provides the catalog where a NetBox or pyATS connector can be registered once and reused.

For a network operator, that reuse has to fit the existing permission model. RBAC, approvals, and audit belong in the path through which the shared tool is used.

NVIDIA: Running MCP for Real

Chris Alexiuk explained that MCP sits at the center of NVIDIA’s AI-Q and its wider agent tooling, then shared what has survived contact with production: controlling which tools an agent can see, authorizing calls, supporting many users on shared deployments, enforcing guardrails, and adapting as the specification changes underneath you. He also gave the operating model a name: MaaS, or MCP as a Service, where MCP servers are run as shared, centrally managed infrastructure and their tools are offered to agents on demand, rather than every team standing up and wiring its own.

Shared infrastructure makes the tool-selection question unavoidable. A catalog can serve many teams, but each agent still needs a deliberate set of tools for its job.

The Itential MCP Server uses tag-based tool selection, with documented profiles for platform administrators, network engineers, automation developers, and operators. Inside the platform, a FlowAgent can call only the tools its builder attached at build time. Multi-user identity comes from the platform’s AAA integration. The guardrails live in deterministic workflows.

MaaS also describes the service model behind the FlowMCP Gateway. Teams bring the MCP servers they already run, such as NetBox, pyATS, or an ITSM system, and register them through the gateway. Their tools become native gateway services that agents and workflows can use through the shared catalog, subject to tool selection and permissions.

That is how the shared-service idea connects to infrastructure operations: teams reuse capabilities while the gateway remains responsible for their governed execution. The server-registration and credential details matter, and I will come back to those below.

Accenture: Governing MCP for a Workforce the Size of a City

Michael Forrester of Accenture LearnVantage told a story every enterprise will recognize. It began with a demo that worked perfectly: a single agent calling a single tool over MCP in about a minute. Then came the question of how many people would need access, and the honest answer was possibly everyone, perhaps 750,000. Nobody had formally approved any of it, and as he put it, “There was also nowhere to say no.”

The architecture that followed had a few load-bearing pieces: a registry that serves as the authoritative list of approved servers, their owners and what agents are allowed to find; a gateway that every agent-to-tool call must traverse, so identity checks, authorization, throttling and policy live in one place instead of inside each server; a GitOps-managed control plane with admission checks that stop unapproved servers from being deployed; runtime monitoring of tool execution; and workload identity that tells the gateway which agent is making each call.

That foundation carried a rollout toward 200,000 internal users at one company.

Forrester’s story made the governance question concrete. A working demo becomes an organizational problem when there is no place to approve a server, deny access, or enforce that decision before a tool runs.

That is the role the FlowMCP Gateway plays in Itential. Registering an MCP server requires operator-level access in Itential Gateway. Credentials live in the gateway’s secrets manager and are never returned in plaintext. Discovered tools become native gateway services that inherit the Gateway Manager permission model, and a FlowAgent can invoke only the tools explicitly attached to it.

That is a place to say no, built into the execution path. It connects the operational problem described on stage to the controls infrastructure teams need before adopting another server or agent.

OpenAI: The Client Is No Longer One App

On the breakout stage, Martin Au-yeung brought lessons from building plugin submissions at OpenAI, showing how MCP extensions can deliver interactive interfaces inside ChatGPT and Codex that keep users coming back. It was another sign of how thoroughly MCP has become shared ground across the industry: OpenAI engineers now sit among the protocol’s core maintainers, including on its transport work.

A shared protocol also changes where the user can start. Claude, ChatGPT, Codex, Claude Code, and custom harnesses can provide different front ends to the same platform capabilities. The controls governing those capabilities need to hold regardless of the client.

The Itential MCP Server exposes the platform to MCP clients and ships example prompts for both Claude and GPT. Inside FlowAI, the Model Registry lets LLM admins bring their own model provider, enable specific models, and decide which builder groups may use them.

Reasoning is pluggable. Governed execution is not.

The Breakouts Drew the Same Map

The keynote discussions carried into the breakouts. Guardrails, tool selection, and execution reliability kept surfacing, with more detail about where production systems succeed and where they fail.

Guardrails Belong Below the Model

Hillary Curran presented a Linux Foundation Research and AAIF study built on interviews with 22 leaders running agentic systems, many in regulated industries. Nearly all of them use MCP, even if they disagree about where it goes next. Two patterns came up again and again: a gateway between agents and models for governance and cost control, and guardrails enforced beneath the model instead of through prompts, because the model is exactly what an attacker is trying to manipulate and cannot be its own safeguard.

Determinism Under Reasoning

Dilawar Javaid built an incident-response agent spanning observability, Kubernetes and GitHub MCP servers to show that the protocol handles discovery and invocation but leaves planning, retries and recovery to someone else. His answer was a lightweight orchestration layer with deterministic checkpoints, idempotent steps and explicit retry rules, rather than one free-running agent loop. Nidhi Singh’s account of more than 20,000 production tool invocations included a sobering example: one faulty validation pattern quietly wiped inventory counts for more than 70 sellers.

This is the same constraint behind the NetClaw work I presented. Networks are the final frontier for AI in operations: stateful, high-consequence, and intolerant of hallucinated changes. Structured skills constrain an agent far better than a pile of raw device access, and spec-driven development keeps an autonomous loop predictable.

This is the heart of FlowAI. Agents reason; workflows execute.

When a FlowAgent decides what should happen, the change itself is carried out by a deterministic workflow that runs the same way every time, with pre-checks, post-checks, rollback, and a complete audit trail.

Teams decide how much human oversight each action needs, from approving every step to supervising by exception.

First to MCP in Network Infrastructure & Still Maturing It in the Open

The operational questions in Toronto also explain the progression of our MCP stack. Itential published the first release of its open-source MCP server, itential-mcp, on May 1, 2025, and launched it publicly on May 28, 2025, at the Network Automation Forum’s AutoCon 3 in Prague, making Itential the first in the network infrastructure space to ship an MCP server.

Being first only matters if you keep going. The server has shipped continuously since launch, tracking the protocol as it evolved, and it now sits alongside FlowAI and the FlowMCP Gateway as one part of a complete MCP architecture.

Itential MCP Maturity Timeline

How FlowAI Agents Access MCP

The practical answer to the summit’s questions is an architecture that connects agents to tools while preserving a governed execution path. Itential’s MCP architecture runs in two directions, and the distinction matters.

Two directions of MCP, one governed execution path. External AI reaches in through the Itential MCP Server; FlowAgents and workflows reach out to your MCP servers through the FlowMCP Gateway. Both pass through the same RBAC, AAA, and audit.

The Itential MCP Server exposes platform capabilities, including workflows, device management, compliance, gateway services, and FlowAgents, to external AI assistants such as Claude, ChatGPT, and Claude Code. The FlowMCP Gateway connects external MCP servers to the platform so FlowAgents and workflows can use their tools natively.

The two compose cleanly: Claude can trigger an Itential workflow through the MCP Server, and that workflow can call a tool registered through the FlowMCP Gateway, with every hop governed.

Inside the platform, a FlowAgent lives in an Agent Project and has four parts:

• A prompt.
• Input variables.
• An LLM drawn from the Model Registry.
• The specific set of tools it is allowed to call.

The catalog those tools come from is broad: Studio workflows, adapter and integration APIs, gateway services written in Python, Ansible, or OpenTofu, Lifecycle Manager actions, compliance plans, other agents, and tools discovered through the FlowMCP Gateway. Whatever the agent calls, Gateway Manager and Itential Gateway execute it at runtime, on the same path that already runs Itential automation.

Execution is hybrid by design. Agents can call workflows; workflows can hand a single decision to an agent through the Run Agent task and resume with its output; agents can call other agents. Teams can adopt AI one decision at a time, without replacing the automation that already works.

BYOMCP: Bring Your Own MCP Server to the Gateway

Most organizations already run MCP servers they care about, whether that is NetBox as the source of truth, pyATS for live device state, an AIOps platform, an ITSM system or an in-house data service. The FlowMCP Gateway, an extension of Itential Gateway 5.5 and later running with Platform 6.5 and later, brings those servers under Itential governance without a custom integration for each one.

Registration is deliberately simple. An operator supplies the server’s details, and Itential Gateway connects to it, discovers the tools it exposes and publishes them in Gateway Manager as native gateway services. The gateway supports multiple MCP transports and detects the right one automatically when none is specified. Credentials are referenced from the gateway’s secret store rather than typed in plain text. MCP server definitions travel with gateway database exports and resolve secrets by alias in the target environment, so promoting from lab to production does not expose credentials.

When a server adds tools, rediscovery picks them up; when a server is removed, all of its tools are withdrawn at once.

MCP-backed services behave like every other gateway service: they inherit the same permission model, appear in the same catalog, report errors in the same formats, and land in the same audit trail.

That continuity is what connects the registry-and-gateway pattern Accenture described to day-to-day infrastructure operations. Bringing in another MCP server extends the catalog without creating a separate permission model or execution path for its tools.

RBAC & AAA, All the Way Down

If one idea echoed through Toronto, it was to enforce identity and policy once, at the gateway, rather than re-implementing them in every server. Itential layers authentication, authorization and accounting across every surface a human or an agent can touch, with fine-grained permissions at each layer.

Where Governance Lives in the Itential MCP & FlowAI Stack