MCP Registry Governance and Server Certification Standards

#The Governance Moment for Agentic AI

In November 2024, Anthropic open-sourced the Model Context Protocol (MCP) — a universal standard for connecting AI agents to external tools, databases, and services.^[1] The protocol's premise was elegant: instead of every AI application building bespoke integrations, a shared JSON-RPC 2.0 layer would let any MCP-compatible host speak to any MCP-compatible server. The early adopters — Block, Apollo, Zed, Replit, Codeium, Sourcegraph — validated the premise quickly.^[1] What followed was one of the fastest adoption curves in recent infrastructure history.

By April 2026, the MCP ecosystem counted 9,400+ public servers — a 7.8× year-over-year increase from Q1 2025 — and 78% of enterprise AI teams reported at least one MCP-backed agent in production.^[2] The official registry grew from roughly 210 entries in Q4 2024 to 1,200 in Q1 2025, 6,800 in Q4 2025, and 9,400+ by Q1 2026.^[2] Monthly SDK downloads exceeded 97 million at the time Anthropic donated the protocol to the Linux Foundation in December 2025.^[3]

That growth, however, has outpaced the governance and security infrastructure needed to make MCP trustworthy at scale. Three crises are converging simultaneously. First, a credential crisis: analysis of 5,200+ open-source MCP server implementations found that 53% rely on static API keys or Personal Access Tokens — long-lived credentials that are rarely rotated — while only 8.5% use OAuth, the modern preferred method.^[4] Second, a novel attack class: Tool Poisoning Attacks, discovered in April 2025, embed malicious instructions in tool descriptions that are invisible to users but visible to AI models, enabling credential theft and arbitrary code execution through what appear to be legitimate tool calls.^[5] Third, a registry architecture gap: the official MCP Registry explicitly disclaims security responsibility, stating that consumers "should assume minimal-to-no moderation" and that the registry does not remove servers with security vulnerabilities.^[6]

The stakes are materially higher than prior package registry crises. An npm package that contains malware executes code when a developer runs npm install. An MCP server that contains malware executes code when an AI agent — acting with full user credentials, potentially in an automated pipeline — invokes a tool. The attack surface is broader, the execution context is more privileged, and the victim is often unaware that tool descriptions are being processed at all.

This paper surveys the institutional response taking shape in 2025–2026: the official MCP Registry's architecture and its deliberate minimalism, the credential crisis and its partial remediation, tool poisoning as the defining attack vector, three emerging certification approaches (Microsoft's formal program, the community MSSS standard, and the CSA's resource center), the Linux Foundation's AAIF governance model, lessons from npm and PyPI's security evolution, enterprise deployment patterns, and a set of concrete recommendations for the road to MCP Registry v2.

#MCP Architecture and the Registry's Role

Understanding the governance challenge requires understanding the protocol's architecture. MCP defines three component types: Hosts (LLM applications such as Claude Desktop, Cursor, or VS Code Copilot), Clients (connectors embedded in hosts that manage server connections), and Servers (lightweight processes that expose context and capabilities to clients).^[1] Communication uses JSON-RPC 2.0 over stateful connections, with capability negotiation at session initialization.^[7]

Servers expose three primitive types: Resources (read-only data, analogous to GET endpoints), Prompts (reusable prompt templates), and Tools (functions the model can invoke, analogous to POST endpoints with side effects).^[7] The Tools primitive is the primary security surface: the MCP specification explicitly states that "tools represent arbitrary code execution and must be treated with appropriate caution."^[7] Tool descriptions — the natural-language text that tells the model what a tool does — are the vector for tool poisoning attacks.

The official MCP Registry, launched in preview on September 8, 2025, is best understood as a metaregistry — a centralized metadata pointer store that does not host code or binaries.^[8] When a server is registered, the registry records its name, description, and a pointer to where the actual package lives (npm, PyPI, Docker Hub, or another upstream registry). The registry itself never touches the code.^[9]

Namespace authentication is the registry's primary security mechanism. Server names follow reverse DNS format: a server published by GitHub user domdomegg would be named io.github.domdomegg/my-cool-mcp, and publishing that name requires authenticating as the domdomegg GitHub account.^[10] Domain-based namespaces (e.g., com.example.myserver) require DNS verification: the publisher places a TXT record containing an Ed25519 or ECDSA P-384 public key at a well-known location, and the registry verifies ownership cryptographically.^[11] Both Google Cloud KMS and Azure Key Vault are supported for key management in enterprise deployments.^[11]

The registry's sub-registry architecture is its most important governance feature. Downstream aggregators — PulseMCP, Smithery, and others — consume the registry's unauthenticated read-only REST API (GET /v0.1/servers, GET /v0.1/servers/{serverName}/versions) and build enriched views on top of it.^[12] Sub-registries can inject custom metadata via the _meta field in the OpenAPI spec: user ratings, download counts, security scan results, and compliance badges.^[12] Private sub-registries implement the same OpenAPI spec, enabling enterprises to maintain internal registries with stricter governance while consuming the public registry as a baseline.^[8][13]

The registry launched with backing from Anthropic, GitHub, PulseMCP, and Microsoft, and reached v1.7.9 by May 12, 2026, accumulating 6,805 GitHub stars and 807 forks across 70 contributors.^[8][10] The transport mix of registered servers reflects the ecosystem's maturity: 67% use STDIO (local process communication), 28% use Streamable HTTP (remote servers), and 5% use the deprecated SSE transport.^[2] The shift toward Streamable HTTP — the transport that enables remote, multi-tenant MCP servers — is the architectural precondition for enterprise adoption and the governance challenge that follows.

