Why do unmanaged MCP servers create security risk in Claude Code and similar agentic workflows?

Unmanaged MCP servers create risk because they can introduce unreviewed tools, uncontrolled credentials, and opaque data flows into agent execution. When developers copy servers from informal sources, security teams lose visibility into what the agent can call, what secrets it can reach, and whether the server aligns with policy. That weakens least privilege and increases the blast radius of misuse.

Why This Matters for Security Teams

Unmanaged MCP servers are risky because they turn an agent workflow into a plug-in ecosystem with weak governance. In Claude Code and similar agentic environments, a server can add tools, expose secrets, or relay data outside approved paths without the visibility security teams expect from standard application controls. That creates a control gap between what the agent is allowed to do in theory and what it can reach at runtime.

This is not a hypothetical edge case. NHIMG research on The State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files. That matters because an agent does not need human curiosity to misuse exposed access, only a toolchain that can chain calls faster than reviewers can inspect them. The broader agentic risk picture is consistent with OWASP Agentic AI Top 10, which treats tool abuse, excessive authority, and unsafe orchestration as first-class threats.

Security teams often assume the MCP server is just infrastructure, but in practice it becomes part of the agent’s identity and access plane. In practice, many security teams encounter data exposure only after an agent has already called an unreviewed server, not during deliberate tool onboarding.

How It Works in Practice

The practical risk is that MCP servers can expand an agent’s effective privileges in ways that are hard to see from the outside. An agent such as Claude Code may discover a server, inherit its tools, and then combine those tools with other connectors to read files, query systems, or move data. If the server is unmanaged, security teams may not know whether the tools were vetted, whether credentials are scoped, or whether the server is sending prompts and outputs to a third party.

Best practice is evolving toward treating MCP servers like privileged workloads, not casual developer add-ons. That means reviewing the server’s tool catalog, enforcing allowlists, constraining credentials to the smallest useful scope, and requiring short-lived secrets where possible. The operational goal is to reduce standing access and make every tool call traceable to a policy decision at runtime. Guidance from CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework both point toward continuous governance, not one-time approval.

• Inventory every MCP server and tie it to an owner, purpose, and approved tool scope.
• Review configuration files for embedded secrets, hard-coded endpoints, and undocumented network paths.
• Use workload identity and short-lived credentials so access expires with the task, not the developer machine.
• Log tool invocation, data access, and downstream actions so audit teams can reconstruct agent behaviour.

NHIMG’s Analysis of Claude Code Security shows why this matters: the workflow can look like a coding assistant while operating like an autonomous operator with broad execution reach. These controls tend to break down when teams allow self-serve MCP servers in fast-moving developer environments because ownership, review, and revocation lag behind deployment.

Common Variations and Edge Cases

Tighter MCP control often increases friction for developers, requiring organisations to balance speed against the need for provable tool governance. That tradeoff is real, especially in teams that depend on rapid experimentation or internal prototypes. Current guidance suggests the right answer is not blanket prohibition, but tiered approval based on data sensitivity, tool reach, and credential scope.

There is no universal standard for MCP server governance yet, so edge cases matter. A local-only server used for single-user development may pose less risk than a shared server that can reach production APIs, but the latter can still become dangerous if the agent can chain tool calls or inherit broad filesystem access. This is where unmanaged servers intersect with broader NHI failures documented in NHIMG’s Top 10 NHI Issues: static credentials, unclear ownership, and weak lifecycle controls. For implementation detail, NIST Cybersecurity Framework 2.0 remains useful for mapping inventory, access control, and monitoring to operational controls.

In practice, the hardest cases are managed-by-the-user environments where engineers can add MCP servers faster than security can classify them. That is where policy-as-code, signed configuration, and per-task credential issuance become more important than manual reviews alone.

Related resources from NHI Mgmt Group

• Why do AI-generated MCP tools and agent workflows create a different security risk than ordinary application code?
• How do sandboxed MCP servers still create security risk?
• When do agentic code workflows create more risk than they reduce?
• Why do AI copilots and MCP servers create data security risk beyond ordinary SaaS usage?