MCP Servers Expose Enterprise Secrets Through Flawed Security Practices

"Every organization should now question what secrets they are handing to AI and how well those secrets are protected once they reach an MCP server." — Ashley D’Andrea, Content Writer at Keeper Security

What the Model Context Protocol is, and why its servers matter

The Model Context Protocol (MCP) is an open standard, originally introduced by Anthropic, that lets AI assistants reach external tools and live data instead of relying solely on a model’s internal knowledge. MCP works by placing a small program—the MCP server—between an AI agent and the systems it needs to access. That server exposes the specific actions an agent may perform and, to do that work, typically holds the credentials required to act: API tokens, service account keys and other secrets. Because MCP turns agents into operational identities that call systems on demand, the MCP server is a gatekeeper that, if compromised, grants an attacker both data and the ability to act on it.

How MCP servers commonly expose enterprise secrets

The convenience of letting agents reach files, APIs and infrastructure carries predictable technical failure modes. The source identifies five recurring exposure paths that organizations are already seeing in MCP deployments:

• Plaintext credentials in config files. MCP servers often store tokens and keys in local configuration files and sometimes in plaintext. Bootstrapping a server can mean pasting a configuration string that contains credentials; if that file persists on disk it may be copied, overlooked or accidentally committed to source control.
• Credential sprawl across ungoverned servers. Without a central secret store, each AI agent ends up managing its own credentials. Identical keys and tokens proliferate across development, staging and production, rarely getting rotated and remaining useful to attackers indefinitely.
• Prompt injection. Because agents act on documents and web pages they read, an attacker can hide instructions in those inputs. An agent that treats such hidden instructions as legitimate commands may misuse its tools or disclose secrets it was supposed to protect.
• Over-permissioning. Developers frequently give MCP servers broad permissions to avoid authorization errors during build and test. Those generous scopes can make it to production, meaning a single compromised agent can access far more than necessary.
• Exposed-server supply chain risk. Anyone can publish an MCP server. The example cited is CVE-2025-6514 in mcp-remote, an OAuth proxy downloaded more than 400,000 times that runs on the client machine: a malicious server could trigger OS command injection and remote code execution on the client, allowing attackers to steal credentials.

Concrete mitigations the source recommends

Securing the MCP layer, the article argues, requires applying familiar secrets-management rigor to this new class of servers. The practical steps laid out are direct and operational:

• Centralize secrets; stop hardcoding. Move credentials out of config files, environment variables and source code into a single managed store so agents retrieve what they need at runtime instead of scattering secrets across servers.
• Use short-lived credentials and automate rotation. Replace static, long-lived secrets with credentials issued on demand that expire automatically, shrinking the window of exposure should a secret leak.
• Enforce least privilege. Limit each AI agent to the minimum systems and data necessary so a compromise affects only a narrow scope.
• Keep a human in the loop for sensitive actions. Require explicit confirmation for retrieving unmasked secrets, deleting records or acting on production systems—checkpoints that can stop prompt-injection attempts from escalating.
• Encrypt with zero-trust, zero-knowledge models. End-to-end encryption and vaults that the platform cannot read mean that even a compromised store yields nothing an attacker can use.
• Log and audit every agent action. Autonomous agents move quickly; full records of access and timing are essential for compliance and post-incident diagnosis.
• Inventory MCP servers. Visibility into every MCP server eliminates shadow AI—unmanaged identities that quietly hold live credentials.

How Keeper Secrets Manager and product controls fit in

The article calls out tools built for this problem and names Keeper Secrets Manager as an example: it masks secrets by default and requires confirmation before any value is revealed, enabling AI agents to use credentials without leaving them exposed. That kind of tooling demonstrates one design philosophy the source advocates—preventing secret material from being readable except at the precise moment of use and under controlled conditions.

What this means for technologists, procurement leaders, and security teams

• Technologists and security teams: Expect to inventory MCP servers, centralize credentials and adopt short-lived, request-time secrets as part of deployment pipelines. Logging and human approval gates should be integrated into agent workflows.
• Procurement leaders: Review third-party MCP servers and proxies before adoption. The CVE-2025-6514 example underscores supply-chain risk from publicly available tools like the cited mcp-remote OAuth proxy.
• Security operations: Add MCP-related telemetry to existing SIEM and incident-response playbooks so prompt-injection and over-permissioning failures are detectable and containable.

MCP has quietly placed a new layer between AI agents and the data and systems enterprises care about. The choice organizations face is straightforward and technical: decide which systems hand credentials to agents, centralize and shorten those credentials’ lifespan, and require explicit human confirmation for sensitive acts—or accept that an MCP server is now another secret repository that attackers can target. As Ashley D’Andrea writes, that should be a deliberate decision, not an accident.

https://thehackernews.com/2026/08/how-mcp-servers-can-expose-enterprise.html