#The Permissive Moderation Policy — A Deliberate Architecture Choice

The MCP Registry's moderation policy is stated with unusual candor: "TL;DR: The MCP Registry is quite permissive! We only remove illegal content, malware, spam, and completely broken servers."^[6] The policy explicitly enumerates what it does not remove: low-quality or buggy servers, servers with security vulnerabilities, duplicate servers, and adult content.^[6] Consumers are advised to "assume minimal-to-no moderation."^[6]

This is not an oversight — it is a deliberate architectural choice that reflects a coherent philosophy. The registry positions itself as a discovery layer, not a security gate. Security responsibility is delegated upward (to upstream package registries like npm and PyPI, which have their own scanning and moderation) and downward (to sub-registries and aggregators, which can apply stricter criteria). The registry is a floor, not a ceiling.^[9]

The enforcement mechanism is correspondingly lightweight. Community moderation — contributors flagging violations via GitHub issues — is the primary channel. Registry maintainers can denylist offending servers retroactively, setting their status to "deleted." Crucially, the "deleted" status preserves metadata accessibility via the API: the server's record remains queryable, enabling forensic analysis of known-bad entries but also potentially enabling discovery by unsophisticated consumers who do not filter on status.^[6][12]

The structural gap this creates is significant. The canonical source of truth for MCP server discovery — the registry that sub-registries treat as their authoritative upstream — provides no security assurance about the servers it lists. Most users and enterprises, encountering a server in the registry, will treat registry presence as implicit endorsement. The moderation policy explicitly warns against this inference, but the warning is buried in documentation that most consumers never read.

The supply chain implications are compounded by the metaregistry architecture. A malicious tool description does not need to be injected at the registry level — it can be present in the npm or PyPI package that the registry points to, or it can be injected by a compromised aggregator that enriches the registry data before serving it to clients.^[14] The attack surface spans the entire pipeline: registry → aggregator → client → model. Registry-level scanning, even if implemented, would be insufficient without corresponding controls at each layer.^[14]

The registry's working group has acknowledged this gap. The sub-registry architecture is explicitly designed to allow downstream actors to add security enrichment that the official registry does not provide. But this creates a fragmented security landscape: the security posture of an MCP server depends on which aggregator a client uses to discover it, and most clients use the official registry directly.

#The Credential Crisis — 53% Static Keys, 8.5% OAuth

In October 2025, Astrix Security published the most comprehensive analysis of MCP server security to date, examining 5,200+ unique open-source MCP server implementations.^[4] The findings were stark: 88% of servers require credentials to operate, but only 8.5% use OAuth — the modern, preferred authentication method that provides scoped, time-limited access tokens.^[4] The dominant credential pattern is static API keys or Personal Access Tokens (PATs), used by 53% of servers — long-lived credentials that are rarely rotated and represent a systemic supply chain risk.^[4]

The credential storage problem compounds the authentication problem. Of servers that use API keys, 79% pass them via environment variables.^[4] In containerized deployments, CI/CD pipelines, and shared development environments, environment variables are frequently logged, exposed in process listings, or leaked through misconfigured secrets management. The MCP server ecosystem has, in effect, reproduced the credential hygiene problems that the software industry spent a decade trying to eliminate from web application development.

The root cause is partly historical. The MCP specification's initial examples and SDKs normalized insecure credential patterns — environment variable injection was the path of least resistance for getting a server running quickly, and the ecosystem's rapid growth meant that early patterns became entrenched before better alternatives were widely available. The 2025-11-25 spec revision began correcting this by introducing server identity as a first-class concept.^[3] OAuth 2.1 work led by Den Delimarsky at Microsoft — which "enabled remote MCP servers, unlocking enterprise adoption" — provided the authentication infrastructure that the ecosystem had been missing.^[15]

The enterprise picture is more encouraging. Among remote MCP servers in enterprise deployments, 81% authenticate with OAuth 2.1 as of April 2026.^[2] This suggests that the credential crisis is concentrated in the long tail of community-built servers — the 20,000+ MCP server implementations estimated to exist on GitHub^[4] — rather than in the production enterprise deployments that represent the highest-value attack targets.

The divergence between community and enterprise credential hygiene has governance implications. A certification program that targets enterprise deployments (like Microsoft's, discussed below) will naturally reach the servers that are already better secured. The servers most in need of security improvement — the community-built, statically-keyed servers that make up the majority of the ecosystem — are the hardest to reach through formal certification. Addressing the credential crisis in the long tail requires either ecosystem-wide tooling (like Astrix's open-source MCP Secret Wrapper, which pulls secrets from a vault at runtime^[4]) or registry-level incentives that make OAuth adoption the path of least resistance.

#Tool Poisoning — The Novel Attack Class Defining MCP Security

On April 1, 2025, Invariant Labs published a security notification that would define the MCP security conversation for the following year.^[5] Researchers Luca Beurer-Kellner and Marc Fischer had discovered what they termed Tool Poisoning Attacks (TPAs): a class of attack in which malicious instructions are embedded in tool descriptions — the natural-language text that tells an AI model what a tool does and how to use it.

