MCP servers can expose enterprise secrets through plaintext configuration files, over-permissioned access and prompt injection, often before security teams even know the server is running. As more organizations adopt AI agents into their systems, that exposure can silently become a major gap in MCP server security. The Model Context Protocol (MCP) allows AI agents to reach the tools and data, including internal documentation and cloud infrastructure, that form the foundation of enterprise systems. Behind that convenience, the MCP server connecting those tools and data to enterprise systems typically holds the keys to everything it touches: credentials, service account keys, API tokens and other secrets. 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.
What is Model Context Protocol (MCP)?
Model Context Protocol (MCP) is an open standard, originally introduced by Anthropic, that allows AI assistants to connect to external tools and data. Instead of being constrained to a model’s existing knowledge, an AI agent can use MCP to reach live systems, pulling a record from a database, opening a file or calling an API. What makes this work is the MCP server: a small program that sits between the AI and the system it wants to use, exposing the specific actions the AI agent is allowed to perform. With the MCP server serving as the middleman, this is where the greatest risk lies because, to act on a system, an MCP server requires that system’s credentials.
Agents no longer just produce answers; they take action by retrieving sensitive data and deciding which tools to call using Non-Human Identities (NHIs) like API keys and tokens. Because MCP turns AI agents into active identities operating across enterprise systems, a leaked secret doesn’t just expose data; it also grants an attacker the ability to act on it.
Ways MCP servers may expose secrets
The convenience of MCP comes with a catch: The same server that allows an AI agent to do meaningful work is also a hub for credentials. Since MCP is innovative and moving fast, many servers are built and deployed without the security measures that should be expected for something holding production keys. Here are some of the most common ways secrets can end up exposed in MCP servers.
Plaintext credentials in config files
MCP servers routinely store the tokens and keys they need in local configuration files and often in plaintext. In many setups, getting a server running means pasting in a configuration string that contains the credentials themselves. If that file is left on a disk, it’s very likely to be overlooked, copied between machines or committed to a Git repository by accident. Once an attacker reaches that server, everything it holds is readable.
Credential sprawl across ungoverned servers
Without a central location to store secrets, every AI agent ends up managing its own. The same credentials — including API keys and tokens — get scattered across config files and environment variables, and duplicate copies pile up across development, staging and production. Because no one has a full inventory of these secrets, they rarely get rotated, leaving them valid and static indefinitely. Each scattered, long-lived secret can be stolen by an attacker, creating another potential entry point for a breach.
Prompt injection
Not every leak requires an attacker to break in. Because AI agents read and act on the material they are given, an attacker may hide instructions within a document, support ticket or web page the agent accesses. As a result, the agent may follow those hidden directions, treating them as legitimate commands in what is referred to as prompt injection. Agents can be tricked into misusing their tools or handing over the secrets they were trusted to protect.
Over-permissioning
To avoid running into authorization errors while building, developers often grant an MCP server broad permissions and move on. However, those generous scopes tend to ship to production if they are forgotten about. When least privilege isn’t enforced, an AI agent can reach far beyond what’s necessary for its task, meaning any single compromise exposes much more than it should have.
Exposed-server risk
Anyone can publish an MCP server, which is a supply chain issue waiting to happen. Connecting to an untrusted one can turn against you, as CVE-2025-6514 demonstrated. In mcp-remote (an OAuth proxy downloaded over 400,000 times that runs on the client machine), a malicious server could trigger OS command injection, leading to remote code execution on the machine running the proxy and granting attackers access to steal its credentials.
How to secure enterprise secrets on MCP servers
MCP changes where secrets live and who reaches them, but the measures for protecting them must be applied intentionally to this new AI layer. Here are several best practices that counter the exposure paths:
- Stop hardcoding secrets and centralize them. Pulling credentials out of config files, environment variables and source code and placing them into a single managed store is the solution for both plaintext exposure and credential sprawl. Instead of secrets sprawl across servers, AI agents retrieve what they need from one governed source at runtime.
- Use short-lived credentials and rotate them automatically. Static, long-lived secrets are valuable to attackers because they don’t change. Replacing them with credentials issued on demand and expiring on their own minimizes the window of opportunity for attackers to exploit them, and automated rotation means a leaked secret is useless once it’s exposed.
- Enforce least privilege. Give each AI agent access only to the systems and data its task requires, so one compromised agent exposes only a fraction of what an over-permissioned one would.
- Keep a human in the loop for sensitive actions. Retrieving an unmasked secret, deleting a record or reaching production should require explicit confirmation. That checkpoint is typically what stops a prompt injection attempt from quietly turning into a serious breach.
- Encrypt secrets with a zero-trust, zero-knowledge model. Secrets should be end-to-end encrypted, retrieved only at the moment of use and never readable by the platform storing them. A zero-knowledge approach means that even a compromised vault yields nothing an attacker can read.
- Log and audit everything the agent does. Autonomous agents act fast and without direct oversight, so a full record of what was accessed and when is essential for compliance and for diagnosing an incident afterward.
- Inventory your MCP servers. You can’t protect what you can’t see. Maintaining visibility into every MCP server running in your environment eliminates shadow AI — unmanaged, forgotten identities that quietly hold live credentials and never appear in a security review.
Rethink secrets management for AI agents
MCP has quietly added a new layer to the enterprise — one that sits between AI agents and nearly every system worth protecting, and one that holds the credentials to reach them. Organizations must apply the same rigor they would apply to any other production system holding secrets, which means centralizing credentials and controlling what each agent can reach are essential. Tools built for this, like Keeper Secrets Manager, mask secrets by default and require confirmation before any value is revealed, so AI agents can use credentials without leaving them exposed, helping organizations secure the MCP layer.
Note: This article was thoughtfully written and contributed for our audience by Ashley D’Andrea, Content Writer at Keeper Security.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
