Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: Shadow MCP is already outpacing enterprise visibility, with Stacklok describing cases where teams thought they ran 4 or 5 MCP servers but discovered about 30. The governance gap is that AI agent tool access is expanding faster than catalogs, approval paths, and auditability can keep up, so the safe path must become the easiest path.
NHIMG editorial — based on content published by Stacklok: Shadow MCP: the AI governance problem hiding in plain sight
Questions worth separating out
Q: What breaks when MCP servers are not registered centrally?
A: Unregistered servers create shadow deployment.
Q: Why do MCP environments create new identity governance risk?
A: MCP environments create risk because they connect agents to tools, registries, and data sources through dynamic trust relationships.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Practitioner guidance
- Inventory every MCP server and connector Run discovery across developer environments, clusters, and shared repositories to identify undocumented MCP servers, then reconcile them against approved records and application owners.
- Establish a single approved registry Make the registry the system of record for published, approved, and retired MCP servers.
- Bind MCP approvals to identity controls Integrate registry access with your identity provider so only authorised teams can publish, modify, or consume servers.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- How the MCP Registry Server aggregates public registries, internal Git-based lists, and Kubernetes-discovered servers into one catalog.
- How identity provider integration and virtual registries support role-based access and workflow-specific views.
- How automatic discovery surfaces connection URLs, available tools, and approval status for servers running in Kubernetes.
- How the registry supports patching, updates, and retirement so deprecated servers do not remain invisible.
👉 Read Stacklok's analysis of shadow MCP and AI agent governance debt →
Shadow MCP: what it means for AI agent governance now?
Explore further
19/08/2026 4:17 pm
Shadow MCP is a governance debt problem, not a tooling anomaly. The article’s core finding is that enterprises are already undercounting active MCP servers by large margins, which means the control plane is being built after deployment, not before it. That pattern is familiar in cloud sprawl, but MCP compresses the timeline because AI agent tooling can spread across teams in days. The practitioner conclusion is that untracked MCP estates should be treated as a first-order identity governance issue, not a peripheral engineering issue.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- Another finding shows 80% of organisations report their AI agents have already performed actions beyond their intended scope, including unauthorised system access, sensitive data sharing, and credential exposure.
A question worth separating out:
Q: Who should own MCP registry decisions across engineering and security?
A: Ownership should sit with the platform or identity governance function, with security setting policy and engineering supplying operational metadata. If ownership stays informal, no one can manage registration, retirement, or approval drift consistently. The important test is whether the registry has named accountability and an enforceable lifecycle, not just a list of tools.
👉 Read our full editorial: Shadow MCP is creating AI governance debt faster than controls
