Agent Blast Radiusby Kloudle

Answers / Is Your MCP Config Leaking Secrets?

Answer

Can my MCP config leak hardcoded secrets?

Often, yes. MCP server configs for Claude Desktop, Cursor, and similar tools commonly store API keys and tokens directly in plaintext JSON or .env files instead of referencing a secret manager. Research on public configs found that 12% of credential slots hardcode a secret, and most scanners can't recognize the shape of the token. blast flags inline env credentials and unpinned npx packages in your local MCP configs.

Updated · Kloudle

Where do MCP configs live, and why do secrets end up inside them?

MCP configs live in predictable places: Claude Desktop's claude_desktop_config.json, Claude Code's own MCP settings, Cursor's mcp.json, and similar files for Windsurf and Gemini. Unlike a .env file, these are often designed to be committed to source control so a team can share agent tooling, which is exactly why a hardcoded credential in one travels further: into git history, into backups, and into any clone of the repository.

Security researcher and gridctl author wcollins describes this as the default experience: API keys and tokens sitting directly in config files on disk, propagated by home-directory backup syncs, exposed in shell history when someone cats the file to debug it, leaked into git when a .gitignore entry is incomplete, readable from process memory, and sometimes dumped to logs by a library that didn't redact it (wcollins). His conclusion is blunt: a config file should never contain a credential — only a reference to one.

How common is this, really?

Hush Security's analysis of roughly 82,000 public MCP configuration files found that 12% of credential slots hardcode a secret — the "1 in 8" figure — and that 55% of those hardcoded secrets have no vendor-recognizable token shape, the pattern that scanners like gitleaks and GitHub secret scanning rely on to catch a leak. Among the leaked credentials with a definable scope, 53% are organization-, account-, workspace-, or database-wide, and among those with a defined expiry policy, 80% never expire by default; 24% of all hardcoded secrets in the dataset are both broad-scope and non-expiring. Tracing git history across 7,681 credential-bearing configs, Hush found 1,394 secrets still live in the current file and 243 more that were "removed" still fully readable in earlier commits (Hush Security research).

Separate research from Trend Micro reviewed 19,402 MCP server source repositories and found that 9,294 of them — 48% — recommend storing secrets in a plain .env file. The same report tracked MCP server growth from 714 servers in January 2025 to 16,098 by July 2025, and warned that a leaked configuration plus a natural-language query is often all an attacker needs (Trend Micro).

How do you fix it?

Doppler's guidance is to stop embedding API keys in configuration files and load them from environment variables or a dedicated secrets manager at runtime instead. Centralized platforms such as AWS Secrets Manager or Doppler let an MCP server retrieve credentials dynamically without persisting them to disk, OAuth token delegation lets a client obtain short-lived tokens tied to a specific identity instead of a static key, and scheduled rotation with audit logging piped to a SIEM catches unauthorized use quickly (Doppler). The common thread: no hardcoding, least privilege, dynamic credentials, and logging you actually watch.

Pinning MCP server packages matters too. A config that launches a server through an unpinned npx package re-resolves whatever the latest published version is on every run, which means a compromised or yanked package update reaches you automatically; pinning to an exact version at least makes that a decision rather than a surprise. blast flags both patterns — inline env credentials and unpinned npx — in whatever MCP configs it finds on your machine; see the install guide to run it alongside yours.

Check your own machine

See what an agent running as you can reach. Offline, read-only, never prints values:

$npx -y @kloudle/agent-blast-radius@0.3.0

Inside your agent: install guides for Claude Code, Codex, Cursor, Claude Desktop and more. Which keys are live? npx -y @kloudle/agent-blast-radius@0.3.0 verify (paid per check).

Frequently asked

Where do MCP configs typically live on a developer's machine?

Claude Desktop and Claude Code each keep their own MCP settings, and tools like Cursor, Windsurf, and Gemini keep a similar mcp.json or equivalent, often inside the project directory where it can end up committed to the repository.

Does blast fix hardcoded secrets in my MCP configs?

No. It flags inline environment credentials and unpinned npx packages in configs it finds locally so you can see the problem; it doesn't rewrite your config or manage secrets for you.

Are unpinned npx packages in an MCP config actually a secrets risk?

Indirectly, yes: an unpinned package can change what code runs and what it does with any credential the server already holds, which is why blast reports it alongside inline credentials rather than separately.

Is 12% of credential slots the same as 12% of all MCP configs leaking a secret?

No. It's the share of credential slots across Hush Security's roughly 82,000 analyzed public configs that hardcode a secret rather than reference one, not a statement that every config file has a leak.

Sources

  1. Beware of MCP Hardcoded Credentials: A Perfect Target for Threat Actors — Trend Micro
  2. Your MCP Config Is Leaking Secrets — wcollins
  3. New Research Finds 1 in 8 Credentials in Public MCP Config Files Are Hardcoded Secrets — Hush Security / PR Newswire
  4. How to Securely Manage Secrets in MCP Servers — Doppler

Related