Notifications
Clear all
Topic starter
19/08/2026 3:41 pm
TL;DR: Fifty percent of organizations are experimenting with MCP servers while only 11% have reached production, exposing a 39-point governance gap, according to Stacklok. The central issue is not Claude itself but the privileged, action-capable MCP servers behind it, where insecure secret storage, shared credentials, and weak oversight turn AI access into enterprise access.
NHIMG editorial — 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 methods such as plaintext JSON config files, .env files, and hardcoded values in source code.
- 53% of MCP server deployments rely on long-lived static credentials.
Questions worth separating out
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: Why do shared credentials create so much risk in MCP deployments?
A: Shared credentials erase accountability and make containment harder because every tool call appears to come from the same identity.
Q: What breaks when MCP credentials are hard coded?
A: Hard-coded credentials break lifecycle control.
Practitioner guidance
- Centralize MCP server secrets Move downstream credentials for MCP-connected systems into a managed secrets platform and prohibit storage in config files, source code, or environment files.
- Require per-user authentication for tool access Tie every MCP invocation to an organizational identity through SSO so audit logs and revocation actions map to the real user, not a shared service account.
- Create an approved server registry Allow only reviewed MCP servers into production and block ad hoc installs so developers are not independently deciding which privileged integrations can reach enterprise systems.
What's in the full article
Stacklok's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step control mapping across secrets management, network isolation, logging, and policy enforcement
- Concrete examples of server governance patterns for Claude Desktop, Claude Code, and enterprise MCP gateways
- Implementation details for tool-level RBAC, authenticated proxying, and approved server registries
- Practical guidance on how the CIS MCP Companion Guide maps to enterprise deployment decisions
👉 Read Stacklok's enterprise guide to Claude and MCP security controls →
Claude and MCP security: are enterprise controls keeping up?
Explore further
19/08/2026 4:20 pm
Claude and MCP are widening the identity boundary, not just the AI boundary. The article shows that enterprises are already allowing action-capable servers to reach production systems through privileged credentials. That means identity governance now has to cover the server, the downstream system, and the delegated human identity behind the workflow. The practitioner conclusion is simple: if the server can act, it must be governed like any other privileged identity component.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the same study.
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: Claude and MCP security is a governance problem, not a model problem
