Topic starter
15/08/2026 6:07 pm
TL;DR: PointGuard AI’s assessment of 36,527 public MCP servers found that 67% earned D or F grades and fewer than 15% reached A or B, showing that most of the open MCP ecosystem is not ready for enterprise use, according to AppSOC. The governance problem is not adoption speed but the assumption that agents can safely trust tool endpoints without continuous scoping, monitoring, and enforcement.
Editorial analysis by NHI Mgmt Group, based on content published by AppSOC: “MCP Security: 67% of Public Servers Fail Enterprise Tests”.
By the numbers:
- 67% of the 36,527 MCP servers scored earned a D or an F, meaning they carry serious security flaws and are not recommended for enterprise use.
- Fewer than 15% of public MCP servers earned an A or a B.
Key questions
Q: What breaks when MCP servers run locally without governance?
A: Local MCP servers inherit workstation privileges, which means they can read plaintext secrets, access user-scoped tools, and operate without a central approval point.
Q: Why do public MCP servers create enterprise risk even when they are popular?
A: Popularity only shows adoption, not trustworthiness.
Q: How should teams evaluate an MCP server before production use?
A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions.
Practitioner guidance
- Inventory every MCP server in agent workflows Build a complete register of MCP servers, the agents that call them, and the business functions those tools can trigger.
- Enforce tool-level authorization at the connection point Place policy between agents and tools so a server cannot be reached solely because it is discoverable.
- Inspect tool metadata for hidden instructions Review tool descriptions, manifests, and other agent-readable content as part of security review.
Bottom line: Most public MCP servers are unsafe for enterprise use by default, so agent access to them should be treated as a governed entitlement rather than a convenience setting.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 6:15 pm
MCP server trust is now an identity governance decision, not a software preference. The article shows that enterprise risk begins before execution, at the moment an agent is allowed to trust an external tool endpoint. That shifts the governance question from whether an MCP server exists to whether it is authorized, scored, and monitored as part of the identity plane. Practitioners should treat server trust as a living entitlement, not a static integration choice.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between MCP discovery and MCP enforcement?
A: Discovery tells you which servers agents might reach. Enforcement decides which ones they are actually allowed to use, under what terms, and for which operations. Discovery without enforcement leaves risk visible but active, while enforcement without discovery cannot govern the full estate.
👉 Read our full editorial: MCP server security is not enterprise-ready by default