TL;DR: MCP adoption is moving from experimentation to enterprise infrastructure, and Obot argues that the real challenge is governance: access control, auditing, and policy design around reusable MCP servers that can expose apps and data to LLMs, AI agents, and chat users. The identity lesson is that MCP becomes an NHI governance problem as soon as non-technical users can assemble powerful workflows with their own privileges.
At a glance
What this is: Obot argues that enterprise MCP adoption is becoming an identity governance problem because reusable MCP servers let more users assemble powerful workflows around existing application and data access.
Why it matters: IAM, IGA, PAM, and NHI teams need to treat MCP as governed infrastructure, because discovery, policy, audit, and access boundaries now determine whether AI-enabled workflows stay within approved privilege.
Context
Model Context Protocol is a standard layer for exposing applications and data to LLMs, AI agents, and chat users through reusable servers. The governance issue is not the protocol itself but the way it lets more people compose powerful workflows on top of existing access rights.
For identity teams, the important shift is that enterprise MCP behaves like an access fabric rather than a single application integration. That makes policy design, entitlement scope, auditability, and controlled onboarding part of the MCP operating model from the start.
The article’s central claim is that organisations need an enterprise MCP strategy before adoption becomes fragmented across departments. It frames the current state as early but accelerating, which is typical of emerging control planes that quickly become shared infrastructure.
Key questions
Q: Where does enterprise MCP governance fail in practice?
A: It fails when reusable servers are treated as simple integrations rather than shared access surfaces. At that point, ownership, privilege scope, reuse approval, and audit logging fragment across teams, and no one can reliably say who can publish a workflow or what downstream actions it can trigger.
Q: Why do public MCP servers create risk for enterprise identity programmes?
A: Because they extend trust into third-party tool endpoints that may be poorly maintained, over-permissioned, or carrying embedded secrets. That creates an NHI and agentic control problem at the point where machines decide what to do next, which is exactly where traditional approval models are weakest.
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.
Q: What should organisations do before MCP becomes widely adopted?
A: Establish a central policy for discovery, publication, monitoring, and review before the number of servers grows. Once MCP becomes a shared layer across chat tools, agents, and applications, late-stage governance is harder because the access paths are already embedded in daily work.
Technical breakdown
Why reusable MCP servers change the access model
MCP servers are reusable integration layers that let a client, chat interface, or agent invoke approved tools against applications and data. The security shift is that the server becomes a governed interface for many workflows, not a one-off script tied to one app. Once users can combine MCP building blocks across systems, the access question moves from “can this integration call an API?” to “what privilege does this workflow inherit, and who approved it?” That is why MCP belongs in identity governance, not just platform engineering.
Practical implication: Treat each MCP server as a governed access surface with explicit ownership, scope, and approval boundaries.
Why non-technical users create governance pressure
The article’s most important operational point is that non-technical users can build useful workflows while using their own identity and access privileges. That removes the old assumption that only developers or specialists can expose sensitive capability through integrations. When business users can assemble reusable MCPs, entitlement sprawl can appear at the workflow layer even when the underlying apps remain controlled. Identity governance must therefore track who can create, publish, connect, and reuse these servers, not just who can log into the source application.
Practical implication: Define who may create, reuse, and approve MCP servers before broad self-service access is opened.
How enterprise MCP becomes a policy and audit problem
Once MCP adoption scales, the hard problems become access control, usage tracking, auditing, compliance, and centralised management. That is effectively a control plane problem: without consistent policy enforcement, each team can define its own integration boundary and its own review process. The article’s gateway model reflects this reality by separating user discovery from administrator governance. In identity terms, that means you need a single place to govern entitlements and record interactions across reusable MCP assets.
Practical implication: Centralise policy enforcement and audit logging for MCP servers before usage fragments across teams.
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
Enterprise MCP is becoming a governance layer, not just an integration layer. The article is right to move the discussion away from isolated tooling and toward policy, audit, and ownership. Reusable MCP servers turn access into a shared service that can be consumed by many users and clients, which means identity teams must govern the server as infrastructure. The practitioner conclusion is that MCP needs lifecycle control from day one, not after adoption scales.
Non-technical users change the risk profile because privilege now travels through workflows. The important shift is not that more people can use AI tools, but that they can assemble higher-impact actions while inheriting their own access rights. That creates a governance problem at the composition layer, where approved capabilities can be chained into outcomes nobody reviewed as a whole. The practitioner conclusion is to govern workflow reuse as tightly as application access.
The named concept here is enterprise MCP sprawl: modular servers multiplied faster than governance can follow. This is not just shadow IT in a new form. It is the gradual expansion of a reusable control surface that can outgrow ownership, auditability, and entitlement clarity if it is allowed to emerge ad hoc. The practitioner conclusion is to treat server sprawl as an identity architecture issue, not an enthusiasm problem.
MCP exposes the same control tension seen in NHI programmes: scale increases before accountability does. Reusable access primitives are valuable because they reduce friction, but they also widen the blast radius when permissions, logging, and review are inconsistent. That makes the discipline familiar to identity teams even if the technology is new. The practitioner conclusion is to apply identity governance to MCP the same way it is applied to other non-human access surfaces.
The article signals a market move toward governed AI access platforms rather than isolated connectors. That direction matters because enterprises rarely succeed with distributed control ownership once a capability becomes shared infrastructure. The likely winning operating model is central policy with delegated publishing, not uncoordinated server creation. The practitioner conclusion is to design for federation of use, not federation of governance.
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
Enterprise MCP sprawl: reusable servers can multiply faster than governance unless publishing, reuse, and audit are controlled as one operating model. That is why identity teams should plan for MCP as a governed access layer, not a point integration.
The practical question is whether your current IAM and IGA processes can see workflow composition, not just application login. If they cannot, MCP adoption will create privileged business actions that sit outside ordinary certification cycles and access review evidence.
The right operating model is a central policy plane with controlled delegation for server creation. That preserves business agility without letting reusable non-human access patterns outrun ownership and accountability.
For practitioners
- Define MCP server ownership and approval Assign a named business and security owner for every MCP server, with explicit approval for publication, reuse, and privilege scope. Do not allow servers to be shared before the owner, purpose, and review cadence are recorded.
- Classify MCP servers by access risk Group servers by the sensitivity of the underlying apps and data they can reach, then apply stricter review and monitoring to servers that can trigger writes, approvals, or cross-system actions.
- Centralise audit logging for MCP interactions Record which user, client, or agent invoked which server, what action it requested, and which downstream systems were touched, so investigations can reconstruct the full workflow path.
- Limit self-service server reuse Separate the ability to discover approved MCP servers from the ability to publish new ones, and require review before a server can be reused across departments or toolchains.
- Review privileges at the workflow level Check whether a reusable MCP composition can combine otherwise acceptable entitlements into an unapproved business action. If it can, the composition needs its own control, not just app-level approval.
Key takeaways
- MCP shifts the control problem from isolated app integration to governed workflow composition.
- Reusable servers and self-service access can create entitlement sprawl even when source applications remain controlled.
- Identity teams should establish ownership, policy, and audit boundaries before MCP becomes embedded in daily business work.
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 CSF 2.0 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-05 — Overprivileged NHI | Reusable MCP servers can concentrate excessive privilege across many workflows. |
| NHI-10 — Human Use of NHI | Business users can now create workflows that exercise non-human access through their own privileges. | |
| Recommendation — Limit each MCP server to the smallest action scope required for its approved business use. Separate human intent from machine-executed capability and govern the resulting access path explicitly. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Scaled MCP reuse can turn legitimate privilege into broader cross-system movement. |
| Recommendation — Map reusable MCP workflows to credential access and lateral movement paths in your detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP governance depends on controlling who can publish, connect, and reuse server capabilities. |
| Recommendation — Apply entitlement controls to MCP publishing, reuse, and downstream action scope. | ||
| NIST Zero Trust (SP 800-207) | Least privilege principle — Least privilege principle | MCP servers act as a shared access layer that should remain constrained by zero trust principles. |
| Recommendation — Bind MCP access to least-privilege principles and verify every server connection before use. | ||
Key terms
- 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.
- 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.
- Workflow Composition: The act of combining multiple approved capabilities into a larger business process. In identity governance, composition matters because each step may be individually permitted while the full workflow produces a higher-risk action that was never reviewed as a whole.
- Enterprise MCP Strategy: The operating model for deciding who can create, publish, connect to, monitor, and retire MCP servers at scale. It sits at the intersection of IAM, IGA, and platform governance because it defines how reusable non-human access is controlled across the business.
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 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org