What Enterprise IT Asks First
When any new technology enters an enterprise, four questions must be answered before broad deployment:
- Who has access to what?
- What happened, and when?
- How do we remove access when someone leaves?
- Can we prove compliance to an auditor?
For MCP today, in a default setup, the honest answers are: everyone has access to everything, we do not know what happened, we cannot remove access without breaking the whole team, and no we cannot prove compliance.
This is not a reason to avoid MCP. It is a reason to build the governance layer before the rollout, not after.
The Three Phases Every Enterprise Goes Through
Phase 1 — Exploration
A few developers install MCP servers individually. Cursor with GitHub integration. Claude Desktop with a database connector. Productivity improves visibly. Word spreads internally.
Phase 2 — Team Adoption
Teams start sharing configs. Someone creates a recommended MCP stack document. A workspace token gets shared in Slack. Now the entire team is using the same token with the same access to the same tools. Nobody is logging anything. Security has no visibility.
Phase 3 — The Incident
Something unexpected happens. A production query runs at an unexpected time. A file gets modified that should not have been. An internal API gets called by an agent nobody authorised. Now the question is: "what happened, and who did it?" Nobody can answer it.
This is the moment governance becomes urgent. The problem is that retrofitting governance into an existing MCP deployment is significantly harder than building it correctly from the start — because you have no historical data, no baseline, and no audit trail from before the governance layer existed.
The Seven Capabilities Enterprise MCP Requires
1. Centralised endpoint
One authenticated URL per team. Not dozens of individual JSON configs across dozens of developer machines. A single point of control, logging, and revocation.
2. Per-member identity
Every tool call attributable to a specific person. Not "the workspace called something." Individual tokens per member, so the audit trail captures who did what.
3. Tool-level access control
The ability to say "Alice can use these tools, Bob can use those." Enforced at the protocol level. The principle of least privilege applied to AI tooling.
4. Isolated server deployment
MCP servers running in defined, auditable environments — not on developer laptops. Containers with clean lifecycle management: deployable, monitorable, and terminatable centrally.
5. Quality and trust signals
A trust signal per server that goes beyond GitHub stars. Maintenance velocity, last commit date, publisher verification, config completeness — visible before installation.
6. Instant revocation
When someone leaves the team, their access gone in seconds. Without rotating the workspace token. Without reconfiguring every AI client on the team. Individual member revocation with no blast radius.
7. Protocol-level audit log
A record of every tool call — who called it, which tool, which server, when, and whether it succeeded. Not application-level logging. Protocol-level logging that captures everything that flows through the gateway.
None of these are optional for enterprise. All of them are absent from a default MCP setup.
The Retrofit Problem
The most expensive version of this problem is the one teams build toward without realising it.
A team that deploys MCP without governance for six months has six months of tool calls with no attribution, no audit trail, and no access history. When an auditor asks "what did your AI agents have access to between January and June?", the answer is "we do not know."
That answer is not acceptable in regulated industries. It is barely acceptable in any enterprise context where AI agents have access to production systems.
The teams that establish governance now will have a clean audit trail from the first tool call. The teams that wait will be unable to reconstruct the past.
The Window Is Now
MCP adoption in enterprise is in Phase 1 and early Phase 2 for most organisations. The exploration is happening. The team adoption is beginning.
The governance layer needs to arrive before Phase 3.
Building it after an incident is possible. It is just significantly more expensive — in time, in credibility, and in the irreversible absence of historical audit data.
MCPNest is the enterprise governance layer for MCP servers — Gateway, per-member access control, hosted infrastructure, and audit logging for AI engineering teams.
mcpnest.io
Top comments (1)
Spot on, Ricardo. This is the exact architectural conversation the industry needs to have before Phase 3 hits.
The immediate friction with default MCP deployments in an enterprise setting is that they fundamentally treat the protocol as a direct, unvetted pipeline between an unpredictable runtime (the LLM) and highly sensitive, stateful data pools. On developer laptops, that's a productivity win; in a production enterprise environment, it’s a compliance nightmare.
I recently built an MCP auditor framework, and the absolute first obstacle I had to account for was this total lack of an ingestion boundary. If you don't enforce strict, protocol-level data provenance and deterministic access controls before a tool execution occurs, you aren't just looking at data leakage—you are looking at a complete breakdown of the systemic chain of custody.
Whether it's centralized orchestration layers like MCPNest or hardened local gateways, the core rule of modern AI infrastructure is: no unvetted context and no unsigned data footprints. Exceptional breakdown of the governance gap.