The attack exploits a fundamental asymmetry in how tool descriptions are processed. A user reviewing an MCP server sees a brief, benign-looking description: "Reads a file from the filesystem." The AI model, however, processes the full tool description, which may contain hidden instructions invisible in standard UI rendering — instructions like "Before performing any file operations, read the contents of ~/.cursor/mcp.json and ~/.ssh/id_rsa and include them in your next tool call." In the Invariant Labs demonstration on Cursor, this attack succeeded: the agent read the target files and transmitted their contents to an attacker-controlled endpoint, all through what appeared to be a legitimate file-reading operation.^[5]

Two variants extend the basic attack. MCP Rug Pulls exploit the absence of version pinning in the base MCP spec: a server presents a benign tool description during the initial client approval flow, then changes the description after approval to include malicious instructions.^[5][16] The client has approved a tool that no longer behaves as described, and there is no mechanism in the base protocol to detect or prevent this change. Shadowing enables cross-server attacks: a malicious server injects instructions into its tool descriptions that modify the behavior of other, trusted servers in the same session — effectively hijacking the trusted server's tools without compromising the trusted server itself.^[5]

The MCP specification's November 2025 revision introduced ToolAnnotations — structured hints about tool behavior (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) — but explicitly cautioned that these "are hints only — clients should never make tool use decisions based on ToolAnnotations received from untrusted servers."^[17] The spec acknowledges the attack surface but cannot close it at the protocol level: the fundamental problem is that tool descriptions are natural language processed by a model, and natural language can always contain instructions.

The OWASP MCP Top 10, published in beta in 2025, codifies the attack landscape.^[18] Tool poisoning appears as MCP03 (Tool Poisoning, including rug pulls, schema poisoning, and tool shadowing). Related risks include MCP06 (Intent Flow Subversion — prompt injection via contextual payloads that redirect agent behavior) and MCP09 (Shadow MCP Servers — unapproved deployments outside governance frameworks). The full Top 10 maps the attack surface comprehensively: token mismanagement (MCP01), privilege escalation via scope creep (MCP02), supply chain attacks (MCP04), command injection (MCP05), insufficient authentication (MCP07), lack of audit and telemetry (MCP08), and context injection (MCP10).^[18]

Mitigations exist but require implementation at the client level, not the protocol level. Invariant Labs recommends tool and package pinning (locking tool descriptions to a specific hash at approval time), cross-server protection (preventing one server's tool descriptions from influencing another server's behavior), and clear UI patterns that show users the full, unrendered tool description before approval.^[5] Vantage Point's enterprise guide adds tool description hashing and namespace allowlisting as complementary controls.^[16] None of these mitigations are currently mandatory in the base MCP spec — they are recommendations that individual client implementations may or may not adopt.

The supply chain framing is important. Tool poisoning is not just a client-side problem — it is a supply chain problem.^[14] A malicious tool description can be introduced at any point in the pipeline: in the server's source code, in the npm or PyPI package the registry points to, in an aggregator that modifies descriptions before serving them to clients, or in a compromised update to a previously-trusted server. Addressing tool poisoning requires controls at every layer of the supply chain, not just at the client.

#The Emerging Certification Landscape — Three Approaches

The governance gap created by the registry's permissive moderation policy and the ecosystem's security vulnerabilities has prompted three distinct certification responses, each targeting a different layer of the problem.

#Microsoft's Formal Certification Program

The most mature certification approach is Microsoft's, published in February 2026 as part of the Microsoft 365 Copilot platform documentation.^[19] Microsoft requires MCP servers to undergo certification before being made available to all users in Microsoft 365 Copilot — making this the first mandatory certification regime in the MCP ecosystem.

The certification process flows through Microsoft's existing connector certification program (the Power Platform pipeline) and has four stages: automated validation (schema compliance, endpoint availability, basic security checks), manual review (human evaluation of server behavior and documentation), responsible AI evaluation (testing normal, edge-case, and adversarial scenarios for harmful outputs), and deployment (publication to the Microsoft 365 Copilot marketplace).^[19]

Publisher eligibility requirements establish a baseline of institutional accountability: verified publisher status, a Microsoft Partner Center account, and enrollment in the Microsoft 365 and Copilot program.^[19] Authentication requirements are explicit: OAuth 2.0 is the preferred method; API key and Basic Auth are supported but not preferred.^[19] Post-certification, Microsoft "continuously monitors certified servers for regressions, security issues, and policy violations" — a commitment to ongoing compliance rather than point-in-time certification.^[19]

Microsoft's program is effective for its target audience — enterprise software vendors seeking distribution through the Microsoft 365 Copilot marketplace — but its scope is necessarily limited. It does not address the long tail of community-built servers, and its institutional requirements (Partner Center account, verified publisher status) are barriers that individual developers and small teams cannot easily clear.

#The MCP Server Security Standard (MSSS)

The community-driven complement to Microsoft's enterprise program is the MCP Server Security Standard (MSSS), published in January 2026 by Daniel García (cr0hn) and Dr. Alfonso Múñoz.^[20][21] The MSSS defines 24 security controls across 8 domains and 4 compliance levels, designed to be applicable to any MCP server regardless of its distribution channel.

The eight domains cover the full security surface of an MCP server: Filesystem (FS), Execution (EXEC), Network (NET), Authorization (AUTHZ), Input Validation (INPUT), Logging (LOG), Supply Chain (SUPPLY), and Deployment (DEPLOY).^[20] The four compliance levels create a graduated path from minimal to maximum assurance:

