TL;DR: MCP moved from niche integration layer to enterprise infrastructure in under two years, with more than 10,000 active public servers and broad exposure risks around typosquatting, tool poisoning, and invisible delegated access, according to Unixi. The core issue is that existing IAM and authorization models can record sign-ins without governing what an MCP server can actually reach.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: MCP server security creates a governance gap between authentication and actual tool reach.
Why it matters: It matters because identity teams need to govern delegated access, server trust, and offboarding for MCP connections, not just sign-in events.
Context
MCP, or Model Context Protocol, standardises how AI applications discover and invoke external tools and data sources. That standardisation is useful operationally, but it also means one approved connection can expose databases, repositories, and internal APIs in ways traditional identity controls do not describe well.
The governance gap is not in sign-in alone. An identity system may authenticate a person or application while leaving the downstream server, delegated rights, and post-approval behaviour outside its view. For identity programmes, MCP is therefore an access-governance problem as much as an integration problem.
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 shadow MCP servers create higher risk than ordinary shadow IT in AI environments?
A: Shadow MCP servers matter because they let an AI assistant act, not just observe. Once a model can run commands, write files, query internal systems, or send messages, the blast radius expands quickly. If those capabilities are added outside central oversight, security teams lose visibility, logging, and control over privileged actions across production workflows.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.
Q: Should organisations block local MCP servers or govern them differently?
A: Blocking may be appropriate for high-risk environments, but most organisations will need to govern local MCP servers rather than assume they can eliminate them. The decision should follow the value of the use case, the sensitivity of the connected systems, and the maturity of secret handling. If local execution is allowed, it needs compensating controls and strict package approval.
Technical breakdown
How MCP turns a tool connection into reusable access
MCP moves from custom per-tool integrations to a common host, client, and server model. The client discovers a server’s capabilities, then sends invocation requests on behalf of the host. That means metadata, tool lists, resource lists, and prompt templates become part of the trusted integration surface. Once a server is installed, it can look legitimate while still holding reach into internal systems that identity teams did not explicitly model. The security issue is not only whether the connection was allowed, but whether the allowed connection is still constrained to the original intent.
Practical implication: govern MCP onboarding as an access decision, not just a software installation.
Why shadow MCP servers create hidden identity exposure
Shadow MCP servers are servers that reach corporate data without approval, inventory, or policy control. They may be installed from registries, repositories, or search results, and typosquatting makes the fake entry look close enough to a real one that a user or agent chooses it by mistake. In practice, this creates a second identity problem beyond the approved server set: unapproved delegated access that authentication logs alone will not reveal. If you only monitor sign-ins, you miss the tool endpoints, resources, and permissions the server can now access.
Practical implication: inventory MCP servers and tie every server to an approved owner and business purpose.
Why authorization does not solve MCP server reach
The article separates authorization from governance. A policy can approve a token or delegated grant, but still say nothing about whether the server should have been reachable at all, whether the access is being used as granted, or whether the approved behaviour has changed since review. Local servers make the gap larger because they can run from a config file and never pass through an external authorization server. That leaves identity teams with a control blind spot: a valid authentication event without a durable record of what the server can actually touch.
Practical implication: pair authorization with continuous discovery of identity-to-tool connections and their effective privileges.
Threat narrative
Attacker objective: The attacker aims to obtain durable delegated access through a convincing MCP server and use that access to reach internal tools and data unnoticed.
- Entry begins when a user or agent installs or selects a lookalike MCP server from a registry, repository, or search result.
- Credential or consent abuse follows when the server obtains delegated access that looks legitimate but reaches internal data and APIs beyond intended oversight.
- Impact occurs when the server can read, invoke, or manipulate enterprise resources while identity logs show only a normal sign-in event.
Breaches seen in the wild
- AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
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
Identity governance for MCP must start at server adoption, not at sign-in. The article shows that a valid login does not tell you which server was installed, what it can reach, or whether it should have been approved in the first place. That breaks the old assumption that authentication visibility is enough to explain delegated access. Practitioners should treat MCP server adoption as a governed access event, not a passive integration choice.
Shadow MCP is an inventory failure before it is a privilege problem. Unapproved servers, lookalike entries, and local config-driven servers create access paths that never enter the normal governance workflow. That is a lifecycle gap as much as a technical one, because offboarding and review cannot work on assets that were never registered. The practitioner implication is simple: if the server is not inventoried, it is already outside governance.
Invisible delegated access is the named concept this category now needs. MCP makes it possible for an identity system to record a sign-in while leaving the downstream tool reach effectively unmanaged. The issue is not just overprivilege, but access that exists outside the control plane identity teams use for review, revocation, and attestation. Security teams need a governance model that follows the server’s effective reach, not just the user’s authentication event.
Typosquatting and tool poisoning show that MCP identity cannot be treated as static metadata. A server name, description, or approved version can look stable while the behaviour behind it changes or misleads the client. That means trust decisions cannot stop at catalogue review. Practitioners should assume the identity surface includes the server’s advertised capability set, its install channel, and its change history.
Enterprise MCP governance is converging on lifecycle control, not only access approval. The article’s four control pillars point to a broader pattern: discovery, approval, risk analysis, and deprovisioning must be tied together if delegated tool access is to remain governable. That aligns with the direction of identity governance generally, where the real question is not whether access was ever granted, but whether it is still appropriate now.
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: Shadow AI and AI Agent Discovery Guide
What this signals
Invisible delegated access: MCP forces identity programmes to govern the server that receives access, not just the user who started the session. When authentication is separated from effective reach, access review no longer answers the real question, which is what the connected server can touch right now.
The practical shift is toward continuous discovery of tool connections, their owners, and their reachable resources. That is the only way to make offboarding, revocation, and approval checks apply to MCP in the same way they apply to other non-human identities.
For practitioners
- Inventory every MCP server and its owner Record approved servers, local servers, and registry-sourced servers in the same inventory so you can see which tools have corporate reach and who is accountable for each one.
- Gate server adoption before any delegated grant Require review and approval before a user or agent can connect a server to corporate data, especially where the server can reach databases, repositories, or internal APIs.
- Track identity-to-tool connections continuously Log which identity holds which server connection, what resources that server can reach, and when the approved behaviour changes after onboarding.
- Revocation on offboarding and posture change Remove server grants when a user leaves, when a server is no longer approved, or when the server’s behaviour drifts from the reviewed scope.
Key takeaways
- MCP server security is really an identity governance problem because sign-in visibility does not describe tool reach.
- Shadow and typosquatted servers create access paths that escape normal inventory and review processes.
- The control gap closes only when organisations govern server adoption, delegated reach, and revocation together.
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 SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Lookalike and unapproved MCP servers function as third-party identity risk in this article. |
| NHI-10 — Human Use of NHI | Users selecting MCP servers from registries are exercising human approval over non-human access. | |
| Recommendation — Inventory and approve third-party MCP servers before they can obtain corporate access. Remove ad hoc server selection from end users and route adoption through governed approval. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on delegated access credentials and their lifecycle, not just login events. |
| Recommendation — Apply credential lifecycle controls to MCP grants so delegated access can be revoked cleanly. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes how a trusted MCP server can enable downstream access to internal systems. |
| Recommendation — Map MCP server reach to credential access and lateral movement paths in threat detection. | ||
| NIST Zero Trust (SP 800-207) | Policy enforcement and continuous verification | The article shows why sign-in alone is insufficient without ongoing policy checks on server reach. |
| Recommendation — Enforce continuous verification on MCP server connections rather than trusting initial approval alone. | ||
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.
- Shadow MCP: Shadow MCP is an unauthorized or ungoverned use of the Model Context Protocol inside an organization. It appears when AI agents, scripts, or tools connect to data or actions through MCP servers without security review, inventory, policy control, or monitoring. This creates hidden access paths, data exposure, and weak accountability.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Typosquatting: Typosquatting is the practice of naming a malicious package so it looks like a legitimate dependency with a small spelling change. In software supply chains, the goal is to get developers or automation to install attacker code before provenance or behaviour checks catch the deception.
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 27, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org