Supply chain and unapproved MCP servers: dependencies, installation and shadow IT

Introduction

An MCP server can be installed locally or consumed as a service. In both cases it matters who maintains it, what code it runs, which dependencies it uses and what access it needs. An unapproved server is not automatically malicious, but it may operate outside the organization’s normal controls.

Inventory before expansion

Keep a register of servers and versions: owner, origin, environment, exposed tools, permissions, data handled, network destinations and update process. Review packages, images and artifacts through trusted sources; pin versions where appropriate, verify provenance and integrity, and analyze dependencies and installation scripts before granting sensitive access.

Separate development, evaluation and production. Use limited test credentials during evaluation and avoid installing with administrative privileges if they are not needed. Establish a simple path to request review and a clear exceptions policy; prohibiting without offering alternatives can hide usage instead of governing it.

Responding to change and shadow IT

Look for client configurations, processes and network connections in line with corporate policies and applicable regulations. Make sure monitoring is proportionate and transparent. When an unregistered server appears, identify the owner, capabilities and data it accessed before deciding whether to block, isolate, approve or remove it.

OWASP’s MCP09:2025 roadmap covers unapproved MCP servers under the Shadow MCP Servers category. It is a reference from an evolving community project, not a normative obligation of the protocol.

Conclusion

A sustainable program combines inventory, provenance review, minimal permissions, controlled updates and a practical path to obtain approval. That way innovation is governed without assuming that every installation is trustworthy or that every unapproved installation is an incident.