MCP registry preview raises the stakes for enterprise governance

At a glance

What this is: This is an analysis of how the MCP Registry preview and ChatGPT support change the governance problem for enterprise AI integrations.

Why it matters: It matters because IAM, NHI, and platform teams will need to govern who can publish, discover, and connect to MCP servers before uncontrolled access becomes the default.

By the numbers:

• Over 160 MCP servers were registered within a few days of the official MCP Registry preview.

👉 Read Obot's analysis of the MCP Registry preview and ChatGPT support

Context

MCP, or Model Context Protocol, is becoming a discovery and connectivity layer for AI tools, but discovery without governance creates a familiar identity problem. If any server can be published and clients can connect quickly, enterprises must decide how trust is established, how access is granted, and how usage is audited across the MCP ecosystem.

The governance gap is not the protocol itself. The gap is the assumption that open publication plus light validation is enough for enterprise use, when security teams need curated onboarding, access control, and visibility tied to identity platforms and policy enforcement.

With ChatGPT adding MCP support and the registry already gaining momentum, the pressure now shifts to downstream registries and control planes. That is a typical pattern whenever a broad integration standard moves from niche adoption to enterprise relevance.

Key questions

Q: What breaks when MCP servers run locally without governance?

A: Local MCP servers inherit workstation privileges, which means they can read plaintext secrets, access user-scoped tools, and operate without a central approval point. That breaks the assumption that credential use is limited to known services. The practical result is hidden NHI sprawl, with no reliable inventory or review path for the identities doing the work.

Q: Why do account takeover metrics matter to IAM and NHI teams?

A: They show how authentication fails in the real world, especially where credentials are reused, leaked, or abused at scale. For IAM and NHI teams, those signals help connect detection to action: rotate exposed secrets, revoke stale access, and review privilege assumptions before a compromise spreads.

Q: How do you know if MCP security controls are actually working?

A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Q: Who should be accountable for MCP governance failures?

A: Accountability should sit across platform engineering, security, and the product owners of the workflows using MCP, because each owns a different part of the control plane. Security defines the policy, platform engineering enforces the server boundary, and the workflow owner approves the business purpose. If any one of those is missing, governance fragments quickly.

Technical breakdown

How the MCP Registry changes discovery and trust

The registry creates a common discovery layer for MCP servers, which is useful only if discovery is separated from trust. An open registry can verify basic origin signals such as DNS or repository ownership, but those checks do not establish enterprise suitability, privilege scope, or lifecycle governance. In practice, this makes the registry a source of candidate integrations, not an approval decision. The real control point shifts to downstream systems that can classify servers, apply policy, and decide whether a server is fit for use in a given business context.

Practical implication: treat the registry as intake, not approval, and require a second governance layer before any MCP server is made available to users or agents.

Why downstream MCP gateways matter for enterprise control

A downstream MCP gateway sits between open discovery and enterprise consumption. It can proxy traffic, enforce access controls, and maintain visibility into which users or agents connect to which servers. That matters because MCP access is not just about connectivity, it is about identity binding, authorisation, and auditability across tools that may be used by people, workflows, or agents. Without a gateway or equivalent control plane, the enterprise cannot reliably separate sanctioned MCP use from shadow MCP adoption.

Practical implication: place MCP traffic behind a governed gateway that can enforce identity-based policy, logging, and approved server catalogs.

Why MCP support in ChatGPT changes the identity surface

When a major client embeds MCP support, the protocol stops being an isolated developer pattern and becomes a mainstream access path for tools and data. That expands the identity surface because each connected server becomes a new governed endpoint with its own authentication, authorisation, and monitoring requirements. The challenge is not only technical onboarding. It is also control ownership, because the same server may be reachable from multiple clients, each with different trust and policy expectations. That is a classic identity sprawl problem in a new form.

Practical implication: inventory MCP servers as governed identity endpoints and map each one to ownership, access policy, and monitoring requirements.

Threat narrative

Attacker objective: The likely objective is to obtain unaudited access paths into enterprise tools and data through unverified MCP servers.

