MCP server sprawl and MCP governance in the enterprise

MCP governance is the control system that replaces that growth with a registry, an owner per server, scoped credentials and a recorded decision per call.

It is the same problem shadow IT posed with a sharper edge. An unmanaged SaaS app holds documents. An unmanaged MCP server holds an agent's authority to act on systems you care about.

Why does MCP server sprawl matter now?

MCP servers install like developer tooling, because that is what they are. A line in a config file, a package from a registry, an environment variable with a key. None of that touches procurement, a network gateway or a change board. The growth is fast, quiet and distributed.

The scale of the ecosystem explains the exposure. A survey of 5,200 open-source MCP servers found 88% require credentials, 53% rely on long-lived static secrets, only 8.5% use OAuth, and 79% pass API keys through environment variables (State of MCP Server Security 2025, Astrix). Each of those servers is a candidate for someone's laptop, and each one arrives with a credential decision already made for you.

Quality is uneven. In a study of 1,899 open-source servers, 7.2% carried general vulnerabilities and 5.5% showed MCP-specific tool poisoning (MCP at First Glance, arXiv:2506.13538). A smaller vendor penetration test of popular servers found command injection in 43%, server-side request forgery in 30% and path traversal in 22%, and reported that 45% of contacted vendors described the findings as theoretical or acceptable (Equixly). That last number is the one to remember when someone argues that a popular server is a safe server.

The consequence is measurable in agent behaviour, not only in server code. In one study of 20 agents and 45 live servers, o1-mini was steered by a poisoned tool 72.8% of the time, and no model refused more than 3% of attacks (MCPTox, arXiv:2508.14925). Sprawl is what puts those servers in front of agents that trust them.

How exposed is your setup? Compass gives you a structured read on your MCP and agent exposure in about ten minutes: compass.alyria.ai.

How is MCP governance different from API governance?

API governance assumes a known inventory and a build pipeline. MCP governance assumes neither. Servers appear between releases, tools change without a version bump anyone reads, and the consumer is a model choosing at runtime rather than code calling a fixed endpoint.

Dimension	API governance	MCP governance
Inventory source	API catalogue, gateway config	Endpoint config files, IDE state, process trees
Unit of approval	Endpoint and scope	Server, tool and argument pattern
Change detection	Spec diff in a repository	Negotiated tool list at connection time
Credential model	App registration with a secret or certificate	Per-server key in config, or brokered lease
Consumer	Code with fixed call sites	A model choosing tools per request
Where enforcement lands	Gateway, service mesh, WAF	Endpoint mediation plus gateway for shared services
Failure signature	Unexpected traffic	An action nobody can attribute to a person or a policy
Owner	Platform team	The team using the server, with security holding the registry

In practice: API governance asked who may call this endpoint. MCP governance asks which agent may call this tool, with which arguments, on whose authority.

What does sprawl actually look like?

Sprawl is not one bad decision. It is a handful of ordinary ones, repeated.

The shared config file

One engineer configures five servers, commits the file to a dotfiles repository, and four colleagues clone it. The keys come along. Within a month the same credential is on nine machines and nobody can say which agent used it last.

The per-project server

Each project adds the server it needs, scoped to that project's needs. Individually reasonable. Collectively, a developer with six projects has a tool list assembled by six different decisions, and no single policy describes it.

The demo server in production

A server written for a proof of concept stays connected after the demo. It has no tests, broad scope and a key with admin rights, because narrowing the key was the step that never got done.

The abandoned pilot

A team tries an agent, connects three servers and moves on. The servers remain registered, the leases keep renewing, and the agent identity stays valid for a project that no longer exists. Orphaned entries are one of the most common findings in a first inventory.

The bundled default

An IDE or agent ships with servers enabled by default. They are convenient, they are on by default, and their tool list is wider than most teams would approve if asked. The vendor is the owner, which means nobody internal is looking.

In practice: Every one of these shapes is invisible to a gateway and visible to an endpoint.

How to implement MCP governance

The order matters. A registry with no owner becomes a list. An owner with no credential path becomes a workaround.

1. Discover from the endpoint before you write policy

Cloud logs and gateways show traffic. They do not show the local server a developer started ten minutes ago. Endpoint discovery produces the list you will spend the next year governing, and it should include the config path that referenced each server.

Tip: Record the config file path and the owning user for every server found. It converts an inventory into a conversation with a person.

2. Register servers as software with owners

Each entry needs a name, a version, an owner, the tools it exposes, the data it reaches and a review date. Owners are named people, not teams, because teams do not answer questions.

3. Approve per tool, not per server

Approval of a server is a supply chain decision. Approval of a tool is a security decision. A server that reads and writes should be approved for one of those, and policy should express the difference even when the server's design does not.

4. Move credentials out of config files

Issue short-lived leases per session, scoped to the tools in play. This is the single change that most reduces the value of a leaked config file, and it is also the change that surfaces how many servers depend on a key someone pasted years ago.

Tip: Run the credential migration in parallel with discovery, not after it. Every week of delay adds servers to the migration backlog.

5. Decide at runtime with attribution

Every tool call should produce a decision naming the agent, the server, the tool, the arguments and the outcome. Attribution per agent is what turns a server log into an investigation.

6. Detect change, not just incidents

Alert when a new server appears, when an existing server adds a tool, when a credential's scope changes, or when a config file is modified outside the registry. Change detection catches sprawl while it is still cheap.

7. Publish a fast path to approval

If approval takes three weeks, engineers will route around it and never tell you. A published decision time, a reviewable template and a default that allows read-only access with logging removes most of the incentive to go around.

8. Retire on a schedule

