The MCP Server Credential Crisis: Why Half of Agent Servers Are Insecure

The Model Context Protocol (MCP) has rapidly become the de facto standard for connecting AI agents to external tools and services. Anthropic's open protocol now powers thousands of integrations across coding assistants, enterprise workflows, and autonomous agent frameworks. But as the ecosystem has scaled, a systemic credential security crisis has emerged — one that threatens the entire foundation of agentic computing.

The numbers paint a stark picture: 48% of reviewed MCP servers recommend or implement insecure credential storage methods, according to research by Trend Micro. This isn't a fringe finding about obscure tools. This is nearly half of the infrastructure that AI agents rely on daily.

The OWASP wake-up call

When OWASP published its first MCP Top 10 vulnerability list, the #1 entry was unambiguous: MCP01:2025 — Excessive Agency / Token Mismanagement. This ranking places credential security above injection attacks, above tool poisoning, above every other category of MCP vulnerability.

The OWASP analysis identified a pattern repeated across the MCP ecosystem: servers that accept and store API tokens with excessive permissions, persist them without encryption, share them across multiple tools without scope restrictions, and provide no mechanism for rotation or revocation. The result is an attack surface that grows with every new MCP integration.

This isn't theoretical. OWASP documented real-world scenarios where compromised MCP servers provided attackers with lateral movement across entire cloud environments — all through mismanaged credentials that were never designed to be held by an intermediary protocol layer.

Thousands of servers, zero authentication

The exposure isn't limited to poor credential storage within servers. Security researchers at Astrix Security conducted an internet-wide scan and found approximately 1,862 to 2,000 internet-reachable MCP servers exposed with no authentication whatsoever. These servers were accepting connections from any client, executing tool calls without verifying identity, and in many cases, holding credentials for downstream APIs that could be accessed by anyone who connected.

Critical CVEs in core tooling

The credential crisis extends into the MCP ecosystem's most widely-used tools. Two critical vulnerabilities in 2025 demonstrated that even official and popular MCP infrastructure can serve as an attack vector for credential compromise.

• CVE-2025-6514A vulnerability in mcp-remote, an OAuth proxy for MCP servers with over 437,000 downloads, enabled command execution and credential compromise. The package, designed to bridge MCP clients with remote servers over OAuth, contained a flaw that allowed attackers to execute arbitrary commands on the host machine and access stored credentials. Given that mcp-remote is used precisely to handle authentication flows, the irony is bitter: the security layer itself became the vulnerability.
• CVE-2025-49596Anthropic's own MCP Inspector tool — a developer utility with over 38,000 weekly downloads — was assigned a CVSS score of 9.4 (Critical). The vulnerability allowed full workstation compromise, including access to all credentials stored on the developer's machine. An attacker exploiting this could harvest SSH keys, browser cookies, cloud provider credentials, and any secrets stored in environment variables or config files.

These aren't obscure libraries. mcp-remote and MCP Inspector are foundational tools in the MCP development workflow. When the infrastructure designed to facilitate secure connections is itself vulnerable, the entire security model collapses.

A new attack category: contextual secret leakage

Beyond traditional credential storage vulnerabilities, the MCP ecosystem has given rise to what security researchers are calling "contextual secret leakage" — a category of exposure unique to agentic systems.

Unlike traditional secret leaks (hardcoded credentials in source code, exposed environment variables), contextual secret leakage occurs through the normal operation of MCP servers:

• Config file embedding — MCP server configurations often include API keys, database URLs, and OAuth tokens in JSON or YAML files that get loaded into the server's context
• Prompt template injection — credentials embedded in prompt templates or system messages that are sent to the LLM as part of normal tool invocation
• Context memory persistence — credentials that persist in the model's context memory across multiple tool calls, remaining extractable long after the original authenticated request
• Environment variable leakage — MCP servers that read credentials from environment variables and pass them through tool responses visible to the agent

The insidious nature of contextual leakage is that it doesn't require a vulnerability in the traditional sense. The MCP server is working exactly as designed — the design itself is the problem. Credentials flow through the system's normal operation, becoming accessible to any entity with context access, including LLMs that might be manipulated through prompt injection.

The 48% problem: why servers get credentials wrong

Trend Micro's finding that 48% of MCP servers implement insecure credential practices isn't surprising when you understand the incentive structure. MCP server developers are optimizing for functionality and ease of integration — not credential security. The typical MCP server README includes instructions like:

These credentials are stored in plaintext config files, loaded into the server process, and accessible to any tool running within that server. There's no encryption at rest, no scoping mechanism, no rotation policy, and no audit trail. The MCP specification itself doesn't mandate any particular credential storage approach, leaving security entirely to individual server implementers — most of whom prioritize shipping features over securing secrets.

The architectural solution

The MCP credential crisis isn't solvable with better documentation or security guidelines. The problem is architectural: the current model requires MCP servers to hold and manage credentials, creating thousands of independently-secured (or unsecured) credential stores across the ecosystem.

The alternative is to remove credentials from MCP servers entirely. Instead of each server managing its own credential storage, route authenticated requests through a credential proxy that handles secrets server-side. The MCP server describes what capability it needs. The proxy handles authentication. The credential never touches the MCP server, the agent, or the LLM context.

The urgency of now

The MCP ecosystem is at an inflection point. Adoption is accelerating, with new servers published daily for every API and service imaginable. Each new server is another node in the credential trust network — and right now, nearly half of those nodes are insecure.

The combination of OWASP's #1 vulnerability ranking, thousands of exposed servers, critical CVEs in core tooling, and a new category of contextual leakage paints a clear picture: the MCP credential model is broken. It can be patched, hardened, and documented — but as long as credentials flow through MCP servers, the attack surface will continue to grow.

The MCP protocol is a breakthrough for agent interoperability. But interoperability without security is just a wider attack surface. It's time to take credentials out of the equation entirely.