MCP governance is the discipline of controlling who can call which MCP (Model Context Protocol) server, with what scope, and under what audit trail. It has moved from theoretical concern to practical requirement in the last twelve months: Anthropic donated MCP to the Linux Foundation in December 2025, the Enterprise-Managed Authorisation (EMA) extension was promoted to stable in July 2026, and the 2026-07-28 specification release candidate introduced session and transport primitives that make enterprise deployment tractable.
The consequence is that MCP is now the connection layer for enterprise AI agents. And the connection layer needs governance the same way any production surface does.
What MCP actually is (and isn't)
MCP is a protocol for exposing tools, data, and prompts to LLM applications through a standardized interface. An MCP server offers capabilities; an MCP client (usually an AI application) consumes them. The wire format is JSON-RPC over stdio or HTTP.
MCP is not a governance system. It is a transport. The governance has to be built around it — at the client, at the server, at a gateway sitting between, or (in mature deployments) at all three.
The five things MCP governance decides
- Who can connect. Authenticated identity of the caller. EMA extension standardizes SSO-integrated OAuth flows for this.
- To which servers. Allow-list of registered MCP endpoints, indexed by trust tier.
- With which scope. A given tool call within a given server may be allowed or denied per policy — for example, "read filesystem OK, write filesystem denied without approval."
- Auditable how. Every tool invocation should produce an audit row with the same rigor as an API call to a production database.
- Recoverable when. If a tool call has real-world side effects (send email, create ticket, transfer money), the audit trail plus a rollback path are the difference between "governed" and "regretted."
The gap MCP left
The base MCP protocol answers "how do these programs talk?" It does not answer any of the five questions above. The stable EMA extension addresses (1) — authentication and identity. The other four are still deployment concerns.
That is why the MCP governance category exists. It is where the enterprise-shaped controls live.
The three deployment shapes
Shape A: hosted registry + direct connection
Clients discover MCP servers via a registry (Glama, Smithery, PulseMCP), then connect directly. Registry provides discovery and quality signals; policy is enforced at the client. Simple, appropriate for developer tooling and personal use. Not sufficient for enterprise: no central audit, no revocation, no cross-team policy.
Shape B: enterprise MCP gateway (proxy)
All MCP traffic from clients to servers passes through a gateway. The gateway authenticates callers, enforces per-tool policy, produces audit rows, and can revoke access without touching the servers themselves. This is the pattern of MintMCP, Lunar.dev MCPX, TrueFoundry, Obot, IBM ContextForge, and similar.
Shape C: gateway + registry + governed client
The mature deployment: a governance-aware MCP registry (allow-listed sources), a gateway on the traffic path, and clients that respect policy in-app. Redundant enforcement (defense in depth); acceptable operational cost for regulated environments.
What EMA actually gives you
The Enterprise-Managed Authorization extension, stable as of July 2026, provides a standardized way to plug MCP into your existing identity provider (Okta, Entra, Ping, Auth0). The MCP server delegates authentication to your IdP; the client obtains an OAuth token; the server verifies it before serving.
Adopted by Anthropic, Microsoft, Okta, and a growing list of servers. Necessary but not sufficient — EMA gives you "who is the caller?" It does not give you "what is the caller allowed to do?" That is the policy layer above.
Common pitfalls
1. Registry as governance
Listing your MCP servers in a registry is not governance. Registries are discovery tools; they do not enforce anything at request time. A malicious or misconfigured client that has the URL of your MCP server can bypass the registry entirely.
2. Authentication as governance
Turning on OAuth via EMA is necessary but not enough. Once the caller is authenticated, the policy layer still has to answer "which tools can this identity invoke on this server, with what arguments?" Auth alone is a boolean; policy is a graph.
3. Trust without audit
Deploying MCP into production without per-invocation audit rows leaves you unable to answer basic incident-response questions after the fact. Which agent called which tool with which arguments? At what time? On whose behalf? Without audit, "we don't know" is your answer.
4. Local stdio in production
The stdio transport (client and server in the same process tree) is convenient for local development. It is a bad fit for production because there is no natural place to insert a gateway, and audit ends at the process boundary.
What good looks like in 2026
- Every MCP server your organization consumes is either self-hosted or in a governance-vetted registry.
- Every MCP client authenticates via your IdP (EMA).
- All traffic passes through a gateway that enforces per-tool policy.
- Every tool invocation produces an audit row that survives at least 12 months.
- Destructive tool calls (writes, side effects) require a policy tier above read tools.
- Revocation is a single-command operation at the gateway.
Where ThinkNEO fits
ThinkNEO's MCP posture: 8 SMB MCP servers (68 tools) built to the audit-and-scope discipline described above, running behind the same enforcement plane that governs LLM calls. Glama registry status: AAA (independently verified quality tier). The MCP governance surface is the same audit ledger, the same identity model, the same fail-CLOSED/fail-NEUTRAL discipline as the LLM plane.
Related reading: How to secure an MCP server · MCP registries compared · ThinkNEO MCP servers