Waxell

What Is MCP Governance? (2026 Definition)

MCP governance controls which MCP servers agents reach and what they do there. See what the 2026-07-28 spec revision changed and how to enforce it.

Logan KellyUpdated 14 min read

MCP governance is the set of controls that determine which Model Context Protocol servers an AI agent is allowed to reach, what those servers are allowed to do on the agent's behalf, and what gets recorded when they do it. It is not the protocol itself — MCP defines how an agent and a tool server talk to each other. Governance is the layer that decides whether that conversation should be happening at all, and under what conditions.

That distinction has become urgent for a specific reason: MCP just left its single-vendor phase and entered its infrastructure phase, and the ecosystem it's governing has grown faster than most organizations' ability to track what's connected to what.

The problem MCP governance solves

MCP servers extend an AI agent's reach into calendars, databases, ticketing systems, source control, and internal APIs. Every one of those servers is a new place an agent can read data from or take action against, and most organizations now have more of them than anyone has inventoried. A developer adds a personal MCP server to their coding assistant to save time. A team stands up an internal MCP server for a workflow and forgets to document it. An agent gets pointed at a third-party MCP server whose tool descriptions can change overnight, silently altering what the agent believes it's allowed to do — the failure mode known as an MCP rug pull.

None of that is hypothetical, and there is now a measured version of it. In research published on April 28, 2026, Trend Micro reported that its internet-wide scan found 1,467 MCP servers exposed to the public internet with no client authentication and no traffic encryption — nearly triple the 492 the same team found in its July 2025 scan. Of those, 1,227 were still running the long-deprecated HTTP+SSE transport; 70 exposed an execute_sql tool; and at least three exposed a progress_note feature reaching patient medical records. Separately, Trend Micro's review of more than 19,000 MCP server source repositories found that 48% recommended storing secrets in plaintext.envfiles or JSON configuration. Two command-injection vulnerabilities the team disclosed in a community-maintained aws-mcp-server project — CVE-2026-5058 and CVE-2026-5059, both rated CVSS 9.8 — are, per Trend Micro, in non-official implementations rather than vendor-shipped ones.

Those are scan findings from one research team, not a census. But the shape of the finding is the point: the servers were not compromised through anything exotic. They were reachable, unauthenticated, and unaccounted for. That is the same pattern that made shadow IT a decade-long headache for security teams, except now it's shadow MCP, and the entities using unauthorized tools are autonomous agents that don't ask for permission before they act. The same dynamic played out on a different substrate in the OpenClaw skills-marketplace crisis, covered in depth in our analysis of AI agent supply chain security.

Without governance, an organization typically can't answer three basic questions: which MCP servers exist across the company, which agents are connected to which servers, and what those connections are actually being used to do. MCP governance is the layer built to answer all three.

The analogy: governance is to MCP what identity and access management is to a network

The clearest comparison is enterprise identity and access management. A corporate network doesn't work by trusting every device that connects to it — it authenticates who's connecting, authorizes what they're allowed to touch based on role, and logs what they did for later review. MCP governance applies the same three-part model to agent-to-tool connections specifically: authenticate which agent or user is making a call, authorize which tools and data that identity can reach, and log every call for audit.

The reason this analogy holds better than "MCP governance is just observability" is that IAM isn't optional or after-the-fact — a network without access control isn't a network with weaker security, it's not really controlled at all. The same is true of MCP: a fleet of agents connected directly to MCP servers with no intermediating policy isn't a governed fleet with gaps, it's an ungoverned fleet that happens to work most of the time.

How this applies to AI agents specifically

Agents introduce two problems that traditional IAM was never built to handle. First, an agent's set of available tools can change without a human approving the change — a tool description gets edited on the server side, and the agent picks up new capabilities on its next call. Second, one agent's MCP connections are frequently invisible to the team managing a different agent, even inside the same company, because there's no shared catalog of what's connected to what.

Governing MCP for agents specifically means covering:

  1. Server catalog and discovery — a live inventory of every MCP server in use, sanctioned or not, so "shadow MCP" servers can be found rather than discovered after an incident.
  2. Identity-based access control — every tool call attributable to a specific agent, user, and session, not a shared credential that makes attribution impossible. Scoping matters as much as attribution here; we looked at how often agents exceed the permissions they were granted in our post on AI agent scope violations.
  3. Tool fingerprinting and drift detection — a recorded baseline for what each tool is supposed to do, so a silent change to a tool's description or behavior gets flagged instead of trusted by default.
  4. Prompt injection scanning at the tool boundary — inspection of tool descriptions and results themselves, since injected instructions can arrive through a tool's output, not just a user's prompt.
  5. Human-in-the-loop holds for destructive actions — an approval step for tool calls that write, delete, or send, rather than letting every call execute unattended.
  6. Durable audit logging — a record of every call, allowed or denied, that survives the agent's own memory and holds up for a compliance review. What that record has to contain is its own question, which we worked through in our piece on compliance-grade agent audit trails.
  7. Standards-compliant authentication — remote MCP servers authenticated the way the specification actually requires, not a bespoke workaround per server.

