TL;DR
- An MCP server is a non-human identity with a tool surface. Register it as one, with an owner, an expiry and a recorded reach.
- MCP moved to the Agentic AI Foundation under the Linux Foundation in December 2025, which materially changes its governance risk profile for enterprise buyers.
- The specification mandates OAuth 2.1 with PKCE for protected HTTP deployments. A server using a static token has departed from the specification, not merely from good practice.
- Locally installed servers on developer machines are the hard case and the one carrying the most access.
- Govern the tool surface, not the server. The risk is what its tools can do, and that changes when the server is updated.
Why MCP servers need governance distinct from agent governance
An agent is bounded by what it can reach. An MCP server is reach: it exists to expose tools, data and actions to whatever agent connects. That inversion has three consequences.
- One server can serve many agents, so its scope is the union of every consumer's needs and tends to grow monotonically.
- Its risk changes without your involvement. A server update can add tools, and the tool surface is the risk surface. Nothing in your inventory changes when it does.
- It is frequently third-party code running with credentials you issued, against systems you own. That is a supply-chain position, and it should be governed like one.
Governance status of MCP itself
MCP was contributed to the Agentic AI Foundation under the Linux Foundation in December 2025 and the foundation grew rapidly to a large multi-vendor membership. For enterprise buyers this is the relevant fact: MCP is no longer a protocol a single vendor can deprecate or fork unilaterally. The specification remains actively revised, so pin the version you have assessed and re-assess on change.
Inventory and discovery
Register every MCP server with: a stable identifier, a named individual owner, the systems and data classes its tools can reach split read and write, its provenance (first-party, vendor, or open-source), the specification version assessed, its credential type and expiry, and the agents permitted to connect.
Discovery, as always, is harder than storage. Look for:
- OAuth clients registered against your authorization server that correspond to no known application.
- Outbound connections to MCP endpoints from workloads and from developer subnets.
- Configuration files in repositories declaring MCP server connections, often committed, and a reliable signal.
- Package installs of known MCP server distributions on managed endpoints.
- API gateway consumers whose call patterns match tool invocation rather than application traffic.
An approval model that works
Approval gates fail when they are slower than the workaround. Three tiers keeps the friction proportionate:
| Tier | Server type | Gate |
|---|---|---|
| Self-service | Read-only, non-sensitive data, first-party or vetted list | Register and go. Owner and expiry captured automatically. |
| Review | Writes, or reads sensitive data, or third-party code | Security review of the tool surface and scope, with a recorded decision |
| Restricted | Production write access, financial systems, or customer data egress | Named approver, documented risk acceptance, short credential lifetime, mandatory review interval |
Publish a vetted list. The most effective control here is not a gate but a good default: if there is an approved server that does the job, most people will use it.
Scoping a server
- Scope to the tools actually used, not to the tools offered. Most servers expose more than any given deployment needs, and unused tools are pure risk.
- Separate read servers from write servers where the implementation allows. Two narrowly scoped registrations beat one broad one.
- The server holds its own identity and mints downstream credentials per call. It must never carry a long-lived secret reachable from a context the model can influence. See MCP security on credential injection.
- Log at the tool-call level, recording the invoking agent, the delegating principal and the tool invoked. Server-level logs are not sufficient for an audit question.
- Pin the version. An update that adds tools is a scope change and should re-trigger review.
Locally installed servers, the hard case
A developer installs an MCP server on their machine, points it at a repository or a database, and connects a coding assistant. No OAuth client appears, no procurement record exists, and the access is exactly the developer's own, frequently the broadest access in the organisation.
Prohibition does not work here; the productivity gain is real and the workaround is trivial. What works:
- Provide sanctioned local servers with sensible defaults, so the easy path is the governed one.
- Endpoint inventory of MCP server packages on managed devices, treated as software inventory rather than as a security exception.
- Constrain the credentials, not the tool. If a developer's own database access is scoped and time-bound, an MCP server using it inherits those bounds automatically.
- Make repository-declared connections visible. Configuration in version control is discoverable and is a good proxy for what is running.
Review and retirement
Review by usage and by change: which tools were actually invoked in the last ninety days, and has the tool surface changed since assessment. Both are queries rather than judgements, which is what makes the review survivable at scale.
Retire on the same triggers as any other non-human identity, expiry, disuse, owner departure, system decommission, and when retiring, enumerate what the server created as well as what it was given. See the agent lifecycle.
Frequently asked questions
Who governs the MCP specification?
MCP was contributed to the Agentic AI Foundation under the Linux Foundation in December 2025, and the foundation grew rapidly to a large multi-vendor membership. For enterprise buyers the relevant consequence is that MCP is no longer a protocol a single vendor can deprecate or fork unilaterally. The specification remains actively revised, so pin the version you have assessed and re-assess when it changes.
How should an MCP server be registered?
As a non-human identity with a tool surface: stable identifier, named individual owner, the systems and data classes its tools reach split into read and write, provenance indicating first-party or vendor or open-source, the specification version assessed, credential type and expiry, and which agents may connect. The tool surface is the risk surface, so it belongs in the record rather than only the server name.
How do you discover MCP servers nobody registered?
Look for OAuth clients registered against your authorization server that match no known application, outbound connections to MCP endpoints from workloads and developer subnets, configuration files in repositories declaring MCP connections which are often committed, package installs of known MCP server distributions on managed endpoints, and API gateway consumers whose call patterns look like tool invocation rather than application traffic.
What is the right approval model for MCP servers?
Three tiers proportionate to reach. Self-service registration for read-only access to non-sensitive data from first-party or vetted sources. Security review of the tool surface for anything that writes, reads sensitive data, or runs third-party code. A named approver plus documented risk acceptance and short credential lifetimes for production write access, financial systems or customer data egress. Publishing a vetted list does more than the gate itself.
How do you handle MCP servers developers install locally?
Not by prohibition, since the productivity gain is real and the workaround is trivial. Provide sanctioned local servers with sensible defaults so the easy path is the governed one, inventory MCP packages on managed endpoints as software inventory rather than as a security exception, constrain the underlying credentials so a local server inherits scoped and time-bound access automatically, and make repository-declared connections visible since configuration in version control is discoverable.
Would your agent incident response survive first contact?
Most plans assume a containment capability that has never been exercised. HumanAudit runs agent incident tabletops against real environments, including a measured revocation drill.