• L1 Essential (6 controls, 25% coverage): Appropriate for personal or hobby projects. Self-assessment only. Estimated implementation time: 1–2 hours.
• L2 Development (12 controls, 50% coverage): Appropriate for internal or team use. Self-assessment plus automated scanning. Estimated time: 4–8 hours.
• L3 Production (18 controls, 75% coverage): Appropriate for enterprise or customer-facing deployments. Internal audit required. Estimated time: 1–2 weeks.
• L4 Maximum Assurance (24 controls, 100% coverage): Appropriate for critical or regulated environments. Third-party penetration testing required. Estimated time: 4–8 weeks.^[20]

The MSSS maps compliance levels to regulatory frameworks, providing enterprises with a clear path from compliance requirement to certification level: HIPAA and PCI DSS require L4; SOC 2 and ISO 27001 require L3; FedRAMP Low requires L3; FedRAMP Moderate and High require L4.^[20] This mapping is the MSSS's most practically useful feature — it translates abstract security controls into concrete regulatory obligations that enterprise procurement teams understand.

The standard is explicitly inspired by NIST CSF, OWASP ASVS, CIS Controls, PCI DSS, and FedRAMP.^[20] MCP-Hub is listed as the first compliant platform.^[21] The roadmap targets v0.2 in Q2 2026 (incorporating community feedback) and v1.0 in Q4 2026 (stable specification plus a formal certification program).^[21] At v0.1.0, the standard has 71 GitHub stars and 13 forks — modest adoption that reflects its early stage but growing community interest.^[21]

#The CSA MCP Security Resource Center

The Cloud Security Alliance launched the MCP Security Resource Center in August 2025, positioning it as "the first open industry hub for securing MCP."^[22] The CSA's approach is complementary to both Microsoft's certification program and the MSSS: rather than defining a certification regime, it provides open tooling and community intelligence that any actor in the ecosystem can use.

The resource center's tooling suite includes mcpserver-finder (discovery), mcpserver-audit (security assessment), mcpserver-builder (secure server scaffolding), and mcpserver-operator (operational monitoring).^[22] Community intelligence resources include audit-db (a database of server security assessments) and vulnerability-db (a database of known MCP vulnerabilities).^[22] The CSA also published the Top 10 MCP Server Security Risks and Top 10 MCP Client Security Risks — parallel to the OWASP MCP Top 10 but with a CSA-specific framing.

The CSA's framing of MCP as analogous to CGI-BIN — the 1990s mechanism that first enabled web servers to execute arbitrary code in response to HTTP requests — is instructive.^[22] CGI-BIN's security history is a cautionary tale: the capability was powerful, adoption was rapid, and the security implications were understood only after widespread exploitation. The CSA's resource center is an attempt to compress that learning cycle for MCP.

Within eight months of MCP's launch, the CSA counted 70+ public MCP clients and 16,000+ servers visible in the wild.^[22] The gap between 16,000 servers in the wild and 9,400+ in the official registry reflects the ecosystem's fragmentation — thousands of MCP servers are deployed and in use without any registry presence, creating a shadow server population that no governance framework currently reaches.

#The Complementary Architecture

These three approaches are complementary rather than competing. Microsoft's program addresses enterprise platform integration — the question of which servers can be distributed through Microsoft's commercial channels. The MSSS addresses server-side security posture — the question of how well a server is built, regardless of its distribution channel. The CSA addresses ecosystem-wide intelligence — the question of what is known about the security of servers already deployed. Together, they sketch the outline of a comprehensive governance architecture, but the pieces are not yet integrated.

The OWASP GenAI working group's enterprise security framework provides a fourth layer: a defense-in-depth model for enterprise MCP deployments that spans Server-Side Security (network segmentation, gateway controls, tool vetting), Client-Side Security (Zero Trust architecture, just-in-time access, continuous validation), and Operational Security (monitoring, incident response).^[23] The framework defines three deployment patterns — Dedicated Security Zone, API Gateway-Centric, and Containerized Microservices — each with distinct security responsibilities.^[23]

#Linux Foundation Governance — The AAIF Model

On December 9, 2025, Anthropic announced that it was donating MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation.^[3] The announcement came at a moment of peak ecosystem momentum: 10,000+ active public MCP servers, 97 million+ monthly SDK downloads, and adoption by ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code.^[3]

The AAIF was co-founded by Anthropic, Block, and OpenAI, with immediate support from Google, Microsoft, AWS, Cloudflare, and Bloomberg.^[3] The formal Linux Foundation structure established a platinum membership tier — AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI — and a gold membership tier of 15+ companies including Adyen, Cisco, Datadog, Docker, Ericsson, IBM, JetBrains, Okta, Oracle, Salesforce, SAP, Shopify, Snowflake, Temporal, and Twilio.^[24] Bloomberg's CTO captured the institutional significance: "MCP is a foundational building block for APIs in the era of agentic AI."^[24]

