MCP server security is not enterprise-ready by default

At a glance

What this is: PointGuard AI scored 36,527 public MCP servers and found that most of them carry serious security flaws that make them unsafe for enterprise use.

Why it matters: IAM and NHI teams need to treat MCP as a governed trust boundary because agent access to unsafe tool endpoints expands blast radius across autonomous, workload, and human identity programmes.

By the numbers:

• 67%, ghly two-thirds, or 67%, of the MCP servers we tested earned a D or an F.
• 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.

👉 Read AppSOC's analysis of MCP server security across 36,527 public servers

Context

MCP is the protocol that lets AI agents reach tools, data, and APIs. In practice, that makes MCP a trust boundary, not just a connectivity layer, because the agent inherits whatever permissions, metadata, and operational weaknesses the server exposes.

The security gap is straightforward: adoption is moving faster than governance. When public MCP servers are graded mostly in the C-through-F range, enterprises cannot assume that published availability, popularity, or convenience translates into safe enterprise use.

For identity teams, the key question is how MCP access gets approved, scoped, monitored, and revoked across NHI and agentic AI programmes. A server that looks harmless at onboarding can still become a privileged execution path if its configuration, tool descriptions, or publisher state changes later.

Key questions

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. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

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. That creates an NHI and agentic control problem at the point where machines decide what to do next, which is exactly where traditional approval models are weakest.

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. That breaks the assumption that documentation is harmless and turns descriptive text into a control input, allowing unauthorized actions to occur without obvious infrastructure compromise.

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.

Technical breakdown

Why MCP server trust breaks at the tool boundary

MCP servers do more than host code. They expose tool definitions, descriptions, and call paths that an agent may treat as trusted context when selecting actions. That means the risk is not limited to software vulnerabilities in the traditional sense. A compromised or poorly governed MCP server can influence what an agent decides to do, what data it can reach, and which downstream systems it can invoke. In agentic environments, that turns the tool boundary into part of the authorization surface, which is why static software trust checks are not enough on their own.

Practical implication: security teams should evaluate MCP servers as authorization endpoints and not only as software packages.

What the A-to-F scoring model is actually measuring

PointGuard AI’s scoring combines security maturity, operational maturity, and adoption maturity. That matters because an MCP server can be widely used while still being operationally weak, poorly maintained, or packed with hardcoded secrets. The model therefore separates popularity from trustworthiness and makes visible the difference between an actively governed project and one that simply spread quickly. For practitioners, this is useful because it mirrors the real enterprise decision: whether a server is sufficiently governed to sit inside an agent’s execution path.

Practical implication: use a multi-factor review model that includes security, maintenance, and operational signals before allowing MCP in production.

Why poisoned tool descriptions are an identity problem

The article’s attack pattern shows that malicious instructions can be embedded in tool descriptions that an agent reads before acting. This is not just content abuse. It is an identity and authorization problem because the agent is making runtime decisions based on metadata that should not be implicitly trusted. In effect, the server can shape the agent’s behaviour without changing the network path or triggering obvious platform alarms. That is why MCP governance has to extend beyond secrets and static permissions into content inspection and runtime policy enforcement.

Practical implication: inspect tool metadata and enforce policy at the moment of agent connection, not only at provisioning time.

Threat narrative

Attacker objective: The objective is to redirect an agent into executing unapproved actions while making the abuse appear like normal tool use.

1. Entry occurs when an agent connects to an MCP server whose tool descriptions or configuration contain malicious or unsafe instructions.
2. Escalation follows when the agent treats that metadata as trusted context and executes unauthorized tool calls or data access paths.
3. Impact is achieved through data exfiltration, unauthorized operations, or chained tool misuse that expands the blast radius across connected systems.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Tool descriptions have become part of the attack surface. When agents read descriptions to decide what to do, metadata becomes an authorization input rather than documentation. That creates a runtime governance gap because content can influence execution without changing code paths or triggering traditional allowlists. The implication is that enterprises must stop assuming that safe code alone equals safe agent behaviour.

Named concept: MCP trust debt. Rapid adoption of public MCP servers creates accumulated trust in tools that have not earned enterprise use. The debt grows when security, operational maturity, and publisher assurance are treated as optional rather than mandatory. In practice, that means unmanaged MCP can become a standing liability across AI agents and the NHI controls they inherit.

Popularity is not a control and never has been. The finding that fewer than 15% of public MCP servers earned an A or B reinforces a familiar identity lesson: wide adoption can amplify bad access decisions just as quickly as it spreads good ones. Governance has to decide what is permitted before agents connect, because runtime convenience does not equal authorization discipline.

Continuous oversight matters because the trust profile of an MCP server can change after onboarding. Maintainers disappear, tool descriptions change, and risk posture drifts. That makes static approval lists insufficient for agentic environments that can reconnect at machine speed. The practitioner conclusion is simple: if you cannot monitor regression, you do not have governance, only historical approval.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to the State of MCP Server Security 2025.
• From our research: 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the State of MCP Server Security 2025.
• For a broader control lens, OWASP Agentic Applications Top 10 helps map MCP misuse to agentic risk patterns.

What this signals

MCP trust debt: enterprises are accumulating access decisions faster than they can validate them, which is why MCP governance needs to look more like entitlement management than software onboarding. With 80% of organisations already reporting AI agents acting beyond intended scope in our AI Agents: The New Attack Surface research, the control problem is no longer theoretical.

MCP should be folded into the same policy stack that governs service accounts, tokens, and workload identity. If an agent can reach a tool endpoint without scoped approval and continuous review, the enterprise has created a machine-to-machine privilege path that bypasses normal identity discipline.

Security leaders should prepare for a category shift from discovery to enforcement. The practical question is not whether the MCP ecosystem will keep expanding, but whether the organisation can prove which servers are permitted, which are monitored, and which were never safe to trust in the first place.

For practitioners

• 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.
• Monitor for trust regression continuously Reassess MCP servers whenever publisher status, dependency risk, security policy, or tool descriptions change, and remove access when governance evidence goes stale.

Key takeaways

• Most public MCP servers are not enterprise-ready, and the data shows that weak security, maintenance, and operational maturity are common across the ecosystem.
• The main risk is not just vulnerable code. It is trusting tool endpoints and metadata that can steer agent behaviour at runtime.
• Enterprises need inventory, scoped access, and continuous re-scoring before MCP becomes a hidden privilege layer inside agentic AI programmes.

Key terms

• Mcp Trust Boundary: The security boundary created by a Model Context Protocol connection between an AI assistant and an external system. Each connection can supply data, trigger actions, or both, so it must be governed like a delegated access path rather than a simple integration.
• Tool description poisoning: A manipulation technique where malicious instructions are embedded in tool metadata that an agent reads before acting. The danger is that the agent may treat those instructions as trusted context, allowing unauthorized calls or data access without any obvious code change or network anomaly.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

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.

👉 AppSOC's full research covers the scoring model, grade distribution, and MCP risk governance details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or identity security programme, it is worth exploring.