Rolling out MCP in an organization: an approval and governance framework

The moment MCP works on one developer’s laptop, it starts spreading. Someone adds a database server, someone else wires up Jira, and within a month you have forty servers nobody reviewed, running with credentials nobody rotated. This article gives you the governance framework to get ahead of that — the same shape of controls that regulated industries apply to any third-party integration, written so any team can use it.

The good news: MCP’s architecture makes governance tractable. Servers are discrete, declarable units with named tools. You can list them, review them, allowlist them, and log them. You just need a process.

Who can add a server: the intake process

Treat every MCP server like a third-party dependency, because that is exactly what it is — code that runs with credentials and feeds text into a model that acts on it.

A workable intake process has three roles:

• Requester — anyone. A developer fills in a short intake form (below). Low friction here is deliberate: if requesting takes a week, people will bypass you with --scope local.
• Reviewer — a platform or security engineer who owns the checklist. One reviewer per request, timeboxed to a few days.
• Approver — whoever owns the risk. For read-only internal servers this can be the team lead; for anything touching customer data or write actions, it should be your security function.

The intake form

Keep it to one page:

1. Server name, source (registry entry, repository URL, or vendor), and version pin.
2. Transport: stdio (runs locally) or Streamable HTTP (remote — where is it hosted, who operates it?).
3. Tools exposed: full list, with each tool marked read-only or write/destructive. Tool annotations (readOnlyHint, destructiveHint, in the spec since 2025-03-26) are a starting point, but they are hints from the server — verify them yourself.
4. Data touched: what systems the server reaches, and the sensitivity classification of that data.
5. Credentials required: what secrets, what scope, where they will be stored.
6. Requesting team and business justification, one sentence.

The review checklist

For each request, the reviewer confirms:

• Provenance — package comes from the official registry (registry.modelcontextprotocol.io), a known vendor, or your internal artifact store; exact name verified against typosquats; version pinned, not latest.
• Tool descriptions read — every tool description reviewed by a human for hidden instructions (tool poisoning is a documented attack class; see the MCP threat model).
• Least privilege — the credential the server receives can only do what the listed tools need. A “read Jira tickets” server does not get a Jira admin token.
• No token passthrough — for HTTP servers, the server validates token audience and never forwards the client’s token upstream. The spec forbids passthrough outright.
• Network posture — remote servers reachable only over TLS; local servers make no unexpected outbound calls (run it once under a proxy and look).
• Update story — who watches for new versions and re-reviews on upgrade? Tool definitions can change between versions; a re-review triggers whenever the tool list or descriptions change.
• Logging — tool calls from this server can be captured (natively, or via your gateway).

Approved servers go into a catalog: an internal page listing each server, its version, its risk tier, its owner, and its approved scope. The catalog is the single source of truth everything else hangs off.

Allowlists per team

Approval should never mean “available to everyone”. A server approved for the data team’s warehouse queries has no business on a marketing laptop.

Enforce this at the client configuration layer:

• Claude Code: check a .mcp.json into each team’s repositories listing only that team’s approved servers, with secrets referenced as ${VAR} — never inline. Project scope means the allowlist travels with the code and goes through pull-request review like everything else.
• Managed desktops: for clients like Claude Desktop, deploy the config file (claude_desktop_config.json) through your device-management tooling rather than letting users hand-edit it, and audit for drift.
• Gateway-enforced: the strongest option — route all MCP traffic through a central gateway that maps team identity to an allowlist server-side, so a hand-edited local config buys nothing. The gateway pattern article covers this in depth.

Practical rule: the allowlist lives in version control, changes go through review, and the diff is the approval record.

Scoping permissions

Three layers, narrowest wins:

1. Credential scope. The token or key the server holds is the hard ceiling. Issue per-server credentials with minimal scopes and short lifetimes. One shared “integration account” across servers is the classic mistake — it makes audit attribution impossible and blast radius total.
2. Tool exposure. Fewer tools is safer and cheaper — every exposed tool definition also consumes context on every request (see controlling MCP token cost). If the team needs three of a server’s twelve tools, filter the other nine at the gateway.
3. Client-side consent. Hosts prompt before tool calls; keep write/destructive tools on explicit per-call approval and reserve auto-approve for read-only tools on non-sensitive data. Write that policy down so teams don’t decide it individually.

Enterprise-Managed Authorization: SSO for MCP

Until mid-2026, the awkward gap in MCP governance was identity: OAuth flows were per-user, per-server, with consent screens your IT department never saw. The Enterprise-Managed Authorization (EMA) extension, stable as of July 2026 and implemented by Anthropic, Microsoft, and Okta, closes that gap.

What EMA gives you:

• SSO through your IdP. Users authenticate to MCP servers via your existing identity provider, using ID-JAG (identity assertion JWT authorization grants) to exchange enterprise identity for resource access — no per-server password sprawl, no shadow consent.
• Central grant management. Admins decide which servers the organization trusts and which scopes users may grant, instead of each employee clicking “Allow” alone.
• Clean offboarding. Leaving the IdP revokes MCP access everywhere at once — the control auditors always ask about first.

If you are evaluating remote MCP servers for organizational use, make EMA support a procurement requirement. It is the difference between “each user pinky-promises” and identity governance you can evidence.

Audit trail expectations

Whether or not anyone audits you formally, build the record you would want after an incident. Minimum viable audit trail:

• Who: user identity (from the IdP once EMA is in play) and client application.
• What: server, tool name, and arguments — with sensitive argument values redacted at capture time, not at report time.
• Outcome: success or error, and whether a human approved the call or it was auto-approved.
• When and where: timestamp and originating host.
• Config changes: every allowlist and catalog change, which version control gives you for free if allowlists live in repos.

Retention should follow whatever your organization already applies to application logs. The point is reconstructability: for any consequential action an agent took, you can answer which person, which model session, which tool, which arguments, who approved it.

The rollout ladder: pilot → team → org

Do not roll MCP out organization-wide in one step. Climb:

Rung 1 — Pilot (2–6 weeks). One team, read-only servers only, local stdio or a single trusted remote. Goals: exercise the intake process on 3–5 real servers, capture logs end-to-end, write the first draft of your approval checklist from what you actually hit. Exit criteria: catalog exists, logging works, checklist tested.

Rung 2 — Team (a quarter). Several teams, per-team allowlists, first write-capable tools under explicit approval. Stand up the gateway if you are using one. Goals: prove allowlist enforcement, run one credential-rotation drill, do one tabletop exercise (“a tool description turned malicious — walk the response”). Exit criteria: an audit-trail query answers the who/what/when question in minutes.

Rung 3 — Org. Self-service intake against the published checklist, EMA-backed SSO for remote servers, quarterly re-review of the catalog, and drift detection on client configs. At this rung governance is routine, not heroics — which is the whole point.

Each rung earns the next. If your pilot cannot produce a clean audit trail for ten users, an org-wide rollout will not produce one for a thousand.

Where to start this week

Three moves, no committee required: create the catalog page and list every server already in use (you will find more than you expect); write the one-page intake form; and pick the pilot team. The framework above scales up from there — and the technical hardening that backs it is covered step by step in the security hardening tutorial.