MCP adoption has moved past the proof-of-concept stage. Agents are connecting to servers across engineering teams, product squads, and regulated data environments. The question is no longer “should we use MCP?” — it’s “how do we run it safely at scale?”
Without governance, the answer becomes shadow MCP: agents reaching unauthorised servers outside any approval or monitoring framework. Most engineering organisations face five concrete gaps — no server inventory, no approval process, no supply chain evaluation, no migration plan, and no board-level business case.
This article gives you a governance operating model that addresses all five. The security TTPs live in the SAFE-MCP security framework — this article operates at the organisational process level. For foundational protocol context, see the MCP integration standard.
Who owns the MCP server inventory in a well-governed engineering organisation?
SRE or platform engineering owns the MCP server inventory. Not individual product teams. Not the AI team. Not the developer who first connected the server. When product teams self-manage their own MCP connections, you get fragmented inventories, inconsistent versions, and no single view of what is actually running.
Cloudflare concluded that locally-hosted MCP servers are a “losing game” because they rely on unvetted software sources and prevent administrators from governing them. Their answer is a centralised team managing all deployments. Pinterest‘s platform team took the same approach: domain experts define the tools, the platform handles deployment, scaling, and governance.
What the inventory must capture per entry
Microsoft is the most explicit on record requirements. Before any MCP server can operate in their environment, owners must declare: what the server does, what data it touches, how callers authenticate, where it runs, the version pinned, the last review date, and which agents depend on it. Microsoft’s principle: “You can’t govern what you can’t see, and MCP shows up in more places than a single system of record.”
Lifecycle management and deprecation policy
The inventory tracks the full arc from initial approval through to deprecation. When an owner leaves, a new owner must be assigned within a defined SLA. If no owner can be assigned, the server enters a deprecation queue: owner notification, agent migration deadline, sunset date, documentation archival. Without this process, unmaintained servers just accumulate as unmanaged risk.
Kiro’s enterprise registry enforces inventory at the client level — every Kiro client fetches the approved JSON registry at startup and re-syncs every 24 hours. A locally installed server no longer in the registry is terminated automatically.
How do you evaluate a third-party MCP server before enterprise onboarding?
Third-party MCP servers are supply chain risk. They’re executable code running in your environment with agent-level access to tools and data. Treat evaluation the same way you’d treat a vendor security review applied to an open-source or commercial package.
Supply chain attacks don’t require interacting with the MCP protocol itself. Malicious code can execute during agent startup — a zero-click attack vector that bypasses tool approval mechanisms entirely. The pre-onboarding evaluation is the control that stops this from happening.
Pre-onboarding evaluation checklist:
- Automated code scan: Run the server against known CVE databases before it touches any environment.
- Version pinning: Lock to a specific semantic version. Floating references like “latest” create supply-chain exposure.
- Commit-pin model: For highest-assurance environments, pin to a specific Git commit hash — cryptographically linked to content and impossible to manipulate silently.
- Signature and integrity verification: Validate the server binary or container image against a published signature.
- Scope review: Confirm the server requests only the minimum permissions for its stated function. Implementation detail lives in the SAFE-MCP security framework.
- SBOM and dependency currency: Require a software bill of materials, confirm dependencies are current, and verify no credentials are embedded in code.
- AAIF membership check: AAIF membership signals structured protocol governance under the Linux Foundation — a positive procurement signal, not a guarantee.
- Allowlist criteria confirmation: The evaluation outcome is binary — allowlisted or not.
- Ongoing monitoring cadence: Approval is not permanent. Quarterly at minimum, retriggered by major version bumps, scope changes, or owner offboarding.
When a protocol-level SEP is adopted, deployed MCP servers may require updates to stay compliant — include SEP monitoring as an upstream change management trigger. See MCP and the Linux Foundation for full context.
What does the internal MCP server approval process look like?
The supply chain evaluation above is step 2 of the full approval workflow. Here is how the complete process fits together — synthesising the approaches used by Cloudflare, Microsoft, Pinterest, and Kiro.
Stage 1 — Request: The product or feature team submits server details — name, purpose, data scope, source, version, and business justification — to the platform or SRE team.
Stage 2 — Supply chain evaluation: Code scan, version pin, SBOM check, scope review. Pass or fail with documented rationale.
Stage 3 — Scope and allowlist review: Confirm least-privilege scoping and check for duplication against existing servers. Approved servers receive an allowlist entry.
Stage 4 — Versioned deployment: Deploy the pinned version to staging, then production. Record the inventory entry with owner, version, and review date.
Stage 5 — Change management on updates: Any scope change triggers re-review; rollback procedure is documented. SEP monitoring runs in parallel as an upstream trigger for protocol-level changes.
Allowlisting as the default enforcement posture: Cloudflare, Microsoft, and Kiro all use allowlist-by-default — any server not on the approved list is blocked. This is the primary control for preventing shadow MCP.
Human-in-the-Loop Approval Gates: Governance requires human confirmation before agents execute high-impact tool actions. SocPrime‘s guidance: “For actions that create, modify, delete, pay, or escalate privileges, human review remains essential.” That’s a tooling-layer control, not just an onboarding step.
Change management: Microsoft’s production implementation compares tool metadata on connect to the approved contract and pauses for owner review if capabilities have changed. Kiro’s 24-hour registry re-sync does the same thing at the client level.
For OAuth 2.0 identity and audit logging implementation detail, see the SAFE-MCP security framework.
How should you sequence migrating custom API integrations to MCP connectors?
Migration sequencing is a prioritisation problem, not a rewrite project. The question is what order to migrate existing custom API integrations — and migration is also the moment where your M×N integration estate rationalises.
The prerequisite: dependency mapping
Map which agents and systems depend on which custom connectors before you sequence anything. This determines blast radius, informs order, and surfaces consolidation opportunities.
Prioritisation framework
Plot existing integrations on value vs. complexity. High value / low complexity: migrate first. High value / high complexity: plan carefully, parallel running required. Low value / low complexity: migrate opportunistically. Low value / high complexity: deprecation candidates, not migration targets.
Migration phases
Audit current tool interfaces first — document all existing tools, data scope, auth methods, and dependencies. Plan the wrapper strategy for each integration (wrap or rebuild), determine deployment order from the value/complexity assessment, then plan team handoffs: SRE or platform engineering takes ownership post-migration, with documentation, monitoring alerts, and the rollback plan handed over from the product team.
For high-value, high-complexity integrations, run the MCP connector alongside the legacy integration for a defined window before cutover. Migration is also the moment to consolidate: where multiple custom integrations serve the same tool, replace them with a single MCP server — this is where M×N → M+N materialises. See how MCP reduces integration complexity for the full architecture explanation.
How do you frame the M×N cost elimination case for a board presentation?
The M×N framing translates an architectural benefit into a cost argument a CEO or board can evaluate without needing to understand MCP’s protocol mechanics. For a full introduction to what MCP is and how it fits the broader agent tooling landscape, see MCP explained.
The concrete numerical example
An organisation with 8 LLM providers and 25 tools previously required 8 × 25 = 200 custom connectors. With MCP, each provider implements one MCP client and each tool implements one MCP server: 8 + 25 = 33 MCP implementations — an 84% reduction in integration surface.
The compounding savings argument: without MCP, adding one new tool to an 8-provider environment requires 8 new custom connectors. With MCP, it requires one new MCP server. Every new provider or tool added going forward compounds this advantage — not just eliminating existing debt but stopping it from accumulating at all.
Board presentation framing: four steps
- Quantify current integration debt: M × N = current connector count; M + N = target state. Apply this to your actual environment.
- Project the additive cost model: Show what adding the next provider or tool costs under each model — multiplicative vs. additive makes the ongoing savings case.
- Anchor to macro context: Organisational AI spending is accelerating sharply — from 5–8% to 20–25% of IT budget in many enterprises. Rationalising integration architecture now positions you for the AI investment wave.
- Frame as infrastructure investment, not AI experiment: MCP integration infrastructure is platform engineering investment with a documented ROI framework.
AAIF membership as a CFO and risk committee argument: Vendor-neutral protocol governance under the Linux Foundation reduces long-term vendor lock-in and integration churn. With 10,000+ published MCP servers and adoption by Claude, Cursor, Microsoft Copilot, Gemini, and ChatGPT, ecosystem momentum reduces the risk of stranded integration investment.
For the full M×N architectural explanation, see how MCP reduces integration complexity and AAIF membership and procurement risk context.
What does a complete MCP governance operating model look like?
The five components covered above aren’t a sequence of one-off tasks — they integrate into a continuously running governance architecture.
The five pillars:
-
Inventory — Live, versioned MCP server catalogue maintained by SRE or platform engineering, with owner accountability and lifecycle management. Without it, nothing else works.
-
Approval — All servers pass through the documented five-stage workflow before production. The allowlist is the enforcement gate.
-
Supply chain evaluation — Third-party servers assessed using the nine-point checklist before allowlisting. Version-pinned at onboarding, re-reviewed on update.
-
Migration governance — Custom integrations migrated via the value/complexity prioritisation framework, with dependency mapping, parallel running windows, and structured team handoffs.
-
Observability and controls — Audit logging of all tool invocations, human-in-the-loop gates for high-impact actions, OAuth 2.0 identity, RBAC permission tiering. Implementation detail lives in the SAFE-MCP security framework.
Governance as an enabler of adoption
Microsoft’s principle: every server has an owner, every deployment is inventoried, and no unapproved server can be reached. Cloudflare’s experience: “The governance is baked into the platform itself, which is what allowed adoption to spread so quickly.” Governance is what makes scale safe.
MCP Gateway as a governance simplification lever
An MCP gateway routes all agent-to-server traffic through a single control point — allowlist policies, auth checks, and audit logs applied once at the gateway layer rather than per-agent. Natoma‘s managed gateway provides 100+ verified servers with enterprise-grade governance. Microsoft’s open-source MCP Gateway (Kubernetes-native) handles session-aware stateful routing and integrates with Azure Entra ID.
The operating model as the board-level audit trail
The inventory and approval workflow are the audit trail that demonstrates AI governance maturity. When regulators or board risk committees ask what controls exist over AI agent behaviour, this is the answer: documented inventory, version-pinned approvals, supply chain evaluation records, and full observability of tool invocations. Shadow MCP is the symptom of running without it.
For foundational protocol context, see our MCP overview. For the security controls layer, the SAFE-MCP security framework covers threat taxonomy and control implementation.
Frequently Asked Questions
Who is responsible for MCP server security in an organisation — platform engineering or the product team?
Platform engineering owns the governance framework, inventory, and approval process. Product teams request servers and provide business context. Security accountability for the MCP infrastructure layer sits with platform engineering; accountability for how agents use those servers in product features sits with the product team.
What is version pinning for MCP servers and why does it matter?
Version pinning means specifying an exact version — a semantic version lock or commit SHA — rather than a floating reference like “latest.” Without it, a third-party update can silently introduce unreviewed code into production. Docker‘s commit-pin model goes further: pin to a commit hash and run an automated review loop each time it’s bumped. The pin bump is itself a governance event.
How often should an MCP server allowlist be reviewed?
Quarterly at minimum, and additionally triggered by major version bumps, scope changes, security incidents, and owner offboarding. Each review confirms the server is still actively maintained, no new vulnerabilities disclosed, and scope remains appropriate.
What is shadow MCP and how do you prevent it?
Shadow MCP (Cloudflare’s term) describes unauthorised remote MCP servers accessed by agents outside governance controls. Prevention: allowlist-by-default enforcement, centralised MCP gateway routing, and agent-level access policy enforcement. Shadow MCP is the symptom of running without the inventory and approval workflow.
What is the SEP process and why does it matter for enterprise MCP governance?
SEP (Specification Enhancement Proposal) is MCP’s formal governance mechanism for protocol-level changes. When an SEP is adopted, deployed servers may need updates to stay compliant — include SEP monitoring as an upstream trigger in your change management process. See MCP and the Linux Foundation for full context.
What governance controls are required for MCP but covered in detail elsewhere?
Least-Privilege Scoping, Audit Logging, and OAuth 2.0 are all referenced in this article but not re-explained here — implementation detail for all three lives in the SAFE-MCP security framework. The governance model must mandate these controls; how to implement them is a security layer concern.
What is the difference between a local and remote MCP server from a governance perspective?
Local servers run on the same machine as the agent — lower network attack surface, harder to govern centrally. Remote servers are accessed over HTTP/SSE — easier to govern via a gateway, more network exposure. The governance model applies to both regardless: inventory entry, approval, version pinning, and audit logging are all required.
How does an MCP gateway simplify governance?
An MCP gateway routes all agent-to-server traffic through a single control point — allowlist policies, auth checks, and audit logs are applied once at the gateway layer rather than per-agent. Natoma’s managed MCP Gateway provides 100+ verified servers with built-in access controls and audit trails. Microsoft’s open-source MCP Gateway (Kubernetes-native) handles session-aware stateful routing and integrates with Azure Entra ID.
How do you handle MCP server deprecation when the owning team is reorganised or the owner leaves?
Owner offboarding is a lifecycle management event. When an owner leaves, a new owner must be assigned within a defined SLA. If no owner can be assigned, the server enters a deprecation queue: owner notification, agent migration deadline, published sunset date, documentation archival. Without this process, unmaintained servers accumulate as unmanaged risk.
How do you calculate the M×N cost elimination for a specific organisation’s environment?
Count your LLM providers (M) and tools or data sources (N). M × N = connectors required without MCP; M + N = MCP implementations required with it. The difference is the integration surface eliminated — express it as a percentage and a headcount or cost estimate for board presentations. Example: 6 providers × 20 tools = 120 connectors vs. 26 MCP implementations — a 78% reduction.
How does AAIF membership reduce MCP procurement risk?
AAIF (Agentic AI Integration Forum) is a Linux Foundation governance body. A vendor’s participation signals their MCP server is under structured protocol governance and subject to community security review. It’s a positive procurement signal, not a guarantee — it reduces but doesn’t eliminate the need for independent code scanning and version pinning.
