MCP Governance Guide: Controls for Servers, Tools, and Access

MCP governance is the operating discipline that decides which servers and tools may exist, who can use them, how a change is approved, and what evidence remains after an action. This guide is for teams that have moved beyond one experimental connector and need a control model that survives new tools, new clients, and staff turnover.

Govern the catalog before clients discover it

Treat the available-server list as a production catalog. Each entry needs a component source, version, transport, tool schema, data classes, downstream systems, business owner, technical owner, and expiry or review date. A server with an unknown owner should not become discoverable merely because a developer can run it locally.

Document the client-server roles using MCP protocol architecture, then add local facts the protocol cannot supply: which tenant can see a tool, which environment it reaches, and what a successful call changes. This turns an inventory into an admission decision instead of a spreadsheet of names.

Freeze the proposed source, version, schema, and permission set before collecting evidence so the review applies to one catalog candidate.

When a catalog entry is a skill, plugin, MCP server, or agent, Deep Scan can add component-admission evidence for the exact version. Confirm the covered artifact in AgentGuard documentation, but leave ownership, permissions, expiry, and downstream effects in the catalog decision.

Bind each tool to identity and capability

Clients, servers, users, and downstream services should not share a generic identity. Make the policy decision at the tool boundary with the caller, tenant, operation, target, and intended effect available to it. A client authorized to search a tenant should not inherit the ability to send mail or alter an account simply because the server also offers those tools.

Credential handling is part of governance, not an implementation footnote. The agent credential leak controls guide helps test whether a connector secret has entered a project file, prompt trace, or support bundle. Revoke a leaked identity before deciding whether the original tool policy was correct.

Treat tool changes as production changes

New arguments can widen a capability as much as a new endpoint can. Require a change record when a tool description, schema, server version, authorization rule, downstream identity, or data destination changes. The record should name the existing control it might weaken and the test that will be repeated.

For example, a search tool that gains an include_content field may need a data-classification test; a billing tool that gains a recipient field may need a destination-approval test. Roll back to the prior catalog revision when the test fails. Do not leave a changed server enabled while the owner decides how to explain it.

Use runtime evidence to find control gaps

Admission evidence says what was reviewed. Runtime evidence says what clients actually selected and whether the policy decision matched the effect. Record tool discovery, selected tool, normalized arguments, decision, downstream identity, and resulting state for consequential actions. Avoid capturing raw sensitive content when metadata is sufficient.

Do not treat the absence of a product observation as a passing runtime result. AgentGuard states that it cannot fully monitor or block all third-party MCP server runtime calls, so the governance record must still reconcile client identity, server policy, downstream authorization, and final state.

Make exceptions short-lived and reviewable

An emergency exception should identify the blocked rule, accountable owner, reason, compensating measure, expiry, and a check that confirms removal. A permanent 'temporary' bypass is a governance failure because later reviewers cannot distinguish an intended capability from an incident workaround.

Review governance with an adversarial case

Choose a controlled server change: a tool description that requests a broader destination, a schema addition that raises effect, or a revoked client identity that attempts discovery. The expected result is not just an alert. The catalog, policy, and target state should agree that the change or request was rejected. The MCP specification and NIST AI RMF are useful references; the proof is the exercised control in your environment.