TL;DR: MCP adoption is accelerating while the list of available servers keeps growing, which makes discovery, trust, and access governance harder for teams using AI-connected tools, according to Obot. The central issue is not just tool variety but the control gap around who can expose what data and actions to AI clients.
At a glance
What this is: Obot’s update argues that MCP server growth is accelerating faster than teams can evaluate trust, usefulness, and governance for AI-connected tools.
Why it matters: For IAM, NHI, and AI governance teams, the issue is not tool discovery alone but the control problem of who can expose data and actions to AI clients.
Context
MCP server sprawl is a governance problem before it is a tooling problem. As more AI-connected servers appear, the hard part becomes deciding which servers are trusted, what they can reach, and how their permissions are constrained across the organisation.
In practical terms, this sits at the intersection of AI tool governance and non-human identity control. Every MCP server can act as a delegated access path, so inventory, approval, and access scope matter as much as the quality of the tool itself.
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 MCP servers reduce integration risk in enterprise AI workflows?
A: MCP servers reduce integration risk because they replace one-off connectors with a standard tool interface. That lowers maintenance burden, improves reuse across agents and business functions, and makes permissions easier to manage consistently. Standardization also helps teams test, observe, and govern tool access without rebuilding custom integrations for every new data source.
Q: How can organisations tell if an MCP server is safe enough to use?
A: Look for evidence that every tool is bound to a narrow role, every session is logged, every credential is short lived, and unexpected outbound behaviour is blocked at runtime. If any one of those elements is missing, the environment is still relying on trust rather than control.
Q: Should organisations treat MCP servers like ordinary plugins or like privileged identities?
A: Organisations should treat MCP servers like privileged identities, because they are not passive extensions. They execute inside trusted workflows, make file and API access possible for agents, and can widen the blast radius of a compromise if their permissions are not tightly scoped and continuously revalidated.
Technical breakdown
MCP server sprawl and delegated access paths
MCP servers extend an AI client by giving it access to external tools, data, and actions. That turns each server into a delegated access path, not just a convenience layer. The security challenge is that the client may not understand the full blast radius of the server it is calling, especially when servers can read messages, query data, or trigger workflows. As the server ecosystem grows, the governance problem shifts from simple installation control to trust calibration: which servers are allowed, which identities they run under, and which datasets or actions they can reach.
Practical implication: Treat every MCP server as a governed access connector with explicit scope, ownership, and approval.
Why discovery alone does not solve AI tool trust
A growing catalogue of MCP servers creates selection friction, but discovery is not the same as assurance. Teams still need to know whether a server is maintained, whether it exposes sensitive functions, whether credentials are handled safely, and whether its behaviour matches the access that AI clients are being given. In other words, the control gap is not a lack of options. It is a lack of standardised trust signals for server inventory, capabilities, and privilege boundaries. That is where governance needs to move from informal adoption to policy-based review.
Practical implication: Require capability review and identity checks before allowing any MCP server into production workflows.
MCP authentication and authorization need explicit boundaries
Because MCP servers can sit between AI clients and enterprise systems, authentication and authorisation become central design issues. The right question is not just whether the server can connect, but how it proves its identity, how clients are authorised to use it, and whether the server can be restricted to the minimum set of operations. The protocol itself is only part of the picture. Implementation choices determine whether the server becomes a narrow, auditable bridge or a broad, over-permissioned control plane for AI actions.
Practical implication: Bind MCP access to tightly scoped authentication, authorization, and logging rules.
Threat narrative
Attacker objective: The objective is to turn a trusted AI integration point into a high-leverage access path for sensitive data and downstream actions.
- Entry occurs when an AI client connects to an MCP server that has been added for convenience without a strong review of its permissions or source integrity.
- Credential and data exposure follow when the server can read or relay sensitive information, including tokens, queries, or workflow inputs that the client passes through it.
- Impact appears when the delegated path is trusted more broadly than intended, letting the server influence data access or actions across the connected environment.
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 sprawl is becoming an identity governance problem, not just a tooling problem. The more servers an organisation permits, the harder it becomes to answer basic questions about who can expose what to an AI client. That is a governance failure mode because the server becomes a delegated authority layer with real access consequences. Practitioners should manage MCP servers as part of identity and access policy, not as informal add-ons.
Trust signals for MCP servers are currently too weak for enterprise use at scale. A list of available servers does not tell a security team whether the server is maintained, what data it can touch, or how it should be classified. The field needs clearer inventory, ownership, and approval boundaries before AI clients are allowed to rely on these servers in business workflows. Practitioners should assume discovery without assurance increases risk.
Standards-based control will matter more as MCP adoption expands. The protocol may make tool connection easy, but governance depends on how authentication, authorization, and runtime scoping are implemented around it. That is where NHI control principles intersect with AI governance: delegated access must be narrow, accountable, and revocable. Practitioners should evaluate MCP under explicit access policy rather than convenience.
The named concept here is MCP trust debt: the growing gap between the number of available MCP servers and the organisation’s ability to govern them safely. That gap accumulates when teams adopt servers faster than they define ownership, approval, and revocation rules. The longer it grows, the more likely a trusted AI connector becomes an unmanaged access path. Practitioners should treat trust debt as an operational risk to be reduced, not a cataloguing issue to be tolerated.
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.
- Read next: MCP Security Guide
What this signals
MCP trust debt: the real risk is the gap between rapid server adoption and the organisation’s ability to enforce ownership, approval, and revocation. The number of available servers will keep rising, so governance has to move earlier in the onboarding lifecycle rather than trying to recover control later.
The practical test is whether an AI connector can be inventoried, scoped, and removed as cleanly as any other non-human access path. If it cannot, the environment is already depending on informal trust instead of enforceable policy.
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.
For practitioners
- Inventory all MCP servers in use Create a current register of every MCP server connected to AI clients, including business owner, technical owner, data touched, and permission scope.
- Approve servers before client access Require security and data-owner review before any new MCP server is allowed to connect to production AI workflows.
- Restrict each server to minimum scope Limit server permissions to the smallest viable tool set and block servers from broad access to data or actions they do not need.
- Log and review delegated actions Record which AI client used which server, what action was requested, and which data or systems were reached.
- Offboard unused servers quickly Remove dormant MCP servers and revoke any credentials or tokens tied to integrations that are no longer required.
Key takeaways
- MCP server growth is creating a governance gap because organisations can add access paths faster than they can assess trust, scope, and ownership.
- The core security issue is delegated authority, since each server can become a pathway from an AI client into sensitive data and actions.
- Teams need inventory, approval, least privilege, and revocation controls around MCP servers before adoption becomes operational sprawl.
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 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF 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 servers need explicit authentication boundaries before AI clients can trust them. |
| NHI-05 — Overprivileged NHI | The article's core risk is delegated access paths with broader scope than necessary. | |
| NHI-10 — Human Use of NHI | Humans are selecting and operating the servers that AI clients consume, creating governance dependency. | |
| Recommendation — Bind MCP access to authenticated, auditable identities before allowing server connections. Scope each MCP server to the minimum permissions required for its intended function. Assign clear human ownership for every MCP server and make that owner accountable for access decisions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | A compromised or over-trusted MCP server can expose credentials and move access laterally. |
| Recommendation — Map MCP server exposures to credential access and lateral movement paths in threat hunting and detection. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governing AI-connected tools and their trust boundaries. |
| Recommendation — Define AI governance rules for MCP onboarding, ownership, approval, and revocation. | ||
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.
- Delegated access path: A delegated access path is the chain of identities, tokens, connectors, and approvals that lets one system act through another. It becomes a governance concern when the path outlives the original approval or can be reused for actions beyond the intended business purpose.
- MCP trust debt: MCP trust debt is the accumulated risk created when Model Context Protocol connections, permissions, and assumptions are added quickly without strong governance. It appears when agents, tools, and data sources are linked before identity, authorization, logging, and revocation are fully defined, leaving hidden access paths and weak accountability.
- Server Scope: Server scope is the exact set of tools, data sources, and actions an MCP server is allowed to reach. Tight scope reduces blast radius, while broad scope turns a convenience layer into a high-risk access bridge that is difficult to audit or contain.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity controls into practical guardrails for AI-connected systems and delegated access.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org