1. Entry occurs when a user, developer, or agent discovers and connects to an MCP server from the open registry or from an unverified source.
2. Escalation happens when the server is trusted without enterprise curation, allowing broader tool access, data exposure, or unsupported integrations to spread into production use.
3. Impact follows when shadow MCPs proliferate, users connect through ungoverned channels, and security teams lose auditability over which data and actions passed through the protocol.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP discovery has created an identity governance problem before it has created an adoption problem. The registry makes servers easier to find, but easier discovery does not equal safer consumption. Enterprises now need to govern which MCP servers are even eligible for use, because discoverability without trust controls simply accelerates shadow adoption. The practical conclusion is that MCP needs identity governance at the catalog layer, not only at the client layer.

Open publication plus minimal validation is not an enterprise trust model. DNS checks and repository ownership can indicate provenance, but they do not prove that a server is suitable for production access or aligned with policy. That means the control gap is not discovery itself, but the assumption that provenance is enough to justify access. Practitioners should treat provenance as a signal, not as authorisation.

Model Context Protocol governance now sits at the intersection of NHI, platform, and AI access control. Each MCP server is effectively a new non-human integration endpoint, even when it is used by a human-operated client. That means IAM, PAM, and NHI teams need a shared ownership model for onboarding, access review, logging, and offboarding. The organisation that fails to assign this ownership will end up with tool sprawl that no single team can see end to end.

Shadow MCPs will become the next unmanaged integration class if enterprises do not define an approved consumption path. When users can easily connect to external servers, they will do so whether or not central teams have documented the risk. The category is heading toward the same governance pattern seen in shadow IT and shadow AI. The practical conclusion is that policy must be paired with a usable enterprise catalog.

From our research:

• 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.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• Open discovery is not enough, so read OWASP Agentic Applications Top 10 for the risk patterns that matter when tools and agents start chaining access.

What this signals

MCP governance is converging with agent governance. As MCP becomes a mainstream integration path, enterprises will need a single view of non-human access that covers protocols, agents, and tool endpoints together. The organisations that separate those domains will miss privilege propagation across the full delegation chain.

The new control question is not whether a server exists in the registry, but whether it can be consumed under policy, with auditability, and with a defined owner. That is a practical identity problem, not a protocol preference.

With 80% of organisations already reporting AI agents acting beyond intended scope, per AI Agents: The New Attack Surface, the broader lesson is that discovery layers are becoming security boundaries whether teams intended them to or not.

For practitioners

• Establish an approved MCP intake process Require every new MCP server to pass through a controlled review that checks ownership, business purpose, data access, and security baseline before it is made available to users or agents.
• Bind MCP access to enterprise identity controls Use identity platforms and policy enforcement to tie each approved server to named owners, scoped permissions, logging, and offboarding procedures.
• Build a curated internal MCP catalog Publish a trusted directory that employees can browse, with only sanctioned servers and clear documentation for connection paths, support, and usage boundaries.
• Monitor for shadow MCP consumption Track unsanctioned server connections, duplicate functionality, and unreviewed tool exposure so that unapproved integrations are detected before they spread into routine use.

Key takeaways

• MCP discovery is expanding faster than enterprise trust models can absorb.
• Open registries create scale, but curated downstream controls determine whether that scale is governable.
• IAM, NHI, and platform teams need a shared ownership model before shadow MCP use becomes normalised.

Key terms

• Model Context Protocol: Model Context Protocol is an open standard that lets AI clients connect to tools and data sources through a common interface. In governance terms, it creates a new access layer that needs ownership, trust controls, logging, and lifecycle management like any other non-human integration path.
• MCP Registry: An MCP Registry is a discovery layer for publishing and finding MCP servers. It may help standardise onboarding, but it does not by itself prove enterprise suitability, authorisation, or compliance, so organisations still need downstream curation and policy enforcement.
• Downstream registry: A downstream registry is an enterprise-controlled catalog that selects, curates, and governs which external or internal MCP servers are available for use. It turns open discovery into an approved consumption model with identity controls, auditability, and clear ownership.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

Obot's full analysis covers the operational detail this post intentionally leaves for the source:

• How the MCP Gateway proxies traffic and applies enterprise governance policies.
• What downstream registry curation looks like when teams need trusted catalogs, not just discovery.
• How identity platform integration supports access control for approved MCP servers.
• Why employees need a user-facing catalog to reduce shadow MCP adoption.

👉 Obot's full discussion covers the enterprise gateway model, trusted catalog design, and adoption risks in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.