What is MCP governance?

By Nolan Sullivan, Founding Growth Engineer

·Published September 24, 2026

Agents connected to the tools a company uses are infinitely more useful than agents without any access. Consequently, MCP sprawl and shadow MCP are becoming problems at every company with serious AI use. Adoption has been outpacing governance. And yet, as AI use has grown, and agents have become increasingly independent, it’s become clear that the MCP servers agents use need to be managed the same way as any software product the company licenses.

IT and security teams are now catching up and putting together comprehensive MCP governance programs that treat each server as an asset with a lifecycle. Every server, sanctioned or not, gets an owner, a recorded approval decision, distribution to the users (agents) that need it, a log of what it is doing, and a point at which it is re-reviewed or retired. Collectively, the managed servers form the company’s MCP inventory.

What happens at each stage of the MCP server lifecycle?

Each stage has an output, an owner, and a common way it fails. The stages below are listed in the order a new server moves through them.

Discover: find the servers agents already use

Discovery compares the servers agents are observed in production against the servers the organization has approved, and surfaces the gaps between the two. Non-approved servers are considered shadow MCP, and the team that maintains the inventory needs to evaluate each server on an individual basis.

One of the challenges of discovery is that, by definition, these servers fall outside the approved path. That can make detection difficult. Some companies rely on network telemetry to catch remote MCP traffic. A better option is agent-side hooks that check which MCP tools are being used within every agent session.

Whatever the mechanism, the activity needs to be added to an immutable record in the MCP inventory for every server, sanctioned or not, with its URL or package, transport, credential type, users, and last-seen time. A common point of failure is treating discovery as a one-time scan, rather than ongoing monitoring.

Review and approve: assign an owner and record a decision

Every discovered server needs someone to answer three questions: who operates it, how it is authenticated (OAuth scopes, secrets, headers), and what capabilities it enables, especially the ones that write or delete. The reviewer records a decision and its scope. An approval might cover one requester, one team, or the whole organization.

The review should sit on the server’s inventory record, with the evidence and rationale attached, so the next reviewer can see why a server was approved or denied. The common failure is review in chat threads or tickets that nobody can find six months later, which forces the same server through review twice.

Promote: move approved servers into the official registry

Promotion turns an approved server into a supported one. The server gets an entry in the organization’s approved MCP registry, its authentication is configured once (OAuth on the user’s own identity, or a managed credential stored centrally), and its tool list is curated so that destructive tools can be excluded or granted separately. If the server should only be reachable from inside the company network, this is where that exposure is set, as described in private MCP gateway.

Promotion is also how shadow MCP gets resolved without friction. If discovery shows that dozens of engineers have each wired up the same vendor server with their own personal access token, promoting that server replaces every one of those unmanaged credentials with one governed entry. The common failure is an approved registry that lags behind demand, which sends people back to wiring servers up themselves.

Distribute: provision servers by role

Distribution decides who receives each promoted server and delivers it without a manual step per person. Roles map from identity provider groups to servers and tools, and a new hire in the right group gets the right servers on day one. Delivery happens through the gateway or a managed client configuration, rather than someone sending an mcp.json snippet in a message.

Role-based distribution depends on the identity provider’s groups being accurate. If the groups do not reflect who does what, the distribution inherits the error, so the first role mapping usually turns into a review of the groups. The common failure is admins provisioning servers one request at a time, which platform teams we talk to name as their most acute problem with MCP today.

Monitor: audit every tool call

Monitoring records every tool call with the user, the agent or client, the server, the tool, the decision the gateway made, and the time. That audit log answers the security team’s questions after an incident, and it also answers the governance questions: which servers are used, by whom, and how often.

Monitoring also feeds the loop. A server nobody has called in months is a retirement candidate. A new server appearing in client telemetry is a discovery finding. A spike in denied calls to one server is a request for access that nobody has filed yet.

Update or retire: re-review what changes, remove what is unused

MCP servers change after approval. A vendor adds tools, requests broader OAuth scopes, or publishes an advisory. Re-review compares what a server asks for now with what it asked for when it was approved, and flags the difference for a new decision. Checking published evidence has a limit, because a server can change its behavior without changing its interface, so re-review narrows the risk rather than removing it.

Retirement removes a server when it goes unused for the review period, loses its owner, is replaced, or fails re-review. Retiring a server means revoking its credential and removing it from every role. Deleting the registry entry alone leaves the credential live and the connection easy to restore.

What makes MCP governance a closed loop?

A closed loop means the output of each stage is the input to another, with no step that depends on someone remembering to do it. In practice, three connections close it:

