MCP Compliance Lives in the Registry You Run.

A property no server can carry

It is tempting to treat MCP compliance as a box on a server's listing, something a vendor attests to and a buyer files. The Model Context Protocol (MCP) offers no such box. Its current specification, the 2026-07-28 revision, says so in one line: "Authorization is OPTIONAL for MCP implementations." The official registry confirms that a server exists and who owns its name. It does not scan what the server does.

So the question has to move to the admitting side of the connection: the decision to admit a server, the identity that decides who may reach it, the token that binds each call to one destination, and the record that can answer for any call afterward. None of those belongs to the server. All of them belong to the enterprise.

In August I argued that MCP is becoming a governance surface: a tool definition is a disclosure, and its description is policy text addressed to a reasoning system. This dispatch asks where MCP governance has to live once you are looking, because neither the protocol, nor the public registries, nor the regulations now approaching will hold it for you.

The protocol sets a ceiling, not a floor

The 2026-07-28 revision is the largest since the protocol launched, and it hardens authorization wherever authorization is used. Clients must validate the issuer parameter defined in RFC 9207 when it is present. Client credentials are bound to the authorization server that issued them. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents.

Every one of those rules governs an implementation that has chosen to implement authorization, and the same specification leaves that choice open. Implementations served over HTTP should conform to the authorization framework; local implementations running over standard input and output should not use the OAuth flow at all, and take their credentials from the environment instead.

Tool annotations follow the same logic. A server can mark a tool read-only or destructive, and the protocol's own blog calls those markings hints, not contracts: "An untrusted server can lie." An annotation can feed a policy engine. It cannot enforce anything.

A specification that makes authorization optional has written a ceiling. The floor is whatever the enterprise decides to enforce.

The registry confirms existence, not trust

The official MCP Registry launched in preview in September 2025 and is still in preview, its API frozen at version 0.1 since October 2025. It hosts metadata pointing to packages on npm, PyPI or Docker Hub, and it verifies that a publisher owns the namespace it claims.

What it does not do is the longer list. It delegates security scanning to the package registries and to downstream aggregators, it does not support private servers, and its codebase is not designed for self-hosting. The intended shape is a chain, in which private sub-registries consume the upstream one and implement the same API. OX Security's count of 15,465 servers across three public registries measures how many servers can be found. It says nothing about how many should be reached.

GitHub has drawn the same line in its own product. Its Copilot policy that restricts users to a private registry is in public preview, GitHub calls it not the recommended method, and it warns that matching by name or ID "can be bypassed by editing configuration files." What GitHub made generally available on 6 August 2026 is different in kind: allowlists and denylists in enterprise managed settings, matched on the server's URL or the command that launches it, which fail closed. Name matching is described as convenience only.

The pattern language I published for production LLM platforms rests on one proposition, the Boundary Invariant: a boundary is a clause the optimizer may not cross, and everything else is optimization. A name match in a catalog is optimization. A fail-closed match on the URL or command that will execute is a boundary, because it still holds after someone edits the file.

So a registry is not a control. It is a catalog, and a catalog becomes governance only when something refuses what it does not list.

The obligations arrive without naming the protocol

Three dates fall in 2027. Colorado's SB26-189, on Automated Decision-Making Technology, takes effect on 1 January and asks for developer documentation, deployer notices, and consumer rights to correction and human review. It says nothing about MCP. OSFI's Guideline E-23 on model risk management takes effect on 1 May; its model definition includes AI and machine learning, and it expects an inventory, lifecycle governance, risk ratings and controls over third-party models. It does not mention agents or tools. In the European Union, the AI Act's high-risk rules, as amended by the Digital Omnibus, apply from 2 December to stand-alone Annex III systems.

The connection between those obligations and an MCP server is my reading, not theirs. What E-23 requires is set out in the guideline; how an institution brings its agents' servers into the inventory it expects is a question of method, and the method that follows is mine.

The reading is not a stretch. An agent's tools are where its outputs become effects, and an inventory that lists the model but omits the servers it can call has recorded the part of the system that thinks and skipped the part that acts.

MCP registry governance starts where the public registry stops

By MCP registry governance I mean one arrangement: the enterprise runs its own registry as the system of record for which servers its agents may reach, at which version, on whose approval, and with what evidence, and enforcement refuses anything that registry does not hold. It is MCP server governance at the only point where it can be enforced, which is admission. Four properties make it hold.

• Admission carries a name. One accountable person accepts a server, never a committee, and the acceptance writes a record: who accepted, on what evidence, when, and under which policy version. That is the gate property of the Five-Gate Deployment Model™, which I specified for AI systems. I apply the same property to the servers those systems call.
• A server someone else operates is a vendor. The questionnaire in the AI Vendor Risk Framework (AVRF)™ was written for third-party AI systems, models and APIs, and its sections on provenance and identity, subprocessors and supply chain, change and notification, and exit and portability carry over to a remote server with little translation. Its section on training data does not.
• The version is part of the approval. Invariant Labs described tool poisoning and the rug pull in April 2025: instructions hidden in tool descriptions, and descriptions that change after approval. The control is to pin the version, hash the reviewed tool definitions, and treat a changed hash as a new admission.
• Enforcement fails closed on what runs. The allowlist matches the URL or the launch command, never the display name, and an unlisted server is refused, not warned about. For local servers, the specification requires a client offering one-click setup to show the exact command and obtain explicit approval.

MCP access governance belongs to the identity provider

