Most enterprises that rolled out GitHub Copilot or VS Code MCP support did not roll out a security review process to keep pace.
Developers see news of a useful MCP server, install it, and the server now sits inside the IDE process — reading repo context, sometimes reading credentials, sometimes shaping LLM prompts on its way to and from the model. The server is unvetted. The security team finds out about it from a Slack thread, weeks later, after a developer mentions it offhand.
This is not an MCP problem. The protocol does what it says. This is an enterprise rollout problem. The protocol is faster than the security review around it.
The fix is structural. An allow-list of approved MCP servers, surfaced inside the IDE, with provenance and approval status visible to the developer at install time. Not a Confluence page. Not a Slack pin. A live, authenticated, allow-list service the IDE can read.
That is what an enterprise-grade MCP rollout looks like in 2026. And that is the pattern Naftiko Fleet ships.
What an allow-list capability does
A Naftiko Fleet allow-list capability is a single MCP tool — list-approved-servers — that returns only the entries your security team has explicitly approved. It runs every time a developer opens the MCP picker in VS Code or Copilot. The picker only ever shows them servers your org has reviewed.
The structured payload includes the registry URN, the org policy tags, the security review date, the reviewer, and a pointer to the underlying spec. A coding assistant can reason about it. A human can read it. The whole thing is governable.
When a developer asks “can I use this MCP server?” the answer is in their IDE, not in their inbox.
The Schneider Electric proof point
A global industrial-technology enterprise — one we work with closely — has been running this exact pattern against the open-source community MCP registry for months. ~6,000 developers. ~10 approved MCP servers in the allow-list at any given time. Roughly fifteen weeks of operating experience that says the model works at enterprise scale.
The architecture they ship: developers see only allow-listed servers in their IDE picker. The actual server packages sit in their internal JFrog Artifactory. The registry is a community three-URL setup acting as the metadata index. Every server in the allow-list has been through the security team’s review pipeline. The MCP picker integrates the allow-list as the only discoverable surface.
When the GitHub MCP Registry shipped earlier this year as a public catalog, the Schneider pattern needed no architectural change to extend onto it. Naftiko Fleet’s mirror capability turned the GitHub registry into another upstream — feeding the same governance pipeline they already run. The allow-list is the contract; the catalog is just a source.
The four capabilities Fleet ships for this
Naftiko Fleet exposes the GitHub MCP Registry management story as four composable capabilities, each anchored on one GitHub API surface:
manage-github-mcp-registry-mirror— pulls approved entries from the public registry into a governed internal mirror, attaching org policy on the way inmanage-github-mcp-registry-publish— opens a PR against the public registry from a capability YAML, governance metadata baked inmanage-github-mcp-registry-allow-list— filters the mirror to security-approved entries, exposes thelist-approved-serversMCP tool to IDEsmanage-github-mcp-registry-attest— attaches Sigstore-backed signed provenance to each entry so the chain is verifiable
These are not aspirations. These are the four capability specs published in the Naftiko Fleet capability catalog right now. Read the spec. Inspect the consumes block. Run the operations against a sandbox. None of this is a deck.
Three dimensions of the rollout
Technology: one MCP tool replaces the N “is this MCP server OK?” Slack threads happening across your engineering channels. The IDE is the enforcement point. The allow-list is the source.
Business: review cost moves from per-developer to per-entry. Security teams get back hours per week. New servers reach the development population within minutes of approval, instead of accumulating in someone’s inbox for a quarter.
Politics: the security team writes the allow-list once and lets the IDE enforce it forever. Developers see the same registry their counterparts at every other company see, but only the slice the org has approved. Discovery time drops to zero for approved servers; supply-chain risk drops to near-zero for unapproved ones.
What to do this week
If your enterprise is shipping MCP servers without an allow-list today, you are accumulating a supply-chain incident on a curve that is steeper than most security teams realize. Every additional MCP server in production widens the surface. Every additional developer with MCP enabled widens it further.
The allow-list is not a future-state capability. It is a present-state requirement. The runtime to ship it exists now in the Naftiko Fleet. The pattern is proven by the Schneider deployment. The four backing capabilities are published.
The only remaining question is whether you ship the allow-list before or after the first incident.
