Notifications
Clear all
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.
NHIMG editorial — based on content published by AppSOC: We Tested 36,500 Public MCP Servers. Two-Thirds Aren't Safe for Enterprise Use
By the numbers:
- Fewer than 15% of public MCP servers earned an A or a B.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should teams govern AI agents that use MCP?
A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle.
Q: Why do public MCP servers create risk for enterprise identity programmes?
A: Because they extend trust into third-party tool endpoints that may be poorly maintained, over-permissioned, or carrying embedded secrets.
Q: What breaks when agents trust MCP tool descriptions by default?
A: The agent can follow malicious or misleading instructions embedded in metadata that should have been treated as untrusted.
Practitioner guidance
- Inventory every MCP server in use Build a live inventory of approved and observed MCP servers, including who published them, which agents can reach them, and whether they expose hardcoded credentials or unsafe tool permissions.
- Gate agent access on server trust scores Block or restrict agents from connecting to MCP servers below a minimum security threshold, and require separate approval for read and write operations.
- Inspect tool metadata before execution Scan tool descriptions, manifests, and configuration files for hidden instructions, secrets, and unexpected capability claims before an agent is allowed to use them.
What's in the full report
AppSOC's full research covers the operational detail this post intentionally leaves for the source:
- The full A-to-F scoring methodology, including how security, operational, and adoption maturity were weighted across 36,527 servers.
- The distribution of grades across the public MCP ecosystem, which is useful if you need to compare your own exposure against the research set.
- Examples of risky MCP server behaviours and the kinds of configuration issues that pushed servers into lower trust grades.
- The collaboration context with Cloud Security Alliance and how the RiskRubric database is being extended for the agentic control plane.
👉 Read AppSOC's analysis of MCP server security across 36,527 public servers →
MCP server security: are your agents trusting unsafe tools?
Explore further
15/08/2026 6:15 pm
MCP security is now an identity governance problem, not a niche protocol issue. The article shows that the real control failure is not merely whether MCP servers exist, but whether enterprises can govern which servers an agent is allowed to trust. That places MCP inside the same lifecycle, scoping, and oversight discipline already used for privileged NHI. Practitioners should treat every MCP connection as a governed entitlement, not a convenience integration.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to the State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the State of MCP Server Security 2025.
A question worth separating out:
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.
👉 Read our full editorial: MCP server security is not enterprise-ready by default