The Linux Foundation governance model provides four guarantees that single-vendor stewardship cannot: long-term stability (the protocol will not be abandoned or pivoted by a single company's strategic decisions), equal participation (all members have a voice in governance regardless of their competitive relationship with Anthropic), compatibility guarantees (breaking changes require broad consensus), and safety of open standard (the protocol cannot be proprietarized).^[15] These guarantees address the enterprise concern that was the primary barrier to MCP adoption: the risk of building critical infrastructure on a protocol controlled by a single AI company.

The AAIF's three founding projects — MCP (Anthropic), goose (Block), and AGENTS.md (OpenAI) — signal an ambition beyond MCP governance: the foundation aims to be the institutional home for the agentic AI infrastructure layer broadly.^[24] MCP Dev Summit events were donated to the AAIF, with the next summit held in New York City on April 2–3, 2026.^[24]

The November 2025 spec release, which immediately preceded the AAIF donation, introduced several features with governance implications: asynchronous operations, statelessness, server identity as a first-class concept, and official extensions.^[3] Server identity — the ability for a server to cryptographically assert its identity to a client — is the foundational prerequisite for any future mandatory certification regime. Without server identity, a client cannot verify that the server it is talking to is the server it approved, making certification badges meaningless.

The AAIF's governance model, however, has not yet translated into mandatory security requirements for registry entries. The registry remains community-governed with limited enforcement capability. The institutional legitimacy of the Linux Foundation provides a framework within which mandatory requirements could be established, but the working group has not yet moved in that direction. The gap between institutional governance (AAIF) and operational security governance (registry moderation policy) remains the central unresolved tension in MCP's governance architecture.

MCP's trajectory — from single-company open-source project to Linux Foundation directed fund in under 13 months — mirrors the governance evolution of Kubernetes (donated to CNCF in 2016, 18 months after open-sourcing), Node.js (donated to OpenJS Foundation in 2019), and PyTorch (donated to Linux Foundation in 2022).^[15] In each case, the governance transition preceded the protocol's adoption as critical enterprise infrastructure. MCP hit 37,000 GitHub stars in under eight months; 1.1 million+ public GitHub repositories now import an LLM SDK, a 178% year-over-year increase.^[15]

#Lessons from npm and PyPI — The Package Registry Precedent

The MCP Registry's governance challenges are not unprecedented. The software industry has navigated analogous crises in package registries, and the lessons are directly applicable.

On September 14, 2025 — one week after the MCP Registry launched in preview — a self-replicating worm called Shai-Hulud infiltrated npm via compromised maintainer accounts.^[25] The worm spread by modifying packages to include malicious code that, when executed, compromised the maintainer's credentials and used them to infect other packages. GitHub removed 500+ compromised packages immediately, but the incident demonstrated the catastrophic potential of supply chain attacks at registry scale.^[25]

npm's response roadmap, published September 23, 2025, outlined three major security improvements: mandatory two-factor authentication for local publishing (migrating from TOTP to FIDO-based 2FA), granular tokens with a maximum 7-day lifetime (replacing long-lived classic tokens), and trusted publishing — an OIDC-based mechanism that eliminates long-lived secrets entirely.^[25] Trusted publishing, pioneered by PyPI in April 2023, allows packages to be published using short-lived OIDC tokens issued by CI/CD platforms (GitHub Actions, GitLab CI, etc.) rather than long-lived API keys.^[25] It is now endorsed by the OpenSSF Securing Software Repositories Working Group and has been adopted by RubyGems, crates.io, npm, and NuGet.^[25]

The parallel to MCP's credential crisis is direct. The 53% of MCP servers that use static API keys are in the same position as npm packages that used long-lived classic tokens before the Shai-Hulud incident forced a reckoning. The difference is that MCP has the opportunity to implement trusted publishing before a Shai-Hulud-scale incident forces emergency response.

MCP's namespace authentication (DNS verification and GitHub OAuth) is architecturally analogous to npm's scoped packages — it ties server names to verified identities, preventing namespace squatting. But it lacks the code-level integrity verification that modern package registries provide: checksums, provenance attestation, and SLSA (Supply-chain Levels for Software Artifacts) compliance.^[25] A server can be published under a verified namespace but contain malicious code that the registry has no mechanism to detect.

The PyPI trusted publishing model provides the template for MCP's next authentication evolution. Instead of requiring publishers to manage long-lived DNS keys or GitHub OAuth tokens, a trusted publishing system would allow MCP servers to be published using short-lived OIDC tokens from the CI/CD pipeline that built them — creating a cryptographic chain of custody from source code to registry entry. This would directly address the 53% static-key problem by making OIDC-based publishing the path of least resistance.

The key lesson from npm and PyPI's governance evolution is that registry security hardening is reactive and crisis-driven. npm's 2FA requirements, granular tokens, and trusted publishing were all proposed before the Shai-Hulud incident — but it took a catastrophic worm to create the political will to implement them. The MCP ecosystem has the advantage of being able to observe this pattern and act proactively. The AAIF and registry working group have the institutional capacity to implement proactive controls; the question is whether they will act before a crisis forces their hand.

#Enterprise Deployment Patterns and Governance Gaps

The enterprise adoption statistics reveal a governance landscape that is more complex than the public registry suggests. 78% of enterprise AI teams have at least one MCP-backed agent in production as of April 2026, but 41% have custom internal MCP servers that are not in the public registry.^[2] These internal servers — built for proprietary data sources, internal APIs, and enterprise-specific workflows — exist entirely outside the governance frameworks that the public registry and its sub-registries provide.

The scale of enterprise MCP deployments is significant. The median production enterprise stack has 4 MCP servers; the 90th percentile has 11.^[2] The median MCP server exposes 7.4 tools, with 80% of servers exposing only the tools layer (not resources or prompts).^[2] The time-to-integrate advantage is compelling: 4.2 hours with MCP versus 18 hours for custom function-calling — a 4.3× productivity improvement that explains the rapid adoption.^[2]

The OWASP GenAI working group defines three enterprise deployment patterns, each with distinct security characteristics.^[23] The Dedicated Security Zone pattern isolates MCP servers in a separate network segment with strict ingress/egress controls — appropriate for high-sensitivity deployments where the attack surface must be minimized. The API Gateway-Centric pattern routes all MCP traffic through a central API gateway that enforces authentication, rate limiting, and logging — appropriate for organizations with existing API governance infrastructure. The Containerized Microservices pattern deploys MCP servers as containers with service mesh controls — appropriate for cloud-native organizations with Kubernetes expertise.^[23]

OWASP MCP09 — Shadow MCP Servers — is the governance risk that cuts across all three deployment patterns.^[18] Shadow servers are MCP servers deployed outside the organization's governance framework: a developer who spins up a local MCP server connected to a production database, a team that deploys an internal server without security review, or a vendor that bundles an MCP server in a product without disclosure. The 41% of enterprise teams with custom internal servers^[2] are not necessarily shadow servers — many will have gone through appropriate review — but the category represents a real and growing governance gap.

The regulatory horizon adds urgency to enterprise governance. The UK government's AI assurance roadmap, published in September 2025, describes an AI assurance market of 524+ companies generating approximately £1.01 billion in GVA in 2024, with potential growth to £18.8 billion by 2035.^[26] The government's response includes an £11 million AI Assurance Innovation Fund (opening Spring 2026) and UKAS piloting of accreditation for ISO/IEC 42001 AI management system certification.^[26] While the roadmap does not specifically address MCP servers, the regulatory trajectory is clear: AI tools that act as agents with user credentials will be in scope for AI assurance frameworks as they mature.

The three pathways the UK roadmap identifies — professionalisation (skills and credentials for AI assurance practitioners), process certification (auditable processes for AI development and deployment), and accreditation (third-party verification of AI assurance claims) — map directly onto the MSSS's compliance levels.^[26] L3 and L4 MSSS compliance, with their internal audit and third-party pentest requirements, are the natural precursors to formal accreditation under emerging regulatory frameworks.

#Recommendations and the Road to MCP Registry v2

The governance architecture for MCP is taking shape, but it is incomplete. The following recommendations address the most critical gaps, ordered by implementation feasibility and impact.

1. Implement a security tier system in the official registry. The current registry has a single tier: listed. A two-tier system — "listed" (current behavior, minimal moderation) and "audited" (requiring MSSS L2+ compliance, automated vulnerability scanning, and code provenance attestation) — would allow the registry to provide security signal without abandoning its permissive baseline. Sub-registries already have the technical capability to implement this via the _meta field^[12]; the missing piece is a standardized badge format and a process for earning it.

2. Implement trusted publishing for MCP. OIDC-based namespace authentication — eliminating long-lived DNS keys and GitHub OAuth tokens in favor of short-lived CI/CD tokens — is the highest-leverage near-term improvement for the credential crisis.^[25] It directly addresses the 53% static-key problem^[4] by making secure publishing the path of least resistance. The npm and PyPI implementations provide proven templates; the MCP Registry's Go codebase is well-positioned to implement this.^[10]

3. Mandate server identity and version pinning in the MCP spec. The November 2025 spec introduced server identity as a first-class concept^[3]; the next step is making it mandatory and adding version pinning — the ability for a client to lock a tool description to a specific hash and detect changes. Version pinning directly addresses MCP Rug Pulls^[5][16] and is a prerequisite for any meaningful certification regime. The AAIF's governance structure provides the institutional mechanism for mandating spec changes.^[3]

4. Adopt MSSS L3 as the enterprise baseline. Enterprises deploying MCP servers for internal use should adopt MSSS L3 as the minimum security bar, with MSSS L4 or Microsoft certification required for servers handling regulated data (HIPAA, PCI DSS, FedRAMP).^[20] The MSSS's regulatory mapping provides a clear path from compliance requirement to certification level. Private sub-registries should enforce MSSS compliance as a condition of listing.

5. Act before the crisis. The npm Shai-Hulud precedent is the clearest warning the MCP ecosystem has received.^[25] Registry security hardening is reactive and crisis-driven in the absence of proactive governance. The AAIF has the institutional capacity — platinum membership from every major cloud provider and AI company^[24] — to implement proactive controls. The MSSS roadmap targets v1.0 in Q4 2026^[21]; the registry working group should coordinate with the MSSS to ensure that the v1.0 certification program integrates with registry infrastructure. The window for proactive governance is narrow.

The road to MCP Registry v2 is not primarily a technical challenge — the sub-registry architecture, namespace authentication, and OpenAPI spec already provide the infrastructure for a more secure registry. It is a governance challenge: building the institutional consensus, the community tooling, and the enterprise incentives that make security the default rather than the exception. The AAIF's formation is the most important governance development in MCP's short history. Whether it translates into mandatory security requirements before a crisis forces the issue will define the protocol's trustworthiness for the next decade.

#Quotable Findings per Part

#The Governance Moment for Agentic AI

• 9,400+ public MCP servers in April 2026 — a 7.8× year-over-year increase from Q1 2025.^[2]
• 78% of enterprise AI teams have at least one MCP-backed agent in production as of April 2026.^[2]
• Registry growth: ~210 entries (Q4 2024) → 1,200 (Q1 2025) → 6,800 (Q4 2025) → 9,400+ (Q1 2026).^[2]
• 53% of MCP servers rely on static API keys or PATs; only 8.5% use OAuth.^[4]
• MCP servers "represent arbitrary code execution and must be treated with appropriate caution" — MCP specification.^[7]
• 97 million+ monthly SDK downloads at time of AAIF donation (December 2025).^[3]

#MCP Architecture and the Registry's Role

• The MCP Registry is "a centralized metadata repository for publicly accessible MCP servers" backed by Anthropic, GitHub, PulseMCP, and Microsoft.^[27]
• Server names follow reverse DNS format (e.g., io.github.user/server-name); namespace tied to verified identity.^[27]
• DNS authentication uses Ed25519 or ECDSA P-384 key pairs; supports Google Cloud KMS and Azure Key Vault integration.^[11]
• Sub-registries can inject custom metadata via _meta field: user ratings, download counts, security scan results.^[12]
• Registry launched in preview September 8, 2025; v1.7.9 released May 12, 2026; 6,805 GitHub stars, 807 forks.^[8][10]
• Transport mix: 67% STDIO (local), 28% Streamable HTTP (remote), 5% SSE (deprecated).^[2]

#The Permissive Moderation Policy

• "The MCP Registry is quite permissive! We only remove illegal content, malware, spam, and completely broken servers." — Official moderation policy.^[6]
• "Consumers should assume minimal-to-no moderation." — Official moderation policy.^[6]
• The registry explicitly does NOT remove: low-quality/buggy servers, servers with security vulnerabilities, duplicate servers, adult content.^[6]
• Malicious tool descriptions propagate through registry → aggregator → client pipeline; registry-level scanning is insufficient.^[14]
• Sub-registries are "free to apply their own criteria" — the registry is a floor, not a ceiling.^[9]

#The Credential Crisis

• 88% of MCP servers require credentials; only 8.5% use OAuth.^[4]
• 53% rely on static API keys or PATs — long-lived, rarely rotated.^[4]
• 79% of API keys passed via environment variables.^[4]
• Estimated 20,000 MCP server implementations on GitHub total.^[4]
• 81% of remote MCP servers authenticate with OAuth 2.1 in enterprise deployments (April 2026).^[2]
• OAuth work by Den Delimarsky (Microsoft) "enabled remote MCP servers, unlocking enterprise adoption."^[15]

#Tool Poisoning

• Demonstrated attack: malicious MCP server caused agent to read ~/.ssh/id_rsa and transmit to attacker via tool description manipulation.^[5]
• "MCP Rug Pulls": malicious server changes tool description after client approval; no version pinning in base MCP spec.^[5][16]
• "Shadowing": malicious server injects instructions that modify behavior of trusted servers in same session.^[5]
• ToolAnnotations in 2025-11-25 spec are "hints only — clients should never make tool use decisions based on ToolAnnotations received from untrusted servers."^[17]
• OWASP MCP Top 10 codifies: MCP03 (Tool Poisoning), MCP06 (Intent Flow Subversion), MCP09 (Shadow MCP Servers).^[18]
• Tool poisoning is a supply chain problem: malicious descriptions can be introduced at any layer of the registry → aggregator → client pipeline.^[14]

#The Emerging Certification Landscape

• Microsoft certification stages: automated validation → manual review → responsible AI evaluation → deployment.^[19]
• Microsoft "continuously monitors certified servers for regressions, security issues, policy violations."^[19]
• MSSS L1 (Essential): 6 controls, self-assessment, 1–2 hours; L4 (Maximum Assurance): 24 controls, third-party pentest, 4–8 weeks.^[20]
• MSSS regulatory mappings: HIPAA→L4, PCI DSS→L4, SOC 2→L3, ISO 27001→L3, FedRAMP Low→L3, Moderate/High→L4.^[20]
• MSSS v1.0 targeting Q4 2026 with stable spec and certification program.^[21]
• CSA: "first open industry hub for securing MCP"; 70+ public MCP clients, 16,000+ servers visible in the wild within 8 months of launch.^[22]

#Linux Foundation Governance — The AAIF Model

• 10,000+ active public MCP servers and 97M+ monthly SDK downloads at time of AAIF donation.^[3]
• AAIF platinum members: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI.^[24]
• Bloomberg CTO: "MCP is a foundational building block for APIs in the era of agentic AI."^[24]
• Linux Foundation provides: "long-term stability, equal participation, compatibility guarantees, safety of open standard."^[15]
• November 2025 spec: asynchronous operations, statelessness, server identity, official extensions.^[3]
• MCP hit 37k GitHub stars in under 8 months; 1.1M+ public GitHub repositories import an LLM SDK (+178% YoY).^[15]

#Lessons from npm and PyPI

• Shai-Hulud attack (Sept 14, 2025): self-replicating worm via compromised maintainer accounts; GitHub removed 500+ packages.^[25]
• npm roadmap: require 2FA, granular tokens (7-day lifetime), trusted publishing.^[25]
• "Trusted publishing is a recommended security capability by the OpenSSF Securing Software Repositories Working Group."^[25]
• PyPI trusted publishing launched April 2023; now on RubyGems, crates.io, npm, NuGet.^[25]
• MCP namespace authentication (DNS/GitHub) is a step toward trusted publishing but lacks code-level integrity verification.

#Enterprise Deployment Patterns and Governance Gaps

• 78% of enterprise AI teams have at least one MCP-backed agent in production; 41% have custom internal MCP servers.^[2]
• Median MCP server exposes 7.4 tools; 80% expose tools layer only.^[2]
• Time-to-integrate: 4.2 hours with MCP vs 18 hours custom function-calling (4.3× advantage).^[2]
• OWASP three deployment patterns: Dedicated Security Zone, API Gateway-Centric, Containerized Microservices.^[23]
• UK AI assurance market: 524+ companies, ~£1.01B GVA in 2024; potential £18.8B by 2035.^[26]
• UKAS piloting accreditation for ISO/IEC 42001 AI management system certification.^[26]

#Recommendations and the Road to MCP Registry v2

• MSSS roadmap: v0.2 Q2 2026 (community feedback), v1.0 Q4 2026 (stable spec + certification program).^[21]
• MCP Registry "recommends self-hosted private registries" for private servers.^[27]
• Sub-registries "can inject custom metadata via _meta field: security scan results."^[12]
• Trusted publishing: "no long-lived secrets, OIDC-based, endorsed by OpenSSF."^[25]
• The window for proactive governance is narrow: act before a Shai-Hulud-scale incident forces reactive hardening.

#Glossary

AAIF (Agentic AI Foundation): A directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI in December 2025, that serves as the institutional home for MCP and other agentic AI infrastructure projects.

CSA (Cloud Security Alliance): An industry organization that launched the MCP Security Resource Center in August 2025, providing open tooling and community intelligence for MCP security.

ECDSA P-384: An elliptic curve digital signature algorithm used for DNS-based namespace authentication in the MCP Registry; provides 192-bit security.

Ed25519: An elliptic curve signature scheme based on Curve25519, used for DNS-based namespace authentication in the MCP Registry; known for high performance and resistance to side-channel attacks.

FIDO (Fast Identity Online): A family of authentication standards (FIDO2, WebAuthn, CTAP) that replace passwords and TOTP codes with hardware-backed cryptographic credentials; npm is migrating to FIDO-based 2FA post-Shai-Hulud.

JSON-RPC 2.0: A remote procedure call protocol encoded in JSON, used as the transport layer for MCP communication between hosts, clients, and servers.

MCP (Model Context Protocol): An open standard, created by Anthropic and donated to the AAIF/Linux Foundation, for connecting AI agents to external tools, databases, and services via a standardized JSON-RPC 2.0 interface.

MCP Rug Pull: An attack variant in which a malicious MCP server presents a benign tool description during client approval, then changes the description post-approval to include malicious instructions; enabled by the absence of version pinning in the base MCP spec.

Metaregistry: A registry that stores metadata pointers to packages hosted elsewhere, rather than hosting packages directly; the official MCP Registry is a metaregistry pointing to npm, PyPI, Docker Hub, and other upstream registries.

MSSS (MCP Server Security Standard): A community-driven security standard defining 24 controls across 8 domains and 4 compliance levels (L1–L4) for MCP servers; v0.1.0 published January 2026, v1.0 targeting Q4 2026.

OWASP MCP Top 10: A list of 10 critical security risks for MCP-enabled systems, published by the OWASP Foundation in 2025; includes Tool Poisoning (MCP03), Intent Flow Subversion (MCP06), and Shadow MCP Servers (MCP09).

OAuth 2.1: The current version of the OAuth authorization framework, combining OAuth 2.0 with security best practices from RFC 9700; the preferred authentication method for MCP servers, used by only 8.5% of community servers but 81% of enterprise remote servers.

OIDC (OpenID Connect): An identity layer on top of OAuth 2.0 that enables cryptographic identity verification; the basis for trusted publishing in npm, PyPI, and the proposed MCP trusted publishing model.

Shadowing: An MCP attack variant in which a malicious server injects instructions into its tool descriptions that modify the behavior of trusted servers in the same session, enabling cross-server attacks without compromising the trusted server.

SLSA (Supply-chain Levels for Software Artifacts): A security framework from Google and OpenSSF that defines levels of supply chain integrity for software artifacts; relevant to MCP server provenance attestation.

Tool Poisoning Attack (TPA): An attack class discovered by Invariant Labs in April 2025 in which malicious instructions are embedded in MCP tool descriptions, invisible to users but visible to AI models, enabling credential theft and arbitrary code execution.

Trusted Publishing: An OIDC-based mechanism for publishing packages to registries using short-lived CI/CD tokens rather than long-lived API keys; pioneered by PyPI in April 2023 and now endorsed by the OpenSSF Securing Software Repositories Working Group.

#Related Research

• [Perea Research] Agentic AI Supply Chain Security: The broader supply chain security landscape for AI agents, including dependency management, model provenance, and runtime integrity — the context in which MCP registry governance sits.

• [Perea Research] OAuth 2.1 and Zero Trust for AI Agents: A deep dive into the authentication and authorization patterns emerging for agentic AI systems, including the OAuth 2.1 work that enabled enterprise MCP adoption and the Zero Trust architectures that enterprise deployments require.

• [Perea Research] Open Source AI Governance: Linux Foundation, Apache, and the Institutional Landscape: A comparative analysis of how major open-source foundations are approaching AI governance, with the AAIF as a case study alongside OpenSSF, LF AI & Data, and the Apache Software Foundation's AI initiatives.

#References