Notifications
Clear all
Topic starter
27/08/2026 8:35 am
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.
NHIMG editorial — based on content published by Unixi: MCP server security and identity governance across discovery, consent, and delegated access
By the numbers:
- UpGuard counted 3 to 15 unverified lookalikes per legitimate brand, roughly 10–16% of servers examined.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Unixi's analysis of MCP server security and identity governance →
MCP server security: what identity teams are missing?
Explore further
27/08/2026 8:35 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server security exposes the gap in identity governance
