MCP server governance: from intake to retirement
Keep an MCP server inventory, approve servers before use, review each tool, treat changed definitions as new decisions and retire servers cleanly.
The decision in brief
MCP server governance treats each server as software that can act on company systems. Keep an inventory with an owner for every server, approve servers against clear criteria, review each tool rather than the server alone, treat a changed tool definition as a new decision, contain servers that run on laptops and retire servers by revoking their credentials as well as their configuration. A registry listing or a passing scan informs these decisions; it does not make them.
What MCP server governance covers
An MCP server is the part of an agent setup that does the work. It offers tools, such as creating an issue or querying a database, and runs them with whatever credentials and access it holds. Some servers run remotely and are reached over HTTP; others are local processes launched on a person’s laptop.
MCP server governance decides which of those servers your teams may use and keeps that decision current. It follows a lifecycle: find what exists, approve servers against criteria, review their tools, watch for changes and retire them when they are no longer needed. Each stage needs an owner and a record.
It sits next to access governance, which decides who may use an approved server and with which data. Server governance usually comes first, because there is little point managing access to a server you have not decided to trust. OWASP’s MCP Top 10, currently a beta project, includes supply chain attacks, tool poisoning and shadow MCP servers among its risks.
Build an inventory you can keep current
MCP servers are often in use before anyone approves them; the MCP project’s guidance tells administrators to assume they will not be asked first. Begin by listing what already exists: remote servers connected through a gateway or an AI client’s admin settings, and local servers in the configuration files of tools such as Claude Code and Cursor.
Client configuration files live in known locations, so endpoint management tools can collect them continuously. A device inventory shows what is configured, which is not the same as what is connected or used. Treat it as a starting point for conversations rather than proof.
Record enough about each server to make later decisions quickly.
| Field | Why it matters |
|---|---|
| Owner | Someone approves changes and answers questions |
| Publisher and source | Shows who you are trusting and where updates come from |
| Version or endpoint | Lets you notice changes and respond to security advisories |
| Where it runs | Local servers need endpoint controls; remote ones can use a gateway |
| Credential and scopes | Shows what the server can do with someone’s authority |
| Enabled tools | Shows what agents can actually ask it to do |
| Users and teams | Shows who is affected by a change or retirement |
| Next review date | Stops an approval from becoming permanent by default |
Approve servers against clear criteria
A short, published set of criteria makes approval faster and more consistent. The MCP project’s guidance for organizations suggests an allowlist of vetted servers with pinned versions, and criteria such as an identifiable publisher, readable source, provenance metadata and a software bill of materials.
Registries help with discovery, not approval. The official MCP Registry, still in preview, verifies that a publisher controls a namespace and leaves security scanning to package registries and downstream catalogs. In the project’s own words, a listing on a registry is not an endorsement. These questions cover most approval decisions:
- Who publishes the server, and can you read its source?
- Does it need to run locally, or is there a remote version?
- How does it authenticate, and whose credential will it use?
- Which scopes does it request, and are they the narrowest that work?
- Which tools does it offer, and which of them change data or contact people?
- Which data will it read, and where will the results go?
- How are updates released, and how will you hear about vulnerabilities?
Prefer remote servers for shared systems
A server that only wraps a SaaS API gains nothing from running on every laptop. The MCP guidance recommends the remote version where one exists: it runs no code on the user’s machine, uses the protocol’s authorization flow instead of a token in a local file, and is patched in one place.
Remote servers can also be reached through a governed path, where access rules and records apply to every request. Keep local servers for work that genuinely needs the machine, such as reading a working tree or driving a local tool.
Review each tool, not just the server
Approving a server is not the same as approving everything it can do. A project management server might offer tools to read issues, edit them, delete them and change permissions. Enable the tools a workflow needs and leave the rest off.
Read the tool definitions as well as the documentation. Tool names and descriptions are instructions the model reads, and a malicious server can hide directives in them. Invariant Labs called this tool poisoning when it demonstrated the attack in April 2025. The MCP specification says clients must treat tool annotations, such as a hint that a tool only reads data, as untrusted unless the server is trusted.
The list of tools can also differ by caller. The current specification allows a server to return different tools depending on the authorization a request presents, so review the tools each role can actually see.
Treat changes as new decisions
A server can change its tool definitions after you approve it, sometimes called a rug pull. The protocol does not require clients to ask again when a definition changes, so the protection has to come from your client, gateway or process.
Pin what you approved. For local packages, pin the version; with launchers such as npx or uvx that fixes only the top-level package, while a container image pinned by digest fixes the whole dependency tree. For tools, record the reviewed definitions and hold back changed ones until someone reviews them.
Changes on your side count too. New scopes, a new team or a new environment such as production are moments to review the approval again rather than extending it silently.
Contain the servers that run locally
A local server is an ordinary process with the user’s privileges. It can read the files and environment variables that user can read, and connect anywhere on the network. The MCP project calls process isolation the single highest-leverage mitigation.
Set a default posture rather than leaving it to each person: run third-party servers in a container with nothing mounted beyond what they need, give each server only its own narrowly scoped credentials, limit filesystem access and restrict outbound connections. Clients that offer one-click installation must show the exact command before it runs.
Record each approval
An approval that lives in a chat thread is hard to review later. A short record makes the decision explicit and gives the next reviewer something to check against. The example below is illustrative.
Keep the record with the inventory entry, and update it whenever the server, its tools or its credentials change.
| Field | Example |
|---|---|
| Server | Issue tracker, vendor-hosted remote server |
| Owner | Platform engineering lead |
| Approved for | Engineering teams, production workspace |
| Enabled tools | Search issues, read an issue, create an issue |
| Left off | Delete an issue, change project permissions |
| Credential | Each person’s own OAuth grant, limited to issue scopes |
| Conditions | Issue creation reviewed during the first month |
| Next review | In three months, or sooner if tools or scopes change |
Retire servers cleanly
Retiring a server means more than deleting a configuration entry. Remove access for everyone who used it, revoke the credentials it held and remove local configurations where you can. The MCP guidance suggests rotating anything a server held when you remove it.
Keep the history. Records of what the server did remain useful for investigations after it is gone, and a retired server that reappears in an inventory should be treated as a new request.
Where Durin fits
Durin brings remote MCP servers under one governed path. Members can request a connection from the catalog, or propose a custom server with its address and purpose, and an administrator approves or declines the request. Approval does not activate anything on its own: provider setup, tool review, a read-only test and activation still follow.
Each tool is reviewed before it can be used, including whether it reads or changes data and which resources it may touch. Unreviewed tools stay blocked. If a server changes a tool’s definition, the changed tool needs fresh review and earlier approvals for it are revoked. Administrators can scope a connection to teams, or disable an installation while keeping its configuration and history.
For servers outside Durin, Shadow MCP discovery collects reports of MCP servers configured on enrolled devices. Reports are observations, not proof of a current connection, and a review status does not block access. To govern a discovered server, add it through Connections and point clients at Durin.