MCP server directories expose the real trust gap in AI access

At a glance

What this is: This is a comparison of major MCP server directories, and its key finding is that discovery and installation are improving faster than trust, security, and governance signals.

Why it matters: It matters because MCP servers connect AI clients to sensitive systems, so IAM, NHI, and agentic AI programmes need controls that extend beyond catalog visibility into authorization, consent, and post-authentication behaviour.

👉 Read Descope's comparison of MCP server directories and trust signals

Context

Model Context Protocol, or MCP, is the standard that lets AI applications connect to tools and data sources through a common interface. The governance problem is that once those connections exist, catalog quality does not tell you what the agent is actually authorised to do, how those grants are reviewed, or whether risky actions require approval.

For IAM and NHI teams, MCP directories are a discovery layer, not a control plane. The article is useful because it compares how different registries expose trust signals, but the operational question remains the same: how do you govern agent access after authentication, especially when the server itself may be well listed but poorly controlled?

The primary issue is familiar to identity teams. Easier access to databases, repositories, and internal tools expands the number of non-human identities touching production systems, while the evidence needed for review, consent, and least privilege often sits outside the directory.

Key questions

Q: How should security teams govern MCP server access in production?

A: Security teams should treat MCP access as a non-human identity control problem, not a directory selection problem. Use the directory to find candidates, then enforce approval, narrow scopes, and revocation through the identity layer. Production access should be granted per tool or function, logged centrally, and recertified like any other privileged machine identity.

Q: Why do MCP directories create governance risk even when they look well curated?

A: Curation reduces search friction, but it does not control what happens after authentication. A well-presented MCP directory can still point to a server with broad permissions, weak lifecycle management, or unclear consent handling. The governance risk comes from assuming metadata equals control, when the real exposure begins at connection time.

Q: What is the difference between directory trust signals and runtime control for MCP?

A: Directory trust signals help you decide whether a server is worth evaluating. Runtime control decides what an AI client can actually do once connected. Trust badges, popularity metrics, and maintainer verification are useful, but they do not replace per-tool authorization, session logging, or revocation when access should end.

Q: How do IAM teams keep MCP from becoming another unmanaged NHI sprawl problem?

A: IAM teams should inventory every MCP connection as a governed identity relationship, not a one-off developer convenience. The controls that matter are entitlement minimisation, approval for sensitive tools, periodic recertification, and clean offboarding. Without that discipline, MCP adoption simply multiplies machine identities faster than governance can catch up.

Technical breakdown

MCP directories are discovery layers, not authorization systems

An MCP directory helps users find servers, inspect metadata, and sometimes install a client connection. It does not define what the AI client may do after authentication, nor does it enforce approval flows, scope limits, or session-level constraints. That distinction matters because a well-curated directory can still expose a server that is overly permissive once connected. In identity terms, the directory helps with selection, but not entitlement governance, policy enforcement, or revocation.

Practical implication: treat directory trust signals as intake metadata, not as evidence that the resulting MCP connection is safe for production use.

Trust signals vary, but none replace runtime access control

The article shows three different trust models: GitHub Registry leans on standardisation, Glama adds security and quality checks, and PulseMCP and MCP Market prioritise discovery and popularity. Those signals help shortlist servers, but they do not answer the question that matters most to security teams: what happens after the agent is authenticated. Runtime authorisation, consent, and function-level scoping still need to be enforced by the identity layer, not inferred from the directory listing.

Practical implication: require explicit authorization controls for each MCP tool or function, even when the registry presents strong verification signals.

MCP expands the non-human identity attack surface

Every server in the comparison grants AI clients access to sensitive systems such as databases, repositories, or internal services. That makes MCP part of the NHI problem space because each connection introduces a machine identity, a delegated credential path, and a new place for privilege creep. The operational risk is not merely exposure to a bad server, but accumulation of access paths that are hard to inventory, hard to certify, and easy to forget once installed.

Practical implication: inventory MCP-connected identities alongside other NHIs and include them in lifecycle review, offboarding, and privilege governance.

NHI Mgmt Group analysis

MCP directory quality is a governance input, not a security conclusion. A registry can improve discoverability, documentation, and maintainability signals, but it cannot certify how an AI client will behave once connected. That means practitioners should stop treating directory selection as the end of the control conversation. The real control boundary begins after authentication, where consent, scope, and runtime enforcement determine whether the connection is safe or merely convenient.

