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.
At a glance
What this is: This analysis says most public MCP servers are too risky for enterprise use, with two-thirds scoring D or F in PointGuard Research Labs’ testing.
Why it matters: For IAM and security teams, MCP changes tool access into a governed identity problem, where agent permissions, server trust, and runtime enforcement must be managed together.
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.
Context
MCP server security is now a governance problem, not just a developer convenience issue. The protocol gives agents a way to reach tools, data, and APIs, but that same connectivity creates a control point that enterprises must inventory, score, and enforce before an agent is allowed to act.
The central failure is trust without continuous verification. If agents can discover and call public MCP servers without policy scoping, content inspection, and change monitoring, then tool access becomes an uncontrolled extension of the identity plane rather than a governed runtime decision.
PointGuard Research Labs’ findings are typical of an immature ecosystem, not an isolated bad example. The article shows that adoption is moving faster than assurance, which is exactly where identity governance gaps become operational risk.
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. That breaks the assumption that credential use is limited to known services. The practical result is hidden NHI sprawl, with no reliable inventory or review path for the identities doing the work.
Q: Why do public MCP servers create enterprise risk even when they are popular?
A: Popularity only shows adoption, not trustworthiness. Public MCP servers can still contain hardcoded secrets, poor maintenance, or malicious tool descriptions, so a widely used server may be a broadly distributed liability rather than a safe default.
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. A directory score or popularity rank is not enough for production decisions. The real test is whether the server can be governed as a bounded identity relationship.
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.
Technical breakdown
Why MCP server trust cannot be assumed at first connection
MCP turns external tools into machine-readable capabilities that an agent can call at runtime. That means the trust decision is not just about code quality, but about whether the server’s metadata, tool descriptions, and exposed operations are safe enough for an autonomous consumer to interpret and execute. In practice, this creates a control plane problem: the agent is not browsing a website, it is selecting actions from a live tool catalog. If that catalog is not continuously scored and constrained, the agent inherits whatever risk the server presents at the moment of connection.
Practical implication: Treat every MCP server as a governed trust relationship, not a generic integration target.
How poisoned tool descriptions become an execution path
The article’s attack example shows a subtle mechanism: malicious instructions hidden in tool descriptions can alter agent behavior without obvious network anomalies. This is not classic malware delivery; it is context poisoning, where the agent reads untrusted content as operational guidance. Because the descriptions sit inside the same trust boundary as legitimate tool metadata, the exploit bypasses naive perimeter checks and lands in the decision layer. That makes content inspection and operation-level authorization essential, especially when agents can chain multiple tools in one session.
Practical implication: Inspect tool metadata and authorize operations separately from mere server reachability.
Why open ecosystem popularity is a weak security signal
The article makes a useful distinction between adoption and assurance. A widely used MCP server can still be unsafe if it has hardcoded secrets, weak operational hygiene, or a stale maintenance posture. Popularity may tell you exposure is spreading, but it does not tell you whether the server is suitable for enterprise use. For identity programmes, that means inventory alone is not enough. The control question is which servers are allowed, under what policy, and with what ongoing monitoring as their posture changes.
Practical implication: Use risk scoring and maintenance signals before granting production agent access.
Threat narrative
Attacker objective: The attacker aims to redirect agent behaviour through trusted tool metadata and turn a legitimate integration into unauthorized execution.
- Entry occurs when an agent connects to a public MCP server whose tool descriptions or code have not been vetted for enterprise use.
- Credential or instruction abuse follows when hidden malicious content in those descriptions is treated as trusted context by the agent.
- Impact occurs when the agent executes unauthorized actions, exfiltrates data, or chains into additional tools under the cover of legitimate-looking interaction.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Open MCP ecosystems create identity blast radius when trust is implicit. When agents can reach public servers that have not been validated, the blast radius extends from one tool call to the entire decision chain that follows. That matters because the security issue is not only exposure of a server, but the downstream authority an agent may inherit from it. Enterprises need to think in terms of permitted tool scope, not mere connectivity.
Context poisoning is the named concept this article sharpens. Tool descriptions can function as an attack surface when an agent reads them as operational truth. That means the control problem is not just secret leakage or code review, but untrusted runtime context being promoted into action. The implication is that MCP governance must address what an agent is allowed to believe before it can address what it is allowed to do.
Security maturity and operational maturity must be joined before adoption becomes safe. The scoring model in the article is useful because it separates vulnerable code, poor maintenance, and weak adoption signals. Enterprises often evaluate integrations on connectivity alone, but MCP requires a combined view of vulnerability posture, publisher trust, and lifecycle hygiene. Practitioners should not let reachability outrun assurance.
The market is moving toward governed agentic control planes. The collaboration with CSA signals where this category is heading: standardised scoring, policy enforcement, and ongoing posture visibility instead of informal trust. That direction does not reduce the need for internal governance. It raises the bar for inventory, approval, and runtime control across every MCP server an agent might touch.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Context poisoning is the control gap enterprises are underestimating: if an MCP server can shape the agent’s next action through untrusted descriptions, then the security boundary sits inside the tool metadata, not just around the server. Governance has to move from simple allowlisting to continuous validation of what the agent is being told to do.
MCP risk is a good example of why identity teams need to think in terms of delegated authority at runtime. The useful control is not whether a server exists, but whether the agent is allowed to trust it, what it may read, and how its actions are constrained once the session begins.
The article’s 36,527-server sample shows how quickly an ecosystem can outgrow manual review. When adoption scales faster than assurance, inventory, scoring, and policy enforcement become the only durable way to keep agent tool use inside an acceptable risk boundary.
For practitioners
- 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. Classify each server by trust level before any production use.
- 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. Separate read and write operations, and block unscored or low-trust servers by default.
- Inspect tool metadata for hidden instructions Review tool descriptions, manifests, and other agent-readable content as part of security review. Treat unexpected command-like text in metadata as a trust failure, not a benign description.
- Monitor server posture continuously Reassess security maturity, maintainer activity, and exposed secrets as servers change over time. A server that was acceptable at onboarding can become unsafe after a quiet metadata or ownership shift.
Key takeaways
- 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.
- The risk is not limited to vulnerable code. Agent-readable tool descriptions can become an execution path when they contain hidden or malicious instructions.
- Enterprises need continuous scoring, policy enforcement, and metadata inspection if they want MCP adoption without uncontrolled expansion of agent trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP trust failures begin when agents authenticate to tools without strong trust validation. |
| NHI-08 — Environment Isolation | The article shows why tool access must be isolated from uncontrolled agent context. | |
| Recommendation — Apply NHI-04 to require stronger trust validation before agents can use an MCP server. Use NHI-08 to separate risky MCP tools from higher-trust agent execution paths. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents can inherit unsafe tool authority from MCP servers with weak governance. |
| Recommendation — Map MCP tool trust decisions to ASI03 and constrain inherited privileges at runtime. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article’s attack example shows trusted metadata being used to reach data and actions. |
| Recommendation — Track poisoned tool-content scenarios to TA0006 and TA0010 in your threat models. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP governance depends on limiting which tools and operations an agent may invoke. |
| Recommendation — Apply PR.AA-05 to authorize only approved MCP tools and operations for each agent. | ||
Key terms
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
- Agentic Data Control Plane: An Agentic Data Control Plane is the governance layer that manages how AI agents discover, request, use, and protect data while acting on behalf of a user or system. It coordinates policy enforcement, authorization, logging, and data boundaries across tools, APIs, and repositories, so agent actions remain traceable, constrained, and auditable.
- Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org