Who may reach a server is an identity question, and since 18 June 2026 the protocol has a stable answer. Enterprise-Managed Authorization (EMA), an official extension, makes the enterprise's identity provider (IdP) "the authoritative decision-maker for MCP server access." Its named adopters include Okta as an IdP, Microsoft's VS Code among the clients, and Atlassian, Linear and Supabase among the servers. Revocation happens at the IdP and takes effect immediately across every MCP client.

Access is not a setting on each server. It is a decision the directory already knows how to make. An enterprise that governs application access through role-based access control (RBAC) at its IdP can now put MCP access governance in the same place, and withdraw it from there in one action.

It does not finish the job. Distinct identity for the agent itself, through Workload Identity Federation, DPoP and the IETF's WIMSE work, sits on the protocol's August 2026 roadmap, not in the shipped specification. Until it ships, my reading is that an agent working under an employee's grant is attributable to the employee, not to itself. In the agent authority stack, identity is the first of eleven layers and capability is the fourth. EMA moves the first layer into the right system. It does not yet give the agent a layer of its own.

What MCP token governance means in the specification

The phrase has two meanings in circulation, and only one of them is written into the protocol.

In the specification's sense, MCP token governance is the set of rules that bind each access token to one server. A server must validate that a token was issued for it as the intended audience, under RFC 8707, and servers "MUST NOT accept or transit any other tokens." A client must send the resource parameter, naming the server's canonical URI, in both the authorization and the token request. Tokens travel in the Authorization header, never in a query string. Token passthrough, forwarding a client's token to a downstream API, is named an anti-pattern and forbidden, because it bypasses controls and breaks the audit trail. Scopes start minimal and step up through challenges. Since July, the issuer is bound as well.

Where others see six separate rules, I see one rule written six ways. A token is not a pass. It is the evidence of a single decision about a single destination, and anything that lets it travel further turns that decision into a guess.

The second meaning belongs to gateway vendors: token budgets, spend caps and per-team rate limits, defined by each vendor, not by the specification. The 2026-07-28 revision helps it indirectly, because the new Mcp-Method and Mcp-Name request headers let a gateway route and meter on headers without parsing the message body. An enterprise can cap spend precisely and still accept a token that was never issued for the server receiving it.

A rule in the specification also protects nobody until the library in production implements it. On 28 September 2026 the official MCP Python SDK published advisory GHSA-qx49-fqc8-xw99, rated 7.5: missing issuer verification let a malicious server redirect client secrets, authorization codes and PKCE verifiers. Versions 1.30.0 and 2.2.0 carry the fix. The enterprise's version pin decides whether the July rule is in the client that runs.

Four incidents, four controls

Recent incidents work better as a test than as a catalog. For MCP security governance, the question is which control would have bounded each.

The right-hand column holds the controls already described: admission, identity, token binding, fail-closed enforcement. No server can supply any of them on the enterprise's behalf. The OWASP MCP Top 10, still in beta, lists shadow MCP servers and the lack of audit and telemetry among its ten risks, which are the missing registry and the missing record under other names.

The record that answers for any call

An MCP compliance program is not judged by its policies. It is judged in the past tense. Someone asks what an agent did on a given day, through which server, under whose authority, and the answer is either in a record or it is a reconstruction.

The parts of that record now exist in the protocol. The Mcp-Method and Mcp-Name headers put each request's routing facts where a gateway can record them. Servers are asked to log scope elevation events with correlation IDs. The deprecation of the protocol's own logging feature names OpenTelemetry as a migration path, and trace context can travel in the message metadata. Joined to the IdP decision, the token audience and the admission record, those parts let one call be followed from the person, through the client and the gateway, to the pinned version of the server that answered.

Admission fixes what may be reached. Identity fixes who may reach it. The record fixes what can be proved afterward, and that is the only form in which an enterprise ever answers the compliance question.

An enterprise that can produce that chain for any call has something to show a supervisor, an auditor or its own board. An enterprise that cannot is relying on its servers to behave.

What this is not

None of the frameworks named here is a certification scheme, and conformance with any of them is self-declared. The pairing of each incident with a control is my reading of the published advisories; each advisory names its own fix. The link between the regulations above and MCP is my interpretation.

Chapter 7 of Prompt Systems & Agent Orchestration builds the registry this argument assumes: one catalog of record, exposed to agents over MCP as a filtered view shaped by who is asking, with every access recorded in a chain an auditor can read. If you will use it in your work, ask for a free copy.

Sources

• Model Context Protocol, Versioning and the 2026-07-28 changelog
• Model Context Protocol, Authorization, 2026-07-28 and Security Best Practices, 2026-07-28
• Model Context Protocol blog, the 2026-07-28 release, Tool Annotations, Enterprise-Managed Authorization and the roadmap
• Model Context Protocol, Enterprise-Managed Authorization extension and MCP Registry, About
• GitHub Docs, MCP private registry enforcement, and GitHub Changelog, MCP allowlists in enterprise managed settings, 6 August 2026
• CISA, Seven Known Exploited Vulnerabilities added to the catalog, 2 September 2026
• MCP Python SDK, advisory GHSA-qx49-fqc8-xw99, 28 September 2026
• The Hacker News on nginx-ui, CVE-2026-33032 and postmark-mcp; Knostic on gadgethumans-mcp; Invariant Labs on tool poisoning
• OX Security, 15,465 MCP Servers, 0 Governance; OWASP MCP Top 10
• Colorado General Assembly, SB26-189; OSFI, Guideline E-23; European Commission, AI Omnibus enters into force

© 2026 Nabeel Khan. MCP Compliance: The Enterprise Registry Governance Guide is published under CC BY-NC-ND 4.0. Quote it, cite it, do not repackage it.