What is MCP config secret exposure?
MCP (Model Context Protocol) is an open standard that lets AI coding assistants connect to external tool servers for capabilities like database queries, API calls, and file operations. Each MCP server connection is defined in a JSON config file stored on the developer's machine. The protocol requires credentials (API keys, access tokens, database passwords) to be passed as command-line arguments or environment variables in these config files, but provides no built-in mechanism for encrypting, rotating, or securely storing those credentials. They sit in plain text on disk. A scan of 1,722 publicly committed MCP config files on GitHub found that the majority contained at least one hardcoded secret, confirming that this design gap leads to real credential exposure at scale.
MCP (Model Context Protocol) is an open standard that lets your AI coding tools (Claude, Cursor, and others) connect to outside servers that can query databases, call APIs, and manage files. Each connection is defined in a JSON config file stored on your machine. The problem: the protocol requires passwords and API keys to be passed as command-line arguments or stored in that config file, but it has no built-in way to encrypt, rotate, or protect them. They sit in plain text on disk. A scan of 1,722 publicly shared MCP config files on GitHub found that the majority contained at least one real secret hardcoded in the file, confirming that this design gap leads to real credential exposure at scale.
MCP (Model Context Protocol) is an open standard that lets AI coding assistants connect to external tool servers for capabilities like database queries, API calls, and file operations. Each MCP server connection is defined in a JSON config file stored on the developer's machine. The protocol requires credentials (API keys, access tokens, database passwords) to be passed as command-line arguments or environment variables in these config files, but defines no governance layer for encrypting, rotating, or scoping those credentials. They sit in plain text on disk. A scan of 1,722 publicly committed MCP config files on GitHub found that the majority contained at least one hardcoded secret, confirming that this gap in the protocol's trust boundary leads to real credential exposure at scale.
Open your config file
If you use Claude, Cursor, Cline, or any AI tool with MCP servers, you have a config file on your machine right now. Open it.
If you use Claude, Cursor, Cline, or any AI tool with MCP servers, you have a config file on your machine right now. Open it.
If you run Claude, Cursor, Cline, or any AI tool with MCP servers, you have a config file on your machine right now. Open it.
# Claude Desktop (macOS)
$ cat ~/.config/Claude/claude_desktop_config.json
# Cursor
$ cat ~/.cursor/mcp.json
# Cline (VS Code extension)
$ cat ~/Library/Application\ Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.jsonOne of these files is on your machine right now. It probably has your passwords in it.
Look at the env block. If you see a real API key, a database URL, or a cloud token in there, every process running under your user account can read it. Every MCP server you install can access it. Every tool that shares the config directory can see it.
That is not a misconfiguration. That is how MCP works.
Look at the env block. If you see a real API key, a database URL, or a cloud password in there, every program running under your user account can read it. Every MCP server you install can access it. Every tool that shares that folder can see it.
That is not a mistake you made. That is how MCP works.
Look at the env block. If you see a real API key, a database URL, or a cloud token sitting there, every process running under your user account can read it. Every MCP server you install gets that capability grant. Every tool that shares the config directory has the same permission scope.
That is not a misconfiguration. That is the protocol's default trust boundary.
The design flaw
Model Context Protocol is the standard that lets AI coding assistants connect to external tools. Your database, your deployment pipeline, your monitoring stack. It is what makes Claude, Cursor, Windsurf, and every other AI tool useful beyond autocomplete.
The protocol tells you to put your credentials in a JSON file. Plain text. On disk. No encryption. No keychain integration. No credential rotation. No scoping. The spec provides no mechanism for any of it.
Model Context Protocol is the standard that lets AI coding tools connect to outside services: your database, your deployment pipeline, your monitoring stack. It is what makes Claude, Cursor, Windsurf, and every other AI tool useful beyond autocomplete.
The protocol tells you to put your passwords and API keys in a JSON file. Plain text. On disk. No encryption. No integration with your operating system's built-in password manager. No way to auto-rotate credentials. No way to limit which server sees which secret. The spec provides no mechanism for any of it.
Model Context Protocol is the standard that lets AI coding assistants connect to external tools: your database, your deployment pipeline, your monitoring stack. It is what makes Claude, Cursor, Windsurf, and every other AI tool useful beyond autocomplete.
The protocol tells you to put your credentials in a JSON file. Plain text. On disk. No encryption. No keychain integration. No credential rotation. No permission scoping. The spec defines no mechanism for any of it.
{
"mcpServers": {
"database": {
"command": "npx",
"args": ["@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_URL": "postgresql://admin:p4ssw0rd@prod-db.us-east-1.rds.amazonaws.com:5432/myapp"
}
}
}
}That is a production database URL with admin credentials. Username, password, host, port, database name. In a JSON file. On a developer's laptop.
This is not a bug. It is the design. MCP has no built-in secret management. Every AI tool that implements MCP inherits this gap. No tool has added their own protection on top of it.
Compare this to how every other credential system works. SSH uses chmod 600 and passphrase-protected keys. Docker stores registry tokens in a credential helper. Cloud CLIs use gcloud auth or aws sso login with short-lived tokens. Even .env files are at least excluded from version control by default in most frameworks.
MCP does none of this. The credentials sit in a JSON file, and nothing stops you from committing it, syncing it, or sharing it.
Compare that to how every other credential system works. SSH uses file permissions and passphrase-protected keys. Docker stores login credentials in a secure credential helper. Cloud tools like gcloud auth and aws sso login use short-lived credentials that expire automatically. Even .env files are at least excluded from version control by default in most frameworks.
MCP does none of this. Your credentials sit in a JSON file, and nothing stops you from committing it to a public project, syncing it to the cloud, or sharing it with a teammate.
Compare this to how every other credential system draws its trust boundary. SSH uses chmod 600 and passphrase-protected keys. Docker stores registry tokens in a credential helper. Cloud CLIs use gcloud auth or aws sso login with short-lived tokens. Even .env files are at least excluded from version control by default in most frameworks.
MCP provides none of this. The credentials sit in a JSON file with no provenance chain, no audit trail, and nothing preventing you from committing, syncing, or sharing them.
We scanned 1,722 public configs to prove it
We wanted to see what this design choice costs developers in practice. So we searched GitHub for every public MCP configuration file we could find.
Methodology
We used GitHub's Code Search API to find publicly committed MCP configuration files. We searched for 9 known filenames and path patterns across two passes:
- Pass 1:
claude_desktop_config.json,mcp.json, and genericmcpServersJSON files (999 configs) - Pass 2:
cline_mcp_settings.json,mcp_settings.json, dotfiles repos, and.configpaths (723 configs)
For each config, we ran 20+ regex patterns covering OpenAI keys, Anthropic keys, AWS credentials, GitHub PATs, Stripe keys, database connection strings, Slack tokens, Supabase JWTs, and generic password fields. We excluded environment variable references, placeholder strings, and example values. Only real, hardcoded credentials counted.
No credentials were stored or logged. Results are anonymized. The scanner and aggregate data are published for reproducibility.
Results
| Finding | Count | % |
|---|---|---|
| At least one hardcoded credential | 55 | 3.2% |
| Database connection strings | 25 | 1.5% |
| AI provider keys (OpenAI, Anthropic, Together) | 23 | 1.3% |
| Platform tokens (Slack, GitHub, Stripe) | 11 | 0.6% |
| Using environment variable references | 110 | 6.4% |
| No secrets detected | 1,667 | 96.8% |
The leak rate varied by tool:
| Tool | Configs | With Secrets | Leak Rate |
|---|---|---|---|
| Cline | 226 | 14 | 6.2% |
| Claude Desktop | 1,011 | 29 | 2.9% |
| Generic MCP | 464 | 10 | 2.2% |
That is 55 production databases, billing accounts, and API keys that are publicly accessible right now. 55 developers who thought their configs were private. And those are the configs that developers knowingly pushed to public repositories. They had every reason to clean them first.
The configs sitting on your machine right now, the ones you never reviewed because nobody was supposed to see them, did not get that pass.
Only 6.4% of all configs used environment variable references. The rest either had no credentials or hardcoded them directly.
What leaked most
Database connection strings were the most common secret type (25 configs). Full PostgreSQL and MySQL URLs with usernames, passwords, hostnames, and database names embedded in the string. A single leaked connection string is direct access to a production database.
AI provider keys were second (23 configs), split across OpenAI (11), Together AI (10), and Anthropic (2). Every one of those keys is a billing account anyone can spend against.
Every credential in an MCP config is one accidental git push, one stolen laptop, or one malicious MCP server away from becoming a production incident.
If you use environment variables, keep reading
You solved the storage problem. The credential is no longer hardcoded in a JSON file. But you did not solve the access problem.
Every MCP server runs as your user. Every one of them can read every environment variable you set. The credential moved out of a file and into a namespace that is equally open to every process on your machine. A malicious or compromised MCP server does not need to read your config file. It just calls os.environ and takes what it wants.
Environment variables are better than plaintext JSON. They are not safe. They are less dangerous.
Why no one fixes this
Three reasons. All of them are structural.
1. The protocol does not have secret management
This is the root cause. MCP was designed for functionality, not security. The spec says "put your credentials here" and provides no alternative. No tool vendor has built their own protection on top of it because the protocol does not define a hook for it.
2. You optimize for speed
When you are setting up a new MCP server at 11pm because you discovered a tool that will save you three hours tomorrow, you paste the credentials and move on. The JSON file on disk with your production database password in it does not feel urgent. Until it is.
3. The tools do not warn you
No major AI coding assistant warns you when it reads a credential from your MCP config. No confirmation dialog. No audit log. The credential flows into the context and you never see it happen. No tool warns you when you are about to commit the config to a public repo, either.
Three reasons. All of them are built into the system.
1. The protocol was not designed for security
This is the root cause. MCP was built for functionality. The spec says "put your credentials here" and gives you no alternative. No tool vendor has built their own protection on top of it because the protocol does not define a place to hook one in.
2. Setup happens fast, security happens never
When you are setting up a new MCP server at 11pm because you found a tool that will save you three hours tomorrow, you paste the password and move on. A JSON file on disk with your production database password in it does not feel urgent. You can fix that now with a scan that takes seconds (keep reading).
3. No tool tells you it is happening
No major AI coding tool warns you when it reads a credential from your MCP config. No confirmation dialog. No audit log. The credential flows into the conversation and you never see it happen. No tool warns you when you are about to commit the config file to a public project, either.
Three reasons. All of them are structural.
1. The spec has no governance surface
This is the root cause. MCP was designed for capability, not for trust escalation. The spec says "put your credentials here" and defines no alternative. No tool vendor has built their own protection layer because the protocol provides no hook for credential management at tool-call time.
2. Credential hygiene loses to velocity at midnight
When you are setting up a new MCP server at 11pm because you discovered a tool that will save you three hours tomorrow, you paste the credentials and move on. A JSON file on disk holding your production database password does not feel like an open trust boundary. Until it is.
3. No tool in the chain enforces least privilege
No major AI coding assistant warns you when it reads a credential from your MCP config. No confirmation dialog. No audit trail. The credential flows into the agent context and you never see it happen. No tool warns you when you are about to commit the config to a public repo, either. There is no policy enforcement anywhere in the pipeline.
This problem is growing. GitHub code search returned over 3,400 results for mcp.json mcpServers alone. As more developers connect AI tools to databases, APIs, and cloud services, the number of configs with exposed credentials will grow until the protocol or the tools fix this at the infrastructure level.
What you can do right now
You do not need to wait for the protocol to change.
Step 1: Replace hardcoded secrets with environment variables
// Before: hardcoded credential
"env": { "DB_URL": "postgresql://admin:secret@prod.db:5432/app" }
// After: reference to env var
"env": { "DB_URL": "${POSTGRES_URL}" }"env": { "DB_URL": "postgres://admin:secret@prod:5432" }
"env": { "DB_URL": "${POSTGRES_URL}" }
Step 2: Restrict file permissions
$ chmod 600 ~/.config/Claude/claude_desktop_config.json
$ chmod 600 ~/.cursor/mcp.jsonStep 3: Add the config to .gitignore
If your MCP config is anywhere near a git repository, make sure it cannot be committed by accident.
These steps are damage reduction, not a solution. The credential still exists in plain text on your machine. Environment variables are still readable by processes. File permissions do not stop a compromised application from reading sibling files. A complete solution requires encrypted credential storage with keychain integration.
Check your machine in 10 seconds
devsafe mcp-scan finds every MCP config on your machine and tells you exactly what is exposed. Free. No account. No data leaves your machine.
devsafe mcp-scan finds every MCP config on your machine and tells you exactly what is exposed. Free. No account required. No data leaves your machine.
devsafe mcp-scan finds every MCP config on your machine and tells you exactly what is exposed. Free. No account. No data leaves your machine.
$ curl -fsSL https://devsafe.com/install.sh | sh
$ devsafe mcp-scan
FOUND: 3 MCP configs
~/.config/Claude/claude_desktop_config.json 2 secrets exposed
~/.cursor/mcp.json 4 secrets exposed
cline_mcp_settings.json 0 secrets (clean)| MCP Server | Secrets Accessible | Secrets Required | Overprivilege |
|---|---|---|---|
| postgres | DB_URL, SLACK_TOKEN, GITHUB_PAT | DB_URL | SLACK_TOKEN, GITHUB_PAT |
| slack | DB_URL, SLACK_TOKEN, GITHUB_PAT | SLACK_TOKEN | DB_URL, GITHUB_PAT |
| github | DB_URL, SLACK_TOKEN, GITHUB_PAT | GITHUB_PAT | DB_URL, SLACK_TOKEN |
The protocol will not protect your credentials. Your AI tools will not warn you. You have to check for yourself.
Managing a team? If you have 5 or 50 developers connecting AI tools to production systems, the question is not whether someone has a credential in a config file. The question is how many. Talk to us about scanning your team's machines before the next accidental git push makes the decision for you.
The protocol will not protect your credentials. Your AI tools will not warn you. You have to check for yourself.
Managing a team? If you have 5 or 50 developers connecting AI tools to production systems, the question is not whether someone has a credential in a config file. The question is how many. Talk to us about scanning your team's machines before the next accidental push to a public project makes the decision for you.
The protocol will not scope your credentials. Your AI tools will not flag the exposure. You have to audit this yourself.
Managing a team? If you have 5 or 50 developers connecting AI tools to production systems, the question is not whether someone has a credential in a config file. The question is how many. Talk to us about scanning your team's machines before the next accidental git push breaches a trust boundary you did not know was open.
Frequently asked questions
Does MCP store API keys in plain text?
Yes. The Model Context Protocol (MCP) specification has no built-in secret management, keychain integration, or encryption for credentials. API keys, tokens, and passwords are stored as plain-text strings in JSON config files on disk. This is how the protocol is designed, not a misconfiguration.
Where is the MCP config file stored on my machine?
The MCP config file location depends on your AI tool. For Claude Code it is at ~/.claude/claude_desktop_config.json. For Cursor it is in your Cursor settings directory. For VS Code with Copilot it is typically in your VS Code settings. Each file contains server definitions with any credentials passed as command-line arguments or environment variables in plain text.
How do I check my MCP config for leaked secrets?
Run 'devsafe mcp-scan' from your terminal. It scans all known MCP config file locations on your machine, detects hardcoded API keys and tokens, and reports which credentials are exposed. The scan takes about 10 seconds and checks Claude, Cursor, Windsurf, and other tool configs.