Every server gets a review date and a removal path. Servers with no calls in 90 days should be candidates for removal, and the decision should be recorded so the next inventory starts from a smaller number.

Where MCP governance applies in the agent lifecycle

Design

Decide which servers the use case needs, and whether a narrower one exists. The design review is where the tool list is small enough to reason about.

Note: Requirements produce server lists. "Connect it to everything so it works" is not a requirement, and it is how the widest tool lists get approved.

Development

Keep server configuration in the project, versioned, with no secrets. A config file is code and should be reviewed like code.

Pre-deployment testing

Test the server's tool list as it actually arrives at runtime. Confirm that a hostile description or an unexpected tool does not silently enter the approved set.

Note: A server that adds a tool between your review and the deployment is a change you have not approved, even though your config file is unchanged.

Deployment

Register the server before the first call, issue credentials through the broker, and confirm attribution appears in the record. A server that works but cannot be attributed is a governance regression.

Runtime

Policy decides per call. Read and write are separated. Egress is a decision with named destinations. Local and remote servers are treated the same way.

Continuous monitoring

Track approvals against observations, new servers per week, standing secrets remaining, and the share of calls with a recorded decision. These four numbers show whether governance is keeping up.

Note: The observation count always grows faster than the approval count at the start. That is normal, and it is why the ratio is the metric rather than the total.

Decommissioning

Remove the registration, revoke the credential path, delete stored keys, and keep the call history for the retention period. Orphan count is a useful quarterly measure of how well retirement works.

The takeaway: Sprawl is not solved by saying no. It is solved by making the registered path faster than the unregistered one, then measuring the gap.

Worked example: MCP governance at a 900-engineer company

A logistics company has 900 engineers, three sanctioned coding agents and a security team of 14. Nobody can answer how many MCP servers are in use.

Month 1, baseline. Endpoint discovery finds 214 distinct servers across 1,300 machines. Nineteen are on the internal allowlist. Sixty-one appear in at least three config files, which suggests they spread through shared dotfiles. Nine servers hold credentials that resolve to admin scope on source control or the cloud control plane, and two of those keys are committed to public repositories from a former employee's dotfiles.

Month 1, containment. The two exposed keys are rotated the same day. A policy that blocks tool calls from servers not on the allowlist is deployed in monitor mode, so the team can see what enforcement would have stopped without breaking work.

Month 2, registry. A registry is created from the discovery data with an owner per server, a version, a tool list and a data classification. Thirty-eight servers are approved, 26 are approved read-only, and the rest are scheduled for a decision. Every entry has a name against it, and the 214 number becomes a work queue rather than a statistic.

Month 3, credentials. Credentials move to short-lived leases. The change breaks 11 servers, most of which depended on a key in an environment variable. Six are rewritten to use the broker, two are retired, three are replaced by a narrower internal server.

Month 4, enforcement. Enforcement turns on for the highest-value systems first: source control, cloud control planes, the customer database. Denials are logged with the agent, the server, the tool and the arguments. Two teams complain, one because a legitimate workflow used a blocked tool, which is fixed by adding a narrow rule with a review date.

Month 6, change detection. An alert fires on a documentation server that added a tool whose description includes an instruction to post results externally. It had been updated three weeks earlier and auto-updated on 40 laptops. The tool is blocked by policy, the version is pinned, and the finding is logged as a supply chain event.

Month 12, steady state. 61 approved servers, 12 pending, 23 retired, and 4 orphaned entries cleared. The gap between observed and approved is 9 servers, down from 195, and it is reviewed weekly rather than annually.

What changed was not the protocol. It was that servers became software with owners, and calls became decisions with records.

How standards and regulations influence MCP governance

Framework	Primary focus	Relevance to MCP governance
OWASP MCP Top 10 (beta)	MCP risks including MCP02 scope creep, MCP04 supply chain, MCP09 shadow servers	The checklist for registry entries and server review
OWASP Top 10 for Agentic Applications 2026	ASI03 identity abuse, ASI04 supply chain, ASI07 inter-agent communication	Frames sprawl as an agent-level risk, not only a tooling risk
NIST AI RMF	Govern, Map, Measure, Manage	MAP expects an inventory in context, which is the registry
ISO/IEC 42001	AI management system and documented controls	Requires roles, records and review cycles for AI components
ISO/IEC 23894	AI risk management inside enterprise risk	Routes server risk through the third-party risk process
EU AI Act	Obligations by risk class, including logging and human oversight	Applies where connected tools sit inside a high-risk system
SOC 2	Access control, monitoring, change management	Expects authorisation and review evidence for tool access

Further reading: Model Context Protocol for how the protocol works, MCP security for per-server controls, and Shadow AI for the wider unmanaged estate.

How Alyria handles it

Alyria treats MCP servers as part of the endpoint estate rather than as a network service. Beacon, the signed daemon on every machine, inventories MCP clients and servers continuously, including local stdio servers, records the config that referenced each one and reports the tools each server exposes. The registry starts from what is actually running rather than from what someone remembered to list.

Lyra holds the policy: which server, which tool, which arguments, which data and which destination, decided locally before the call executes. Approvals are expressible at the tool level, so a read-only approval does not become a write path by accident.

Umbra takes the keys out of the config files and issues short-lived leases at the moment of use, sealed to device hardware keys Alyria never holds. Spectra streams signed, chained OpenTelemetry to Alyria Cloud or to your own SIEM, so the per-call record survives an audit and the chain can be verified without trusting the writer.

Start free at alyria.ai with one Beacon and see your own server count before you write a policy: app.alyria.ai/signup.

The docs cover how the modules fit together, and the free Agent Exposure Report is the read-only starting point.