MCP server security exposes the gap in identity governance

At a glance

What this is: This analysis shows that MCP server security is now an identity governance problem, not just an application integration issue, because discovery, consent, and delegated access are all weak points.

Why it matters: IAM, PAM, and NHI teams need to treat MCP servers as governed identities because unapproved tools can gain access that traditional sign-in logs and consent screens do not fully explain.

By the numbers:

• UpGuard counted 3 to 15 unverified lookalikes per legitimate brand, roughly 10–16% of servers examined.

👉 Read Unixi's analysis of MCP server security and identity governance

Context

MCP server security is emerging as an identity governance issue because the protocol turns tool access into a reusable, discoverable contract between an AI host and external systems. That changes the control problem from one-off API integration to governed delegation across databases, repositories, and internal APIs, which is exactly where NHI oversight becomes unavoidable.

The enterprise risk is not limited to approved servers. Shadow MCP, typosquatting, and silent post-approval change create a gap between what identity logs show and what a model can actually reach. That gap matters because access is not just being granted, it is being delegated to software that can select tools at runtime.

Key questions

Q: What breaks when MCP servers are approved once but allowed to change later?

A: The original approval no longer describes the current access surface. If tools, backends, or ownership change after onboarding, the enterprise is operating on stale risk information. That creates blind spots in authorization, logging, and recertification, because the governing record reflects a past state rather than the server’s present capabilities.

Q: Why does MCP change identity governance for AI applications?

A: MCP turns AI connectors into standardized access paths to tools and data, which means every server becomes a governed entitlement surface. The governance challenge is less about connecting systems and more about bounding what an AI client can reach, when it can reach it, and who is accountable for the action.

Q: How do security teams detect shadow MCP access in practice?

A: They correlate client configuration, registry data, and network telemetry to identify servers that were installed outside approved workflows. The key signal is a valid connection that exists without an approval record, owner, or business justification. If the server is reachable but not governed, it should be treated as exposed delegated access.

Q: Who is accountable when an MCP server authorises the wrong action?

A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.

Technical breakdown

How MCP server discovery creates identity risk

MCP standardises how a host discovers and calls a server, but that same consistency makes lookalike registries and weak verification more dangerous. The server publishes metadata, tools, resources, and prompts in a machine-readable shape, so the host can treat a malicious entry as structurally valid. In identity terms, the problem is not authentication alone, but whether the discovered server is the one the enterprise intended to trust.

Practical implication: Treat server discovery as an onboarding control point and require explicit approval before any MCP server can be registered in production.

Why tool metadata becomes an attack surface

MCP hosts pass tool descriptions into the model as trusted context, which means the metadata itself can steer behaviour. If a tool description contains hidden instruction content, the model may follow it even when the tool performs its normal function. A related failure is the rug pull, where a trusted server changes server-side after review while keeping the same name and version, breaking the assumption that approval remains valid.

Practical implication: Review MCP tool metadata and version drift as governance artefacts, not just developer documentation.

What EMA changes and what it does not

Enterprise-Managed Authorization shifts consent from the browser into the identity provider and makes delegation more attributable through token exchange. That improves attribution and reduces consent prompting, but it does not solve invisible local servers or later token use that bypasses the IdP. The result is a narrower authorization layer, not complete lifecycle control over the full server inventory.

Practical implication: Use EMA as part of a broader control stack, but do not assume it replaces discovery, revocation, or runtime monitoring.

Threat narrative

Attacker objective: The attacker wants trusted delegated access to internal systems without triggering the visibility or approval controls that normally govern identity.

1. Entry occurs when a user installs a convincing lookalike MCP server from a registry, repository, or search result, or when an attacker-controlled tool is selected by mistake from a list.
2. Escalation follows when the server’s metadata, prompts, or delegated access are trusted by the host and used to reach databases, repositories, or internal APIs beyond the user’s intended scope.
3. Impact is the exposure of corporate data, unauthorized tool invocation, or persistent delegated access that remains outside inventory and lifecycle governance.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• 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

