Blog
24,000 Secrets Found in MCP Config Files, and What an MCP Server Can Actually Reach
Unvetted third-party MCP servers are running locally with access to your filesystem and environment. Here is how tool poisoning and plaintext configs create severe blast radius risks.
· updated 1 October 2026
MCP configuration files are plaintext JSON files that often aggregate multiple API keys, OAuth tokens, and database passwords in one place. According to GitGuardian, over 24,000 unique secrets have been exposed in public MCP configurations. Because an MCP server runs as a local process inheriting the user's environment, simply moving secrets to environment variables does not prevent a malicious or compromised MCP server from accessing them. The primary mitigation is per-workspace credential scoping, which limits a server's access strictly to the resources required for a specific task.
What an MCP Server Actually Is
The Model Context Protocol (MCP) standardizes how AI agents communicate with external tools and data sources. But when you install an MCP server from a repository's README, you are not just adding a plugin to a web interface. You are downloading and executing code on your local machine.
An MCP server is a standalone process running on your operating system, communicating via JSON-RPC over stdio or HTTP with SSE. Whether it is a Node.js script, a Python application, or a compiled binary, it executes with the exact user permissions that launched it. This means the server has the unmediated ability to read your filesystem, access your local network, and execute child processes.
Because the server facilitates communication between a local agent and external APIs or databases, it requires credentials to function. The standard way to configure an MCP server involves specifying its start command and passing necessary arguments, often requiring the user to supply sensitive tokens directly to the process environment.
The 24,000 Secrets Exposed in MCP Configs
A recent report by GitGuardian identified 24,008 unique secrets exposed in public MCP configuration files (detailed in AI-assisted code leaks secrets at 2x human rate). This massive exposure stems directly from how early quickstart guides and documentation instructed users to set up their servers.
Files like claude_desktop_config.json (and equivalents for Cursor and Cline) are plaintext JSON files stored locally in paths like ~/Library/Application Support/Claude/claude_desktop_config.json. When a developer configures multiple MCP servers for different services, this single configuration file becomes an aggregated vault of high-privilege credentials.
The risk is compounded by automated development workflows. Developers frequently use settings synchronization features (such as VS Code Settings Sync), which can inadvertently upload configuration files containing plaintext secrets to the cloud. A single accidental git push or a synchronized settings file is all it takes to compromise an entire suite of developer tools.
Tool Poisoning and Malicious Instructions
The OWASP MCP Top 10 lists Tool Poisoning (MCP03) among its ten MCP-specific risks, behind token mismanagement and secret exposure at MCP01. Unlike traditional code injection, tool poisoning attacks the metadata that an agent uses to understand what a tool does.
When an MCP server registers a tool via tools/list, it provides a description of the tool's purpose and JSON Schema for its expected parameters. An agent relies on this metadata to formulate its tool calls. In a tool poisoning attack, an adversary embeds malicious instructions within these tool descriptions rather than in the execution code itself.
Because the AI agent inherently trusts the tool metadata as authoritative instructions, it can be manipulated into executing harmful actions. For example, a poisoned description might instruct the agent to silently append sensitive data from a previous turn into an unrelated API request, effectively exfiltrating credentials without raising alarms during code execution.
The Confused Deputy in Agent Environments
The confused deputy problem is a classic security vulnerability where a highly privileged program is tricked by a lesser-privileged program into misusing its authority. In the context of AI agents, your local agent acts as the highly privileged deputy.
The agent has broad permissions to act on your behalf, often with unrestricted access to your local files and authenticated sessions. If a malicious MCP server successfully compromises the agent via tool poisoning or another exploit, it effectively commandeers your user permissions.
Trail of Bits research on hijacking multi-agent systems describes agents as confused deputies laundering malicious data from other agents. An attacker who controls an MCP server does not necessarily need to exploit the operating system directly. By simply redirecting the agent's actions through malicious prompt injection in tool metadata, the attacker can leverage the agent's broad access to read private .env files or push unauthorized commits.
Why Environment Variables Do Not Solve the Problem
A common, reflexive piece of security advice is to simply move hardcoded secrets out of configuration files and into environment variables. While this prevents accidental commits of plaintext JSON files, it does not mitigate the runtime risks of MCP servers.
Because an MCP server operates as a local process spawned by the agent or the developer's shell, it inherits the process environment via process.env. Any environment variables available to the parent process, including those loaded from a local .env file, are immediately readable by the MCP server code.
If an MCP server is compromised or deliberately malicious, placing secrets in environment variables provides no barrier (as explained in how to stop coding agents reading your .env file). The server's code can read process.env just as easily as it can read a configuration file, granting the attacker access to every token loaded into that session.
Limiting the MCP Blast Radius Architecturally
To meaningfully secure an environment that relies on MCP servers, the architecture must focus on per-workspace credential scoping. Instead of a global configuration file holding all credentials, access must be partitioned so that a compromised server can only reach the minimum required secrets.
This requires a broker that issues credentials just-in-time to the specific agent or server process handling a task, and only for the duration of that task. If an attacker breaches an MCP server in this environment, they only obtain the credentials explicitly granted to that isolated workspace.
One approach to this is how Forkbench's Vault handles Thread credential scoping. By isolating secrets per thread and brokering access with macOS Seatbelt sandboxing rather than exposing the raw environment, the blast radius of any single compromised tool is severely restricted without breaking the developer workflow.
The Unvetted Supply Chain Risk
Despite architectural mitigations, there is a fundamental risk that no software tool or configuration standard can completely eliminate. When you install a third-party MCP server (such as via npx -y or pip install), you are adding an unvetted dependency to your machine.
Tools like Forkbench do not audit the source code of third-party MCP servers, nor do they run these servers in heavily restricted, customized sandboxes by default. A natively executing process that is fundamentally malicious from installation will always pose a threat to the host system.
The ultimate responsibility remains on the developer to vet the authors of the MCP servers they install. Treating every open-source MCP server as a trusted system component without reviewing its source or understanding its network behavior is a persistent supply chain vulnerability.
Related: How to stop an agent reading your .env, How credential brokerage works, AI-assisted code leaks secrets at 2x human rate
Frequently asked
Are MCP servers a security risk?
Yes. MCP servers are standalone processes that execute locally with the user's permissions via the Model Context Protocol. They require access to sensitive credentials and can read your filesystem or environment variables, making them a significant target for attackers if compromised or poorly configured.
What is MCP tool poisoning?
Tool poisoning is an OWASP MCP Top 10 vulnerability where malicious prompt instructions are embedded in tool descriptions and metadata returned by
tools/list. Because AI agents trust this metadata, they can be tricked into executing harmful actions or exfiltrating data.Can an MCP server steal my API keys?
Yes. If an API key is stored in a plaintext configuration file like
claude_desktop_config.jsonor exposed in environment variables (process.env) inherited by the MCP server, a malicious or compromised server process can read and transmit those keys (see Forkbench security).Is it safe to put API keys in MCP config files?
No. MCP config files like
claude_desktop_config.jsonare often stored as plaintext JSON. Storing API keys directly in them aggregates multiple secrets in one place, increasing the risk of accidental exposure through settings synchronization tools or version control (learn more in secrets sprawl risks).How do I secure my MCP server configuration?
Avoid placing plaintext secrets in global configuration files. Instead, use per-workspace credential scoping and brokers like Forkbench's Vault to ensure an MCP server only has access to the specific credentials it needs for a given task, limiting the potential blast radius of a compromise.