Tom Hundley
🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4
MCP config files deserve the same scrutiny as browser extensions, CI secrets, and developer dotfiles. They determine which external tools an AI assistant can invoke, what code gets launched locally, and in some cases which credentials get passed along. If those files are tampered with or carelessly committed, the result can be anything from secret exposure to a malicious server quietly inserting itself into an AI-driven workflow.
For teams using Cursor, Claude Desktop, Windsurf, or other MCP-capable tools, the practical takeaway is simple: treat MCP configuration as security-sensitive infrastructure. Audit every configured server, remove plaintext secrets, keep human approval turned on for risky actions, and limit each server's permissions to the smallest scope possible.
TL;DR: MCP is a standard way for AI tools to connect to external systems through separately running servers.
The Model Context Protocol (MCP), introduced by Anthropic in late 2024, is an open protocol for connecting AI assistants to external tools and data sources. Instead of every AI product building one-off integrations for GitHub, databases, local files, or browsers, MCP defines a common way for a client to talk to a server that exposes those capabilities.
In practice, that means an AI tool may be able to:
Those capabilities come from an MCP server. The desktop app or coding assistant is the MCP client. The connection is usually defined in a config file that specifies which servers to run or connect to, how to start them, and sometimes which environment variables or arguments they receive.
That architecture is useful, but it also expands the attack surface. A compromised or overly permissive server is not just data plumbing; it is executable software participating in an agentic workflow.
TL;DR: MCP config files are sensitive because they define trust relationships, execution paths, and sometimes credential handling.
MCP security discussions often focus on malicious or vulnerable servers. That concern is valid, but the config layer matters just as much because it controls which servers are trusted in the first place.
A config change can swap one server for another, alter launch arguments, or broaden a server's reach. If an attacker can modify that file, they may be able to redirect tool calls, change what gets executed locally, or expose the assistant to manipulated outputs from an untrusted source.
The exact impact depends on the client and server involved, but the core risk is consistent: configuration determines the boundary of trust.
A common implementation mistake is placing tokens, connection strings, or API keys directly in JSON config. That is not unique to MCP, but MCP setups can make the pattern tempting because developers want a tool to "just work."
If those files are synced to a dotfiles repository, committed to source control, or shared in screenshots and support threads, the exposure can be immediate. The safer pattern is to use environment variables or a secrets manager and keep the config file itself free of raw credentials.
Because MCP servers are ordinary software, they can contain the same classes of flaws seen elsewhere: command injection, insecure deserialization, path traversal, weak auth, or excessive permissions. A config file that launches a vulnerable server is not the root cause of the bug, but it is the mechanism that puts that code into the workflow.
| Risk | How it manifests | Severity |
|---|---|---|
| Server substitution | Config points the client to an untrusted or malicious server | High |
| Plaintext secrets | Tokens or credentials stored directly in config | High |
| Overbroad permissions | Server can access more files, systems, or APIs than needed | Medium to High |
| Vulnerable server code | The configured server contains exploitable flaws | Varies |
TL;DR: Inventory servers, remove plaintext secrets, require approval for risky actions, enforce least privilege, and add config scanning to routine security checks.
Open the relevant config files for each AI tool in use and list every server entry. Remove anything unused, unfamiliar, or added for a one-off task that no longer matters. Dormant integrations still expand the attack surface.
Because file locations vary by product and operating system, rely on the vendor's current documentation rather than assuming a single universal path.
Search for API keys, bearer tokens, passwords, and connection strings. Replace them with environment variable references where supported, or retrieve them through a secrets manager.
Avoid examples that expose real vault names, item names, or secret paths in documentation or screenshots. Use placeholders such as YOUR_API_KEY or op://{vault}/{item}/{field}.
Many AI tools offer streamlined approval flows, and some may support broad auto-run behavior for trusted actions. For anything that can touch the filesystem, execute commands, call external APIs, or modify code, human review remains an important control.
Approval prompts are not a complete defense against prompt injection or malicious tools, but they do create a checkpoint before a high-impact action runs.
Limit each server to the smallest set of permissions it needs:
Least privilege reduces blast radius when a server is buggy, compromised, or simply misused.
Treat MCP config files like any other sensitive developer artifact. Include them in secret scanning, repository hygiene checks, and workstation audits. Even if a dedicated MCP scanner is not available for a given toolchain, generic secret scanners and file integrity monitoring can still catch common mistakes.
TL;DR: A read-only audit prompt can quickly surface what your AI tool can access, though results depend on what the client can actually inspect.
Paste this into an MCP-connected assistant:
List every MCP server currently configured or connected in this tool. For each one, report:
1. The server name
2. How it is launched or where it connects
3. What tools or capabilities it exposes
4. What files, directories, APIs, or systems it can access
5. Whether any visible configuration appears to contain plaintext secrets
Present the results as a table. Flag any server that appears high-risk because of broad permissions,
unknown origin, unexpected launch behavior, or exposed credentials.This is useful as a first-pass review, not a definitive audit. The assistant can only report what the client exposes to it, and it may not reliably identify hidden permissions, inherited environment variables, or secrets stored outside the visible config.
TL;DR: The biggest practical questions are where configs live, whether public servers are safe, and how often to review them.
An MCP config file tells a client which servers to use and how to invoke or connect to them. Depending on the product, it may include command paths, arguments, environment variable references, transport settings, or server metadata.
That depends on the tool and operating system. Some products use project-local config, while others use user-level application settings. Check the current vendor documentation rather than relying on copied examples from blog posts or social media.
They should be treated like any other third-party software: potentially useful, but not automatically trustworthy. Review the source, maintenance history, permissions requested, and update cadence. If possible, test in an isolated environment before connecting a server to sensitive files or systems.
It may be acceptable for tightly scoped, low-risk actions in controlled environments, but broad auto-approval increases risk quickly. The more a tool can read, write, execute, or transmit, the more valuable manual review becomes.
At minimum, review them when adding a new server, changing permissions, onboarding a new tool, or connecting to sensitive systems. For active teams, folding MCP config review into regular workstation and repository security checks is a sensible baseline.
MCP makes AI tools more useful by giving them structured access to external systems, but that convenience shifts real security weight onto configuration. The important question is not whether MCP is inherently unsafe; it is whether teams are treating MCP servers and config files with the same care they already apply to dependencies, browser extensions, and local developer credentials.
That means fewer blind installs, fewer hardcoded secrets, tighter permissions, and more deliberate review of what an assistant is allowed to do. As AI tooling becomes more agentic, config hygiene stops being a niche concern and becomes part of basic operational security.
Discover more content: