Claude and MCP security is a governance problem, not a model problem

At a glance

What this is: This is a governance guide to Claude and MCP that shows why action-capable MCP servers create a broader enterprise identity and access control problem than a chat interface alone.

Why it matters: It matters because IAM, PAM, and NHI teams need to govern the credentials, approvals, logging, and network reach of MCP servers as privileged software components.

By the numbers:

• 50% of organizations are actively experimenting with MCP servers, yet only 11% have reached production.
• 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.

👉 Read Stacklok's enterprise guide to Claude and MCP security controls

Context

Claude and MCP are creating an identity governance problem because the thing being governed is not a chatbot, but a set of privileged software components that can act on enterprise systems. In the Claude and MCP model, the MCP server becomes the access path into production data, SaaS tools, and internal APIs, which means security teams are approving machine-to-system access rather than a simple user productivity feature.

The gap is clear in the deployment pattern: development experimentation is advancing faster than enterprise controls, while credential storage, shared access, and logging models still look like legacy integration patterns. For IAM and NHI programmes, that mismatch is the real risk, because the governance boundary shifts from the model to the server, the credentials it holds, and the permissions it can exercise.

This is typical of early AI adoption in enterprise environments: the technology arrives before the control plane does. The article’s starting position is therefore typical, not exceptional.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

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. In practice, that means one leaked key can expose multiple users, multiple agents, and multiple tools at once. Request-level identity is what preserves auditability and lets teams scope access correctly.

Q: What breaks when MCP credentials are hard coded?

A: Hard-coded credentials break lifecycle control. They are difficult to scope, hard to rotate, and easy to reuse across tools or environments, which means the same secret can outlive the team or use case that created it. In an MCP context, that creates a standing access path that is far broader than the interface suggests.

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.

Technical breakdown

Why MCP servers expand the privileged attack surface

MCP, or Model Context Protocol, connects an AI system to tools and data sources through a server that can authenticate and execute actions on the user’s behalf. That server is not passive context delivery. It can read from databases, write to SaaS platforms, create pull requests, and call cloud APIs if the connected credentials allow it. The architectural shift matters because the risk is no longer limited to prompt quality or model output. The privileged component is the server, its credential set, and the systems it can reach.

Practical implication: treat each MCP server as a privileged integration that needs explicit approval, scoping, and monitoring.

Why secrets management fails in default MCP deployments

Default MCP documentation often places credentials in JSON files, environment variables, or source-controlled config. That pattern is structurally weak because the credentials outlive the session, are hard to scope per user, and are easy to copy into developer workflows. The result is standing access hidden inside tooling. When the same token is reused across multiple operators or environments, a compromise of one path becomes a compromise of all paths that share it.

Practical implication: move MCP credentials into centrally managed secrets stores and remove them from developer configuration files.

How identity and access control break when MCP uses shared credentials

A shared MCP service account collapses per-user attribution. The audit trail shows that the MCP server acted, but not which developer’s workflow initiated the action or on whose authority. That destroys least privilege, makes revocation coarse-grained, and weakens offboarding because removing one person often requires rotating a shared credential for everyone. This is an identity governance failure, not just a logging gap, because the entitlement model no longer maps cleanly to the actual actor.

Practical implication: require per-user SSO, scoped tokens, and a revocation path for each authenticated developer identity.

NHI Mgmt Group analysis

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.

Standing credential exposure is the core failure mode in today’s MCP deployments. The source highlights insecure storage patterns and long-lived static credentials as the dominant weak points, which is exactly how NHI risk accumulates in production. The named concept here is ephemeral credential trust debt: every temporary-looking integration that keeps persistent credentials creates future compromise exposure. The practitioner conclusion is that lifecycle control, not feature adoption, determines whether the deployment is governable.

Per-user attribution is no longer optional once an AI system can operate tools. Shared service accounts make it impossible to answer who invoked which tool, when, and for what purpose. That breaks both accountability and revocation, especially in offboarding scenarios. The practitioner conclusion is that tool access without identity continuity should be treated as a governance defect, not a convenience tradeoff.

The control plane now matters more than the model brand. The article is strongest when it frames MCP as a new security boundary that expands identity, access control, logging, and application security requirements. That is the right lens for the market as well: enterprises are buying a governance problem, not just an AI integration path. The practitioner conclusion is that control design, not model selection, will decide whether adoption remains manageable.

Enterprise AI adoption is creating an NHI problem before most IAM programmes are ready for it. MCP servers behave like privileged machine identities with delegated human intent, which places them squarely inside NHI governance. The implication is that IAM, PAM, and NHI teams need a shared operating model for approval, scoping, auditability, and revocation. The practitioner conclusion is to align AI rollout governance with existing identity controls instead of building a parallel exception process.

From our research:

• 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.
• Read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that make governed access possible.

What this signals

Claude and MCP should now be treated as an identity programme issue, not only an AI rollout issue. The control questions are the same ones NHI teams already ask about workload identities, service accounts, and API keys: who can authenticate, what can they reach, how are credentials rotated, and how quickly can access be revoked when the actor changes.

Ephemeral credential trust debt: The more an organisation normalises temporary-looking integrations with persistent credentials, the more it accumulates future compromise exposure. That is why the governance model should prefer short-lived, scoped access paths and central review points over local configuration sprawl.

For teams building the next control layer, the most useful external reference point is the OWASP Agentic AI Top 10, because it helps separate model behaviour from tool-use risk and gives security teams a shared vocabulary for identity, privilege, and delegation problems in agentic environments.

For practitioners

• 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.
• Enforce network isolation and egress limits Run each server in an isolated runtime and allow outbound access only to the specific backend systems the tools require, with authenticated gateways in front of remote servers.

Key takeaways

• Claude and MCP become an identity governance problem the moment a server can reach production systems through privileged credentials.
• Shared tokens, local config storage, and weak audit attribution are the main reasons current deployments remain hard to govern at scale.
• The practical fix is a control plane built around per-user identity, central secrets, approved servers, and constrained network reach.

Key terms

• 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.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Approved Server Registry: A controlled inventory of sanctioned integrations, connectors, or MCP servers allowed to operate in production. It turns tool approval into a governance process rather than an individual developer choice and creates a review point for permissions, provenance, and lifecycle control.

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

👉 The full Stacklok guide covers control mappings, deployment patterns, and governance details for enterprise Claude and MCP environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.