Shadow MCP servers create a governance blind spot, not just a supply-chain risk. The enterprise can have clean authentication logs and still have no idea which model-connected servers were installed, what they can reach, or who approved them. That makes MCP inventory a lifecycle problem as much as a security one, because unapproved servers are identities with reach until they are discovered and removed.

Typosquatting is an identity attack on the server itself. The issue is not merely a fake package name. It is the fact that selection happens in a trust context where the model or user may choose from a list that looks plausible, while enterprise approval and verification are absent. Practitioners should read this as a failure of identity assurance at the point of delegation, not a branding problem.

Enterprise-Managed Authorization improves attribution, but it does not solve the full delegated-access lifecycle. Consent moved into the IdP, tokens became more bounded, and issuer checks got stricter. But local servers, child processes, and post-approval behavior change still sit outside that model, which means token issuance can be governed while actual server reach remains partially invisible.

Invisible delegated access is the named concept practitioners should track. The IdP can record a sign-in while a third-party AI client or MCP server quietly gains standing reach on behalf of the user. That breaks the assumption that an identity event in the IdP equals governed access in the target system. The implication is that identity programmes need connection-level inventory, not just login telemetry.

MCP security is pushing NHI governance into the same operating model used for human and machine lifecycle control. The question is no longer whether a server exists, but whether it is approved, discovered, scoped, and revocable across its full life. That is the same governance pattern the industry already uses for service accounts and tokens, now applied to AI-connected servers.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree that governing AI agents is critical to enterprise security.
• That gap makes the case for Ultimate Guide to NHIs more practical than theoretical when access moves from humans to software delegates.

What this signals

Invisible delegated access is the operating risk teams will keep missing if they only track authentication events. As AI-connected servers proliferate, the governance question shifts to whether every connection is approved, attributable, and revocable across its full lifecycle.

With 70% of organisations already granting AI systems more access than human employees, per The 2026 Infrastructure Identity Survey, MCP governance is no longer a niche integration concern. It is part of the broader move toward identity controls that can handle machine-led delegation and post-approval drift.

Teams that already manage service accounts, API keys, and third-party access can adapt those controls to MCP faster than teams starting from scratch. The practical test is whether discovery, approval, and revocation all happen in the same control plane, rather than in separate developer and security workflows.

For practitioners

• Inventory every MCP server connection Build a complete register of approved, shadow, and local MCP servers, including the host, connected resources, and owner for each entry.
• Gate server adoption before authorization Require explicit approval for any new MCP server before it can be added to a client config, registry, or enterprise host.
• Review tool metadata for hidden behavioural changes Compare tool descriptions, prompts, and version history at every reapproval point so a rug pull cannot reuse an unchanged name as cover.
• Scope delegated access by server and audience Bind tokens and authorization grants to one server, one audience, and one business purpose so a leaked credential cannot be reused elsewhere.
• Pair discovery with lifecycle revocation Withdraw access when a server is no longer approved, no longer used, or no longer owned, and include third-party grants in offboarding checks.

Key takeaways

• MCP server security is an identity governance problem because the server itself can become a delegated access path to internal systems.
• The biggest failure mode is invisible delegated access, where logs show a user sign-in but not the server-level reach that follows.
• Practitioners need server inventory, approval gates, audience scoping, and lifecycle revocation before MCP adoption scales further.

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.
• 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.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Enterprise-Managed Authorization: Enterprise-managed authorization is a policy model in which the identity provider decides what an agent may do and encodes that decision into the token or access flow. It helps organisations keep control logic centralized instead of spreading entitlement decisions across many servers.

What's in the full article

Unixi's full research covers the operational detail this post intentionally leaves for the source:

• Registry-by-registry comparison of verification levels and lookalike risk, useful for procurement and approval workflows.
• Implementation detail on Enterprise-Managed Authorization, including token exchange and issuer validation mechanics.
• Reproducible examples of tool poisoning, rug pulls, and pre-consent exposure paths for lab validation.
• Control-by-control mapping of access management, discovery, risk analysis, and lifecycle management across the MCP stack.

👉 The full Unixi article covers the attack patterns, authorization model, and control breakdowns in more depth.

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 identity controls that need to work across human, machine, and AI-driven access, it is worth exploring.