The credential store nobody inventoried: MCP servers now hold the keys to everything they touch

The Hacker News has published an explainer arguing that Model Context Protocol servers leak enterprise secrets through plaintext configuration files, over-permissioned access and prompt injection, frequently before a security team knows the server is running at all ^[1]. That matters because the server in the middle typically holds credentials, service account keys, API tokens and other secrets for every system it touches ^[4], and once an agent is an active identity, a stolen secret is not just disclosure but the ability to act ^[5].

The mechanics are unglamorous. MCP is an open standard, originally introduced by Anthropic, that lets AI assistants reach external tools and live data instead of working from model knowledge alone ^[2]. The server is the broker: it advertises the actions an agent is permitted to take, and to perform any of them it needs the target system's credentials ^[3]. Agents decide which tools to call using non-human identities such as API keys and tokens ^[5]. So the same component that makes an agent useful is, in practice, a credential concentrator ^[4].

Four failure modes in the piece are the ones worth taking to a control review. First, storage: MCP servers routinely keep the tokens and keys they need in local configuration files, often in plaintext, and standing a server up frequently means pasting in a configuration string that contains the credentials themselves ^[6]. A file like that gets forgotten on disk, copied between machines, or committed to a Git repository by accident, and anyone who reaches the server can read everything in it ^[7].

Second, sprawl. With no central store, each agent manages its own secrets, the same keys and tokens end up duplicated across config files and environment variables in development, staging and production ^[8], and because nobody holds a full inventory they are rarely rotated and stay valid indefinitely ^[9]. That is the definition of a credential store operating outside secrets management.

Third, scope. Developers grant broad permissions to stop hitting authorization errors while building, and those generous scopes tend to ship to production once forgotten, so a single compromise reaches far past the task at hand ^[11].

Fourth, the attacker who never breaks in. Instructions hidden in a document, a support ticket or a web page the agent reads can be treated as legitimate commands, and the agent can be talked into misusing its tools or handing over the secrets it was trusted to hold ^[10]. That is prompt injection working against a component with production keys in a local file.

Two caveats on the material. It is a single explainer, and both supplied copies are the same text, so nothing here is corroborated prevalence data ^[15]; there are no incident counts, no survey numbers and no sample of deployed servers. The one concrete artefact is CVE-2025-6514 in mcp-remote, an OAuth proxy, cited as evidence that connecting to an untrusted server, in an ecosystem where anyone can publish one, can turn against you ^[12].

What to watch: whether MCP configurations start showing up in secret-scanning results on internal repositories ^[7], whether anyone can produce an inventory of which agents hold which non-human identities ^[9], and whether the scopes handed to servers during development are ever narrowed before production ^[11]. The source's own framing is the right question to put to engineering leads: what secrets are being handed to AI, and what protects them after they arrive ^[14].