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.
At a glance
What this is: This is a governance analysis of Claude and MCP that shows the main risk sits in action-capable MCP servers, where weak secrets handling, shared credentials, and poor oversight turn AI access into enterprise access.
Why it matters: IAM, PAM, and NHI teams need to govern MCP servers as privileged software components because their credentials, permissions, and audit trails determine enterprise blast radius.
By the numbers:
- 50% of organisations are actively experimenting with MCP servers, yet only 11% have reached production.
- 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.
Context
Claude and MCP are not just another SaaS integration pattern. In this article, Stacklok argues that the governance problem starts when an AI-connected workflow can authenticate, query, modify, and trigger actions across enterprise systems through MCP servers that hold real credentials and real permissions.
The key question for identity teams is not whether Claude can generate useful output, but whether the MCP servers behind it are being governed like privileged software. That means treating secrets, identity, logging, network reach, and approved-server policy as first-class controls rather than implementation details.
This is a mature enterprise problem, not a theoretical lab scenario. The article frames MCP as a distinct security boundary because once an MCP server can act on behalf of users, the effective risk model shifts from model usage to delegated access governance.
Key questions
Q: What breaks when MCP servers rely on a single shared credential?
A: A single shared credential breaks attribution, scope control, and revocation precision. If the server can be used by multiple people, you cannot easily tell which human authorised a specific action, and removing the credential can disrupt unrelated workflows. That makes the credential both operationally convenient and governance-heavy.
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. That matters when employees change roles, machines are exposed, or agent access must be limited. CLI setups usually lack that control layer, so compromise can translate into broad, persistent access with weak visibility and weak revocation.
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: 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.
Technical breakdown
Why MCP servers change the Claude attack surface
MCP servers are action-capable intermediaries, not passive context feeds. They can authenticate to downstream systems, read data, write data, and invoke tools with the authority carried by their credentials. That means the security boundary is no longer the model prompt alone, but every system the server can reach and every permission attached to the server’s identity. In practical terms, an MCP deployment behaves like a privileged integration layer with AI in front of it, which makes identity, secrets, and tool scope the real control points.
Practical implication: govern each MCP server as a privileged software component with explicit scope, not as a harmless extension of the model.
Secrets management is the first governance failure point
The article shows that many MCP deployments still store credentials in JSON files, environment variables, or source code, which is structurally incompatible with enterprise control. When downstream keys are embedded in developer workstations or committed to repositories, rotation becomes slow, revocation becomes uncertain, and compromise persists beyond the original exposure. Centralized secrets storage changes the operating model by making credentials retrievable at runtime rather than inherited from files that developers can copy, cache, or leak. That distinction matters because AI-connected tooling multiplies the number of places secrets can drift.
Practical implication: move MCP credentials into a managed secrets store and remove file-based credential storage from approved deployment patterns.
Per-user identity and auditability are missing in shared MCP access
The article’s strongest identity point is that shared service accounts collapse attribution. If every developer’s agent uses the same MCP credential, the audit log can show which server was invoked, but not which person initiated the action or why. That breaks least privilege, revocation, and accountability at the same time. Once an enterprise moves to SSO-backed per-user identity, the governance model can distinguish user intent from shared infrastructure access, which is essential when the same server can read, write, or trigger changes in multiple systems.
Practical implication: require per-user authentication and tool-level attribution before allowing MCP access to production systems.
Threat narrative
Attacker objective: The attacker objective is to turn a developer-facing AI integration into broad enterprise access by abusing the permissions and credentials attached to MCP servers.
- Entry occurs when developers connect Claude to MCP servers that expose downstream systems through shared credentials or unvetted server packages.
- Credential access follows when secrets are stored in config files, environment variables, or source code, making them easy to leak or reuse.
- Escalation and lateral movement occur when an attacker or compromised server uses those permissions to reach databases, APIs, cloud services, or developer tools.
- Impact is enterprise-level action through the delegated identity, including data access, repository changes, email, or cloud-side operations under valid permissions.
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
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.
MCP introduces a new privileged boundary that current enterprise controls often do not recognise. The article’s strongest contribution is its framing of MCP as a distinct security boundary with policy, oversight, and operational discipline requirements. That matters because many IAM and PAM programmes still assume integrations are static, well-reviewed, and attribution-rich, while MCP implementations can be rapidly assembled by developers before security review catches up. Practitioners need to govern server registration, credential lineage, and approved tool scope as one control plane.
Shared credentials create identity ambiguity that enterprise governance cannot tolerate. When every user’s agent shares the same MCP account, least privilege becomes an aspiration rather than an enforceable state. Offboarding, incident response, and audit all degrade because the organisation cannot prove who caused which action. The implication is not just stricter access control, but a different trust model in which per-user identity must survive the AI mediation layer.
Secrets sprawl and long-lived credentials are the compound risk in AI-connected workflows. The article points to a familiar NHI pattern with a sharper edge: credentials are easy to embed, hard to rotate, and frequently granted broader reach than the workflow actually needs. In other words, the AI layer does not create a new credential problem so much as it accelerates the old one into production. Practitioners should treat every MCP server secret as a governed NHI asset with ownership, rotation, and revocation.
Approved-server governance is now a supply chain control, not a convenience feature. An MCP ecosystem with thousands of community servers makes trust decisions operational, not theoretical. Once developers can install servers without central review, the organisation has effectively outsourced access design to individual users. That is why curated registries, signed artefacts, and policy enforcement belong in the same conversation as identity governance and logging.
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
Governance starts at issuance, not at review. Access reviews assume a privilege persists long enough to be certified. MCP servers often acquire credentials at setup time and can reuse them immediately, which means the control point has to move upstream to server approval, secret issuance, and runtime identity binding.
Ephemeral or shared tool identities create an identity blast radius problem. Once an MCP server can act across multiple enterprise systems, the question is no longer whether Claude can answer safely. It is whether each server has a bounded identity, a bounded egress path, and a bounded set of tools that can be revoked without breaking unrelated workflows.
MCP adoption will keep exposing hidden secrets unless organisations redesign the operating model. Stacklok’s State of Secrets Sprawl 2026 found 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which is a strong signal that the default developer pattern is already too leaky for enterprise use. That figure reinforces the need for secrets scanning, central storage, and approval gates before production rollout.
For practitioners
- 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.
- Enforce network isolation for each server Bind production servers to restricted network paths, prevent broad egress, and keep untrusted servers away from internal systems they do not need.
- Mandate rotation for high-value API keys Apply scheduled rotation to the Anthropic API key and downstream system credentials, with emergency rotation procedures for suspected compromise.
Key takeaways
- 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.
- Shared credentials, insecure secret storage, and weak server governance collapse attribution and extend the blast radius of any compromise.
- Enterprises should govern MCP like any other privileged integration layer, with per-user identity, secret lifecycle control, server approval, and auditability.
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 CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed MCP credentials in config files and environment variables. |
| NHI-04 — Insecure Authentication | Shared service accounts and weak identity binding are a core control failure in the article. | |
| NHI-07 — Long-Lived Secrets | The article highlights static credentials that persist without rotation across MCP deployments. | |
| Recommendation — Scan MCP configurations for exposed secrets and eliminate file-based credential storage. Bind MCP access to per-user authentication and remove shared server credentials. Rotate MCP and downstream credentials on a fixed schedule and shorten secret lifetime. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP governance depends on scoped entitlements and revocable approvals. |
| Recommendation — Define and enforce least-privilege permissions for each MCP server and tool. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes credential theft and downstream reach through privileged MCP servers. |
| Recommendation — Map MCP credential exposure to credential-access and lateral-movement detections in monitoring. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article focuses on cloud-style identity controls for AI-connected enterprise access. |
| Recommendation — Apply IAM governance to MCP server identities, tokens, and approval workflows. | ||
Key terms
- MCP server governance: MCP server governance is the set of policies, controls, and oversight used to manage how a Model Context Protocol server exposes tools, data, and actions to AI agents. It defines authentication, authorization, logging, change control, and risk review so agent access remains traceable, limited, and aligned with security and compliance requirements.
- Identity Binding: The process of linking an external credential or login method to an internal account record. Strong binding prevents duplicate accounts, broken recovery paths, and unsafe merges when users authenticate through different identity sources or wallet-based credentials.
- Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
- 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.
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.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org