Topic starter
20/08/2026 5:24 pm
TL;DR: MCP makes it easy to connect AI clients to real tools, but Obot argues the hard part is management: OAuth handling, access control, discovery, audit logging, and ownership once servers spread across teams. That governance debt is already showing up as a scaling problem for IAM and security programmes.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “MCP Management: What Comes After Building the Servers”.
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.
Q: Why do remote MCP servers need role-based access control?
A: RBAC is necessary because authenticated users do not all need the same tool power.
Q: How do teams know whether MCP controls are actually working?
A: Teams know MCP controls are working when every tool invocation can be traced to a verified identity, a policy decision, and a recorded approval state where required.
Practitioner guidance
- Inventory all MCP servers Map every MCP server already running, identify its owner, and record what data and tools it can reach.
- Centralise OAuth token handling Move callback handling, refresh logic, and token storage into a controlled broker so individual servers do not manage raw credentials.
- Apply role-based access to tool exposure Tie server and tool access to existing identity groups so users only see the MCP functions their role allows.
Bottom line: MCP is easy to deploy, but unmanaged servers quickly create governance debt across access, discovery, and ownership.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:14 pm
MCP management is an identity governance problem before it is a platform problem: Once MCP servers proliferate across teams, the real risk is not whether the SDK works but whether access, ownership, and revocation remain controllable. The article shows that organisations quickly accumulate duplicate OAuth handling, weak visibility, and unclear service ownership. The practitioner conclusion is that MCP needs the same lifecycle discipline as any other access-bearing infrastructure.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: What happens when an MCP credential is compromised?
A: Without centralized revocation, a compromised credential can leave multiple servers exposed and difficult to contain. A managed MCP setup should make token invalidation immediate, visible, and tied to the identity that owns the access, not to each server individually.
👉 Read our full editorial: MCP management needs governance, access control, and ownership