Live API keys in .mcp.: dev.to author ships a secrets runner for MCP servers

A post on dev.to argues that the most common way to configure MCP (Model Context Protocol) servers leaves live production credentials sitting in plaintext config files — and that this habit, rather than anything about the protocol itself, is what tends to sink MCP deployments at corporate security reviews.

The author, dev.to user wiktormalyska, also built a tool to address it: mcp-secrets-runner, an MIT-licensed, zero-dependency Node package that fetches secrets from a secret manager at startup and then launches the real MCP server.

Keys committed, screenshotted and pasted

Nearly every MCP setup guide shows the same pattern: the .mcp. config file passes environment variables straight to the server process, so a Stripe secret key ends up as a literal string inside the file. According to the post, those files routinely get committed to repositories, synced between machines, captured in tutorial screenshots and pasted into bug reports — and the author writes having seen live Stripe keys in all four situations.

In the author's experience, this is the single biggest reason MCP adoption stalls at a company's security review. Not the protocol, not the tooling — the config file.

The obvious fix expires with your login

Wrapping the server launch in a secret manager's CLI removes the key from the file, but introduces a new failure mode. Those CLIs typically authenticate using a developer session stored in the OS keyring, and sessions expire. When one does, every MCP server wrapped this way stops starting at the same moment, and the MCP client — which knows nothing about secret managers — reports a generic startup failure. The author describes losing an afternoon to this before recognising the pattern.

Machine identities at process start

The post's solution leans on a concept every serious secret manager already has: a credential meant for machines rather than humans, with no expiry of its own. Infisical calls it a machine identity, 1Password a service account, and HashiCorp Vault an AppRole. The credential is long-lived; the tokens it produces are short-lived and exchanged at process start.

mcp-secrets-runner sits between the MCP client and the server: it authenticates with the machine credential, fetches the secrets and then execs the real server. The config file contains no secret values, and the author notes the same config works on every machine that has the machine credential in its environment — which is what makes it safe to commit.

The tool supports three backends, and the author points out they work nothing alike: Infisical mints a token over HTTPS and then hands off to the Infisical CLI; 1Password hands off to op run, which authenticates itself; Vault reads the secret over its HTTP API and starts the MCP server directly, with no CLI involved at all.

Diagnosing failures the client cannot explain

Because MCP clients report several distinct startup failures identically, the runner ships a doctor command that checks the usual suspects one line at a time: missing CLI, missing credentials, wrong instance URL, unreadable secret path.

Two implementation details stand out. All diagnostics go to stderr, because stdout belongs to the MCP protocol — a single stray byte would corrupt the JSON-RPC stream and produce a parse error pointing nowhere useful. And the runner fails closed: if credentials are present but authentication fails, it exits, because the alternative — a credential-less CLI invocation opening an interactive browser login — would hang the MCP server on stdin indefinitely.

Why it matters

MCP is becoming the standard way to connect AI agents to external tools, which means API keys with real permissions — payments, databases, cloud accounts — are now pasted into config files that developers treat like ordinary project settings. The .mcp. habit imports an old problem, secrets in dotfiles, into an ecosystem where configs are shared unusually casually. The post also illustrates a subtler lesson for agent tooling: when a wrapper fails, the failure surfaces in a client with no visibility into the cause. Tools that keep stdout clean, log diagnostics to stderr and fail closed are the difference between a one-line diagnosis and a lost afternoon.