What the 2026-07-28 specification revision changed

The current MCP specification revision is 2026-07-28, and it is a larger change than the version number suggests. Several of its changes are directly load-bearing for anyone building or buying MCP governance.

Authorization remains optional, and that has not changed. The specification states plainly that "Authorization is OPTIONAL for MCP implementations." Implementations on an HTTP-based transport should conform to the authorization spec; implementations on STDIO transport are told the opposite — they should not follow it, and should retrieve credentials from the environment instead.

Once an HTTP-based server does support authorization, the requirements stop being optional. Authorization servers MUST implement OAuth 2.1. MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728), and clients MUST use it for authorization server discovery. Clients MUST implement Resource Indicators for OAuth 2.0 (RFC 8707) and send a resource parameter identifying the target server, and servers MUST validate that a token was issued for them as the intended audience.

Dynamic Client Registration is now formally deprecated. RFC 7591 Dynamic Client Registration has been deprecated as a client registration mechanism in favour of OAuth Client ID Metadata Documents. It is not gone: the spec says it is "retained for backwards compatibility with authorization servers that do not support Client ID Metadata Documents," and the new feature lifecycle policy guarantees a minimum twelve-month deprecation window before anything in the Deprecated state can be removed. Deprecated features still work. New implementations simply shouldn't adopt them.

Client credentials are now explicitly issuer-bound. Clients must key persisted credentials by the issuer identifier, must not reuse them with a different authorization server, and must re-register when the authorization server changes. Authorization servers should include the iss parameter in authorization responses per RFC 9207, and clients must validate a present iss against the recorded issuer before redeeming the code. For anyone running a credential broker on behalf of a fleet of agents, this is a concrete storage and rotation requirement, not a footnote.

Protocol-level sessions are gone. The revision removes the initialize/notifications/initialized handshake and removes protocol-level sessions along with the Mcp-Session-Id header from the Streamable HTTP transport. Servers that need cross-call state now use explicit, server-minted handles passed as ordinary tool arguments. The governance consequence is worth stating: an audit trail can no longer lean on a transport-level session identifier to correlate a series of related tool calls. Correlation has to come from the governance layer's own identity resolution.

server/discoveris now mandatory. Servers MUST implement a server/discover RPC advertising their supported protocol versions, capabilities, and identity. For an inventory-building governance layer, that is a new, standardised place to ask a server what it is — which is exactly the question a catalog needs answered.

Caching results now carry a scope, and one value deserves attention. Results from tools/list, prompts/list, resources/list, resources/read and resources/templates/list must now carry ttlMs and cacheScope. A cacheScope of "public" permits shared intermediaries to cache the response. If a tool list is tenant-specific, marking it public invites a proxy to serve one tenant's tool list to another. That is a governance decision now encoded in a protocol field.

A formal deprecation process now exists. The revision adopts a feature lifecycle policy defining Active, Deprecated and Removed states, a minimum twelve-month deprecation window, and a public registry of deprecated features. Roots, Sampling and Logging are all deprecated under it; the HTTP+SSE transport is reclassified as Deprecated; and all of them remain fully functional during the window. Read against Trend Micro's finding that 1,227 exposed servers were still on HTTP+SSE, the lifecycle policy is the useful half of that story: for the first time, a governance team can put a dated horizon on a transport migration instead of guessing.

The Linux Foundation shift, and why it matters for governance

In December 2025, Anthropic donated the Model Context Protocol to a newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, alongside Block's goose and OpenAI's AGENTS.md as founding contributions. The protocol's legal home is now "Model Context Protocol, a Series of LF Projects, LLC," with contributions licensed under Apache 2.0 and strategic direction set by an AAIF governing board.

Two things changed and one didn't. What changed: MCP is no longer governed by a single vendor's roadmap, which removes the single-vendor risk that made some enterprise architects cautious about standardizing on it — the same path Kubernetes and PyTorch took before wide enterprise adoption. What also changed: the protocol's own internal governance has a documented structure — Maintainers, Core Maintainers, and Lead Maintainers who together form the MCP Steering Group, with decisions and discussion made transparently. What didn't change is the day-to-day decision-making model itself; the foundation move formalized who's accountable, it didn't hand control to a new single party.

The 2026-07-28 revision is the first visible dividend of that for governance teams specifically. Its "Governance and process updates" section adopts the feature lifecycle and deprecation policy described above, and its process changes formalize a PR-based SEP workflow with sponsor responsibilities and status management. Organizational governance of MCP as a project and technical governance of MCP as a deployed protocol in your own environment are two different things, but the first now gives the second something it previously lacked: a published, dated deprecation contract you can plan a migration against.

How Waxell handles this

