TL;DR
- MCP config files now sit in the same risk category as .env files because they often contain live credentials in plaintext.
- They are easy to forget because they look like tooling config, not secret storage.
- A committed MCP file can leak database URLs, GitHub tokens, cloud keys, and internal endpoints to git history and AI tools at the same time.
- The fix is straightforward: ignore the files, scan them, replace secrets with references, and document the workflow explicitly.
What MCP config files actually do
Model Context Protocol gives AI tools a standard way to connect to external systems: databases, GitHub, browsers, filesystem helpers, internal APIs, and custom automation services. That makes MCP genuinely useful. It also means the config file becomes a map of your internal tooling plus the credentials required to access it.
In other words, an MCP config is often not just a config file. It is an authentication bundle. The file may look harmless because it is JSON sitting next to other editor metadata, but operationally it behaves much more like a secret store.
Why teams miss it
- The file lives in tool-specific paths such as
mcp.json,.mcp/config.json, or editor-owned folders. - Developers treat it as IDE config and forget to add it to ignore files.
- The credentials are often added during experimentation, when security review is lowest.
- AI tools themselves may read the MCP config to understand available tools, which means the secret is exposed to more than one assistant.
Why MCP config files became dangerous so quickly
Traditional secrets were at least mentally grouped into obvious buckets: .env, Terraform vars, Kubernetes secrets, CI vaults. MCP changed the packaging. Now the credential often lives inside a JSON block under something that looks like ordinary developer tooling.
That matters because the file often contains high-value access: production database URLs, GitHub access tokens with repository scope, SaaS API keys, or internal admin endpoints. If the file leaks, the attacker does not just learn how you build. They learn how to connect.
MCP config files are the new ".env you did not realize you created."
If your AI stack can query GitHub, Postgres, Notion, Linear, Slack, or internal APIs through MCP, your MCP credentials are often broader in scope than the secrets in a single app-level env file.
What a risky MCP config looks like
The unsafe pattern is common because it is convenient during local setup:
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_URL": "postgres://admin:supersecret@prod-db.example.com/app"
}
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}This file is dangerous in four different ways at once:
- The credential is stored in plaintext on disk.
- It may be committed to git if the file is not ignored.
- AI tools may read it as part of their workspace context.
- The token often grants cross-system access rather than access to one app.
A safer config pattern
{
"mcpServers": {
"postgres": {
"command": "slickenv",
"args": ["run", "--", "npx", "-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_URL": "slickenv://POSTGRES_URL"
}
}
}
}The assistant still sees the server definition and can reason about the tool topology, but the sensitive value is no longer embedded in the file.
How to harden MCP configs
Hardening MCP config is mostly discipline and defaults. You do not need a novel security framework. You need the same practices that should already exist for environment variables.
- Add MCP paths to
.gitignoreimmediately. - Add the same paths to AI ignore files because editor tools and agents also read them.
- Prefer
slickenv://references or runtime env injection over hardcoded values. - Scan the repo and git history to catch the copies that were already committed.
- Keep token scopes narrow; do not use one admin token for every MCP server.
# .gitignore
mcp.json
.mcp/
.cursor/mcp.json
.vscode/mcp.jsonThis should be paired with the broader AI boundary setup described in Your AI Coding Tool Can Read Your .env File Right Now.
Scanning and automation
Because MCP configs are just files, the right response is to include them in the same scanning pipeline as env files and committed credentials.
$ slickenv scan --mcp
→ Scanning MCP-related files...
✗ POSTGRES_URL postgres://admin:password@... (critical) mcp.json:8
✗ GITHUB_TOKEN ghp_xxxxxxxxxxxxxxxxxxxxxxxx (critical) .mcp/config.json:14
⚠ INTERNAL_URL https://admin.internal.example (warning) .cursor/mcp.json:22
Score: 18/100Once the scan exists, wire it into the rest of the lifecycle. Pre-commit hooks catch new leaks locally. CI blocks pushes that slipped through. Git history scans find the old mistakes. This is the same layered pattern we recommend for pre-commit protection and CI secret leak prevention.
Secure defaults for teams shipping fast
- Do not allow raw tokens inside MCP examples in your docs or onboarding guides.
- Use service-specific, least-privilege tokens instead of one broad personal token.
- Assume any tool-readable config may eventually be read by another AI tool in the same machine workflow.
- Review old experimental branches because MCP files are often created during quick tests and forgotten.
- Document one blessed setup command so every developer gets the same ignore and scanning defaults.
The meta-problem here is category confusion. Teams know how to think about .env files. They do not yet think of editor tool config as high-value secret storage. Until that mindset changes, you need the tooling to force the issue.
For more context, read the MCP spec at modelcontextprotocol.io, then compare your current setup against the workflows in Securing Your .env in the Age of Autonomous Code Agents.