Function-level authorization is the right mental model for MCP risk. The article repeatedly shows that server listings are too coarse to answer production questions. AI clients do not need broad server-wide access if the task only requires a subset of tools, and that makes per-function scope the governance unit that matters. In practice, this aligns MCP more closely with NHI entitlement design than with simple app onboarding.

Discovery at scale creates identity blast radius. Once a catalog holds thousands of servers, the security challenge shifts from finding a usable server to managing the spread of connected identities across teams, environments, and use cases. That is a classic NHI pattern: the easier access becomes, the faster review debt accumulates. Practitioners should treat catalog growth as a reason to tighten lifecycle and entitlement governance, not to rely on popularity signals.

AI agents do not need a trusted marketplace so much as a constrained trust model. The article’s comparison makes clear that better search and better metadata improve usability, but not necessarily control. For security programmes, the priority is a governable path from discovery to approval to revocation. The implication is straightforward: build the control plane around the agent, not around the directory.

OWASP NHI Top 10 and OWASP Agentic AI Top 10 both matter here. MCP sits at the intersection of machine identity governance and agentic tool use, so teams need to assess credential exposure, excessive privilege, and tool misuse together. That cross-domain framing is what most directories miss, and it is what practitioners must model before allowing MCP servers into production.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why practitioners should pair discovery sources with controls from OWASP Agentic AI Top 10 and directory-specific review workflows.

What this signals

MCP directory sprawl will push governance upstream. As catalog sizes rise, teams will need a control model that separates the convenience of discovery from the authority of runtime access. The practical lesson is to treat every new MCP connection as a governed identity path, not as a developer install event.

With 98% of companies planning to deploy more AI agents within 12 months, per AI Agents: The New Attack Surface report, the number of MCP-linked identities is likely to grow faster than entitlement review capacity. That makes lifecycle discipline, not catalog popularity, the limiting factor for safe adoption.

Directory trust debt: a registry can reduce uncertainty, but it cannot remove the need for approval, revocation, and tool-level scoping once an AI client connects. Security teams should fold MCP into the same governance paths used for service accounts, API keys, and other NHIs.

For practitioners

• Separate discovery from authorization Allow directories to inform candidate selection, then enforce approval, scope validation, and session policy in the identity layer before any server is connected.
• Assign per-tool scopes to every MCP client Replace broad server-wide access with narrow function-level permissions so each AI client receives only the tools needed for the task at hand.
• Include MCP connections in NHI inventory and reviews Track every deployed MCP server connection as a non-human identity relationship and recertify it with the same discipline used for service accounts and tokens.
• Require offboarding for dormant or abandoned servers Remove unused MCP registrations, revoke linked credentials, and verify that stale servers are not still reachable from active AI clients.

Key takeaways

• MCP directories improve discovery, but they do not solve authorization, consent, or revocation for AI-connected tools.
• The security value of a registry is limited unless identity teams can enforce per-tool scope and lifecycle controls after connection.
• As MCP adoption grows, the real governance challenge is inventorying and controlling the non-human identities created by every new server relationship.

Key terms

• MCP Directory: An MCP directory is a catalog that helps developers find, compare, and install Model Context Protocol servers. It improves discovery and metadata visibility, but it does not itself enforce authorization, consent, or revocation for the AI client once a connection is established.
• Function-Level Authorization: Function-level authorization limits access to the specific tools or actions an AI client needs, rather than granting broad server-wide permissions. For MCP, this is the practical control boundary because a connected agent may only need a subset of available capabilities.
• Non-Human Identity Relationship: A non-human identity relationship is any governed connection between a machine credential and a resource, service, or tool. In MCP environments, each server connection should be treated as an identity relationship with lifecycle, scope, and review requirements, not as a one-time developer convenience.
• Directory Trust Signal: A directory trust signal is any metadata used to judge whether a listed server looks reliable, such as maintainer verification, popularity, security scoring, or update freshness. It helps with evaluation, but it is not a substitute for runtime control or policy enforcement.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step comparison of MCP directories across discovery, curation, maintenance, and installation flows
• Platform-specific trust indicators such as maintainer verification, popularity signals, and security scorecards
• Practical examples of searching, installing, and testing MCP servers in a standard client workflow
• The article's side-by-side matrix covering refresh rates, user reviews, and category browsing behavior

👉 Descope's full post details the directory-by-directory installation and trust evaluation differences

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 identity security programme, it is worth exploring.