The Waxell MCP Gateway is built around exactly the shift described above: one governed MCP endpoint per tenant that agents point at, rather than each agent connecting to upstream servers directly. One URL per tenant replaces the per-machine upstream MCP configuration. The scope is worth being precise about — the gateway governs the calls that traverse it. An agent holding direct upstream credentials, or a locally registered MCP server that was never routed through the gateway, is outside that path, which is why catalog and inventory work sits alongside the gateway rather than being replaced by it.

On the rug-pull problem, the mechanic splits into two halves worth keeping separate. Fingerprinting detects: the Gateway hashes every tool it has seen across connected upstreams against its name, description and input schema, and tracks each tool through five trust states — Pending review, Drift detected, Trusted, Blocked, and Removed. A policy decides what happens next. The Gateway's deny_drift policy action blocks tools whose fingerprint changed since they were last approved; it is a rule you author rather than a default, and Waxell's own starter rule set recommends turning it on. A prompt injection scanner runs against tool descriptions at fingerprint time — before any agent calls them — and re-runs on the new description whenever a tool drifts, with findings surfacing unacknowledged until an admin reviews them.

Identity resolution supports per-user OAuth, tenant API keys, service accounts and more, and offboarding revokes a departing user's API keys, sessions and delegations in one action. Policy rule changes take effect across the gateway fleet within seconds, with no restart. Human-in-the-loop approval holds keep destructive actions — writes, deletes, external sends — parked for a person rather than executing unattended, and the gateway holds the connection open with progress notifications so the agent waits rather than timing out. The audit log records who called what tool, which decision applied and which rules fired; it is durable, exportable to CSV, and stores no payloads, with the retention window set by plan rather than fixed. Upstreams are added from a connector catalog; how many any one tenant may connect at once is set by plan.

Waxell Observe complements the Gateway from the code side, for agents written in Python whose process you can install the SDK into: two lines of instrumentation auto-cover 160+ Python libraries, then enforce against 50+ policy categories — so governance applies whether the agent's exposure is coming through an MCP tool call or a direct model call.

FAQ

Is MCP governance the same as an MCP gateway?

Not exactly. A gateway is one common architectural pattern for implementing MCP governance — a single point every tool call routes through, where policy gets enforced. Governance is the broader goal (control, visibility, audit); a gateway is one of the more effective ways to achieve it, because it puts enforcement in the traffic path rather than relying on every individual agent to self-police.

Does the Linux Foundation now control what MCP servers I can build or use?

No. The Linux Foundation and the AAIF govern the specification and the open-source project — how the standard evolves, who has commit access, how disputes get resolved. It has no say over what MCP servers any individual company builds, connects, or governs internally. That remains entirely up to each organization.

Do I need OAuth 2.1 for internal, single-user MCP servers?

The specification still treats authorization as optional, and implementations on STDIO transport are explicitly told not to follow the authorization spec and to retrieve credentials from the environment instead. The OAuth 2.1 requirement binds once an HTTP-based server chooses to support authorization at all — which is effectively every remote server with more than one user. Purely local, single-user servers have more latitude today, but "internal today" often becomes "exposed to more people tomorrow" faster than access controls get revisited, so treating standardized auth as the default even there is the safer bet.

What changed in the 2026-07-28 MCP spec that affects governance?

Four things matter most. Dynamic Client Registration (RFC 7591) is deprecated in favour of Client ID Metadata Documents, though it keeps working through a minimum twelve-month deprecation window. Client credentials are now explicitly bound to the issuing authorization server, so they can't be reused across servers and must be re-registered when the server changes. Protocol-level sessions and the Mcp-Session-Id header are removed, so audit correlation has to come from your governance layer rather than the transport. And a new mandatory server/discover RPC gives an inventory tool a standard way to ask a server what it supports.

What's the actual risk of not governing MCP connections?

The most cited pattern is the MCP rug pull: a tool's description or behavior changes after an agent has already been granted access to it, and the agent — with no mechanism to detect the change — continues trusting a tool that no longer does what it was approved to do. The second most common pattern is simple sprawl: nobody can produce a current list of which MCP servers are connected to which agents, which makes incident response and audit both effectively impossible. Trend Micro's April 2026 scan is the empirical version of the second pattern — 1,467 servers reachable from the open internet with no authentication at all.

How is this different from just reviewing MCP server code before approving it?

Code review catches what a server does at approval time. It doesn't catch what a server does after approval, once its description or behavior changes, or catch a server nobody knew was connected in the first place. Governance has to be continuous and enforced at execution time, not a one-time gate.

Does MCP governance slow down agent development?

Not if it's implemented as infrastructure rather than as a manual approval queue. A gateway-based approach lets developers connect to sanctioned servers instantly while unusual or high-risk calls — new servers, destructive actions — are the only ones that pause for review. The goal is to make the safe path the fast path.

Sources

Ready to see what your agents are actually calling? Start free with the Waxell MCP Gateway — the Free plan includes one governed MCP upstream, which is enough to put a single high-traffic server behind identity resolution, policy and an audit log before you decide how far to take it. Create an account →