Enterprise MCP is not one rollout, it is four, stacked in an order that keeps a mistake small and recoverable at each step rather than expensive after the fact. That order is the actual subject of this post: which tools go live first, who owns approving a new source, when a write action is allowed to run without a human watching it, and how you would know if any of that quietly broke.
Most guidance on this stops at "connect a server and see what happens." That is fine for one engineer trying MCP on a laptop. It is not a plan for a company where a support agent, a finance lead and a contractor might all be asking the same tool for different things, with different things they are allowed to see. This post is that plan, phase by phase, with the failure modes each phase exists to catch.
What "enterprise mcp" actually needs to mean before you roll it out
Before any phase starts, get one sentence agreed in the room: MCP is a protocol for connecting an agent to a tool, and it says nothing on its own about who that agent is acting for or what they are allowed to retrieve. A server can be perfectly built and still hand two different employees identical access to a customer database, because nothing in the connection itself resolves a caller down to a person with a specific, scoped grant.
That distinction, connection versus authorisation, is where most rollout plans quietly lose a phase. Teams budget time to stand up a server and connect it to Slack or GitHub. They rarely budget separate time to decide who inside the company should get which answer, and that gap is exactly where the survey data below says people are getting stuck.
How many enterprises are actually running mcp in production?
Fewer than the hype suggests. Stacklok surveyed 300 senior technical leaders across large enterprises in software, financial services and retail in December 2025, filtering for respondents with real decision-making ownership of AI investment. Among the software respondents, 26% reported MCP in limited production and 19% in broad production, a combined 45%. Another 30% were still piloting, and 26% were only planning or evaluating options. Adoption is real and moving quickly, not finished.
"MCP is already a top-five priority for nearly half of software enterprises, and they are leading the charge to put MCP into production; their success hinges on secure, governed, enterprise-grade MCP deployments that can safely connect AI to critical internal systems."
Stacklok, "State of Model Context Protocol in Software 2026", Conclusions
That single sentence is the whole argument for treating a rollout as a governed sequence rather than a single "turn it on" step. The organisations leading production adoption are the ones that built the governance in alongside it, not after.
The four-phase rollout
Each phase below has a clear owner, a clear exit condition, and a specific thing it is designed to catch before the next phase makes the mistake more expensive.
| Phase | Scope | Typical duration | Exit condition | What it catches |
|---|---|---|---|---|
| 1. Single-team pilot | One team, two to three read-only tools (e.g. issue tracker, internal wiki) | 2-3 weeks | Team can retrieve real answers with no incident, and every call is logged | Whether the connector actually returns what its manifest claims |
| 2. Scoped expansion | Two to four teams, named owner per connected source, roles mapped to scopes | 3-4 weeks | Each source has a named accountable owner and a written scope, not a shared credential | Whether access is drifting to "everyone gets everything" by default |
| 3. Write-action trial | One low-risk write tool, held for a named human approver | 2-3 weeks | At least one write has been proposed, approved, executed and logged end to end | Whether a mistaken write is recoverable before more write tools are added |
| 4. Company-wide rollout | All approved teams, quarterly access review scheduled | Ongoing | Access review has a calendar date and an owner, not just a policy document | Whether entitlements silently outlive the person or project they were granted for |
Table 1: a four-phase enterprise MCP rollout, with the specific failure each phase is designed to surface before the next phase compounds it.
A worked example
A 6,000-employee logistics company ran this exact sequence in 2026. Week one, the platform engineering team connected a single MCP server to their internal Confluence space and their issue tracker, read-only, for eight engineers. Nothing outside those two sources was reachable. By week three they had caught one thing worth catching: the issue tracker connector's manifest claimed it filtered by project, but a manual check showed it returned tickets across every project the service account could see, not just the ones the pilot team worked on. That is a defect a pilot is supposed to find, on two connectors and eight people, rather than on twenty connectors and six hundred people.
Weeks four through seven added the customer support and finance teams, each with a named owner for their own source connections rather than a shared service account everyone borrowed. Weeks eight through ten trialled a single write action, updating a ticket's status field, held for a support team lead to approve before it ran. Only in week eleven did the company open access more broadly, with a calendar reminder set for a quarterly review of who still needed what. Twelve weeks, not because the technology took that long to configure, but because each phase existed specifically to be small enough that a mistake in it stayed cheap.
What actually blocks enterprise mcp adoption
It is worth being honest about where teams get stuck, because the data does not match the usual assumption that cost or a lack of use cases is the blocker.
| Obstacle (software respondents) | Share reporting it | Source |
|---|---|---|
| Security concerns and requirements | 64% | Stacklok, State of MCP in Software 2026 |
| Cost of implementation or running costs | 40% | Same survey |
| Legacy system integration complexity | 38% | Same survey |
| Lack of end user training | 37% | Same survey |
| Proving business value | 36% | Same survey |
Table 2: obstacles software-sector respondents named as blocking or slowing MCP adoption, December 2025, multiple selection allowed.
Security topped the list by a wide margin, and the same respondents were specific about what they were doing about it: role-based permissions (67%), audit logging and monitoring (60%), and zero-trust access control (54%) were the measures most commonly already in place among software firms in that survey. None of those three is exotic. They are the ordinary controls a rollout plan should assume from phase one, not something bolted on once an incident forces the question.
Does an mcp gateway solve the governance question on its own?
Not by itself, and this is the mistake worth naming before phase two starts. A gateway that sits in front of several MCP servers typically handles routing, credential injection and rate limiting, which are real and necessary jobs. What it usually does not decide is what a specific authenticated caller should see once the connection is open. That is a separate design choice, and what an MCP registry does not do covers the adjacent mistake of confusing a directory of servers with a check on who may call them.
Contextely's own approach is deliberately not a transparent aggregation of everything an upstream server can do. A tool only becomes reachable once an administrator has enabled it, filed it as read or write, and named the scope it requires, so connecting a server does not by itself expose its tool list. That is more setup than a drop-in proxy, and it is the trade this whole post is arguing an enterprise rollout should make room for. Where Contextely does route calls to upstream read tools directly, one caveat travels with that: a passthrough answer is not ranked, because entitlement gates whether the call happens at all, not what shape the reply comes back in. The MCP pillar page sets out that boundary in full, and MCP authorization per person, not per server covers the mechanics of the caller-level check itself. The protocol's own authorization specification is explicit that token scope has to be resource-specific, which is the same instinct behind per-person entitlement, just applied one layer further in.
Enterprise mcp security requirements, mapped to the rollout
The four phases above map onto a short, concrete security checklist rather than a vague policy statement:
- No server goes live in phase one without an authentication mechanism of some kind. A server with none at all is the single worst-case condition a rollout can walk into, and it is the cheapest thing on this list to rule out up front. The OWASP MCP Top 10 project catalogues the fuller set of risks this single control is a defence against, from credential exposure to privilege escalation.
- Every call is logged before the entitlement check runs, including refused calls, so a denied attempt leaves the same trail a successful one does. MCP security explained has the fuller argument for why ordering here matters, not just presence.
- Phase two assigns a named, accountable owner to every connected source, not a shared credential three teams quietly use. An owner is who gets paged when a source starts returning something it should not.
- Phase three holds every write action for a named human approver until the team has evidence the write behaves as expected under real load, not just in a demo.
- Phase four schedules a recurring access review with a calendar date attached to it, because an entitlement that never expires is functionally a standing grant nobody remembers giving.
Teams weighing whether to run this themselves against a hosted option should read what self-hosted MCP governance actually costs before committing either way, since the operational discipline required, not a licence fee, is usually the real cost either path asks for. /security documents how credentials and entitlement checks are handled in Contextely's own implementation, for teams that want to see the ordering written against real code rather than described in the abstract.
What to check before you call the rollout finished
A rollout plan that stops at "company-wide access granted" has not actually finished, because entitlements decay in one direction only: upward, as people change teams and nobody revokes what they no longer need. Before calling any phase complete, confirm three things hold: every source still has a named owner who could describe what it is used for, every write tool still requires an approval step rather than having quietly become "trusted" through repetition, and the most recent access review has an actual date on it rather than existing only as a line in a policy document. None of that is difficult work. It is only work that gets skipped once the initial rollout starts to feel finished, which is exactly the point at which the 64% of respondents who named security as their top obstacle presumably wish someone had kept checking.