• Blocked calls become review requests. When an agent calls an unapproved server and the call is blocked, the user gets a way to request access from the same place, and the request lands on the server’s inventory record for review.
• Approvals become distribution. A server approved for a team is provisioned to that team’s role without a separate ticket to the platform team.
• Usage becomes retirement and rediscovery. The audit log sets each server’s last-used date, and client telemetry keeps surfacing servers that are not in the registry.

The measure of the loop is the time between someone wanting a server and having it, provisioned by role and working. Platform teams we talk to name the same gap repeatedly: no inventory, no approval process, and no golden path, so every new server is a manual request. A loop that turns that request around quickly removes most of the reason to wire servers up outside the approved path. A loop that takes weeks produces shadow MCP.

Why do most MCP gateways skip discovery?

Most MCP gateways start at the approved registry. An administrator adds servers, the gateway enforces who can reach them, and the gateway logs what passes through it. That design assumes the organization already knows which servers exist, which is the assumption discovery exists to test.

A gateway only sees its own traffic, so it cannot see a server that bypasses it. Discovery needs a sensor where agents run (hooks inside the coding agent, a device agent pushed through mobile device management, or a scan of client configuration files) or on the network. Few gateways ship that sensor as part of the same product, and the ones that do differ in which clients they cover.

For MCP governance, this means checking whether a gateway covers the first stage, and if it does not, deciding what will. A registry and gateway without discovery govern the servers that were going to be well-behaved anyway.

Who owns MCP governance?

Ownership splits across three groups, and the split works best when it is written down:

The program owner needs to be the platform or IT team, because the loop is mostly a provisioning and inventory problem. Security teams set the review criteria and make the calls on servers with write access to sensitive systems. When security owns the whole program, the loop tends to optimize for denial, and the turnaround time that keeps shadow MCP down stops being anyone’s metric.

How do you start an MCP governance program?

Start in the order of the lifecycle, and turn on enforcement last:

1. Run discovery in observe-only mode. Record every server agents call without blocking anything, long enough to see the servers teams use weekly as well as daily.
2. Triage by exposure. Sort the inventory by number of users and by whether the server can write, and review from the top.
3. Promote the most-used servers first. Replacing the servers most people already use removes the most unmanaged credentials per review.
4. Map roles from the identity provider. Start with a few broad roles and narrow them as usage data comes in.
5. Turn on blocking with a request path. Block unapproved servers only once a blocked user can request access from the block itself.
6. Set a re-review and retirement schedule. Decide the idle period after which a server is reviewed for retirement, and who reviews it.

Which tools support MCP governance?

The tools below are listed by how much of the lifecycle they cover. Each entry describes only what the vendor documents.

Speakeasy

The Speakeasy AI Control Plane runs the full MCP governance loop on one MCP gateway:

• Discover. Shadow MCP detection classifies every MCP tool call in an instrumented agent session and flags calls to servers outside the platform, including third-party URLs and local stdio servers. Findings land in a shadow MCP inventory with last-called and last-seen times, and a flagging policy builds that inventory before any blocking starts.
• Review and approve. Each discovered server has an access review with automatically gathered evidence on its publisher, requested scopes, and tools. A blocked user gets a request link, and a reviewer approves or denies with a scope of one person, a team, or a project, with the rationale recorded.
• Promote. Servers enter the gateway by generation from an OpenAPI document, by adding a vendor server by URL, or by importing from a catalog powered by the official MCP Registry, with authentication and tool curation configured per server.
• Distribute. Roles and permissions grant access down to individual servers and tools, and roles can be assigned from the identity provider through directory sync. Plugins bundle servers and skills and assign them to roles.
• Monitor. Tool logs record every call on the gateway, including shadow MCP calls.
• Update or retire. A daily check re-gathers evidence for approved servers and flags changes in OAuth scopes, credentials, or advisories for a new decision.

Two limits apply. Discovery depends on agent sessions being instrumented, so a client without the device agent or hooks produces no findings. Plugin role assignments gate delivery only through the device agent today, so a plugin installed from a client’s marketplace is available to anyone with access to that marketplace.

Open-source gateways

Microsoft MCP Gateway is an open-source reverse proxy and management layer for MCP servers running on Kubernetes, with Azure identity and monitoring integrations. IBM ContextForge is an open-source gateway and registry that federates MCP servers and REST services behind one endpoint. Both start from servers an administrator registers. ContextForge’s “auto-discovery” refers to gateways finding each other on a network, which is a different meaning from discovering shadow MCP.

Commercial vendors

Other commercial vendors building MCP gateways, registries, or MCP discovery include Runlayer, MintMCP, Kong, Docker MCP Gateway, Obot, Lasso, and Bifrost.

If you’re setting up the approval and provisioning loop for MCP servers your teams already use, we’d be interested to hear where it breaks down for you. Talk to us.