Topic starter
19/08/2026 3:41 pm
TL;DR: Fifty percent of organisations are experimenting with MCP servers while only 11% have reached production, Stacklok reports, leaving governance far behind adoption. MCP servers need per-user identity, secret control, approval, and auditability before they can safely reach enterprise systems.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “The Enterprise IT Security Guide to Claude and MCP”.
By the numbers:
- 48% of MCP servers use insecure credential storage according to Trend Micro research.
- 53% rely on long-lived static credentials per Astrix.
- Eight out of ten Fortune 10 companies now use Claude.
Key questions
Q: Why does MCP create less risk than long-lived CLI credentials in enterprise environments?
A: MCP can reduce risk because it supports OAuth-based, revocable, scoped tokens rather than long-lived API keys or user credentials baked into files.
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: What breaks when MCP servers rely on a single shared credential?
A: A single shared credential breaks attribution, scope control, and revocation precision.
Practitioner guidance
- Implement centralised secrets storage for MCP servers Store all downstream credentials in a managed secrets platform and retrieve them at runtime instead of embedding them in config files or source code.
- Require per-user identity for every tool invocation Tie MCP access to the organisation’s IdP so audit logs identify the user, the tool, and the server involved in each action.
- Curate an approved MCP server registry Allow only reviewed servers that have clear ownership, documented permissions, and an explicit revocation path when a server is no longer needed.
Bottom line: Claude is not the primary governance problem. The control issue sits in the privileged MCP servers that can reach enterprise systems on the model’s behalf.
Glossary terms: MCP server governance, Identity Binding, Credential Blast Radius, Approved Server Registry
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 20 hours ago by NHI Mgmt Group
19/08/2026 4:20 pm
Claude is not the control problem; delegated MCP access is. The article correctly shifts attention away from the model and toward the privileged software layer that Claude can use to reach enterprise systems. That is the right governance lens because the real blast radius comes from what the MCP server can authenticate to, modify, or expose. Practitioners should assess Claude deployments as access pathways, not as chatbot deployments.
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: How do teams decide whether MCP access can share enterprise IAM controls?
A: They should test whether their identity stack supports client registration, token exchange, and scoped authorization without broadening trust by default. If MCP flows require exceptions outside normal IAM policy, the team needs a separate governance pattern for AI tool access rather than assuming standard SSO is enough.
👉 Read our full editorial: MCP server governance, not Claude, is the security bottleneck
This post was modified 20 hours ago by NHI Mgmt Group