How MCP Servers Expose Enterprise Secrets: Five Paths and the CVEs Behind Them

There is a useful way to think about where AI agent credentials actually live, and it is not the model. The model reasons. The MCP server authenticates. When an agent queries Jira or writes to a bucket, the tool call goes to a connector that holds a token and makes the real request. That design keeps secrets out of the context window, which is correct, and it relocates them into a component that most security programmes have never inventoried. MCP server secrets exposure is therefore a filesystem, identity, and supply-chain problem wearing an AI label, and it responds to conventional controls if you can find the servers.

A contributed piece published by The Hacker News on 17 August 2026, written by Ashley D'Andrea of Keeper Security, lays out five mechanisms by which this goes wrong. The framing is a vendor's and the underlying mechanics are not in dispute, so what follows takes each path and attaches the specific incidents and CVEs that demonstrate it, which is the part a vendor overview leaves out.

A leaked MCP credential does not only expose data. It hands an autonomous system the ability to act on it.Anomity Research

The five paths, at a glance

Path 1: the config file is the new .env

MCP servers routinely store tokens and keys in local configuration files, in plaintext. That file gets overlooked, copied between machines, and committed to a repository by accident. None of this is novel; it is the .env problem, inherited by a component that did not exist two years ago and therefore sits outside whatever secret-scanning and pre-commit hygiene the organisation already built.

What is new is the reader. A plaintext credential on a developer laptop used to require an attacker with code execution on that laptop. Now it also requires only an agent with local file access and a bad afternoon, because agents read config files as a matter of course. That is the mechanism in the lethal trifecta and the reason the GhostSplice researchers targeted .env and .ssh/id_rsa specifically: those paths are where the value is, and the agent can already reach them.

The fix is the standard one, applied to a new location: keep secrets in a managed store, inject them at runtime, and never persist them to the agent's working environment. Secrets management for AI agents works through the practices in detail. The MCP-specific addition is that you have to know which config files exist before you can empty them.

Path 2: sprawl, and the credential that never rotates

Without centralised storage, the same secrets end up duplicated across servers in development, staging, and production. The article's sharpest observation is about time rather than place: these secrets rarely get rotated, leaving them valid and static indefinitely.

Static is the operative word. A human credential has a lifecycle attached to an employee: onboarding, review, offboarding. An MCP server's token has no such anchor. It was created for a proof of concept by someone who has since changed teams, it works, and nothing in the system has an opinion about how old it is. This is the non-human identity problem in its most mundane form, covered in non-human identity governance, and it is why the survey finding that 63% of enterprises still report credential sharing somewhere in the fleet is entirely believable even among organisations that have issued per-agent identities, as discussed in the agent containment gap.

Path 3: injection turns a valid credential into an attacker's credential

Attackers hide instructions inside a document, support ticket, or web page the agent accesses, and the agent misuses a tool or reveals a secret. The important property is that no credential is stolen in the traditional sense. The legitimate credential is used, by the legitimate agent, to perform the attacker's request.

This is why vaulting alone does not close the path. A short-lived, properly scoped, freshly rotated token will happily service an injected instruction. Indirect prompt injection covers the general mechanism, and the current state of the art is worse than per-message filtering can handle: GhostSplice distributes the instruction across a tool description and two tool results so that no individual fragment is objectionable, and researchers report average model compliance rising from 42% to 82% as a result. MCP tool poisoning is the same idea placed in the tool metadata itself.

The control that survives contact with this is evaluation at the point of the tool call. The fragments are invisible; the outbound request carrying .env contents to an unfamiliar host is not.

Path 4: development scopes that shipped

Developers grant MCP servers broad permissions to get something working, and those permissions tend to reach production because nobody remembers to narrow them. The pattern is familiar from OAuth applications and CI service accounts. What differs is the actor at the other end: an autonomous system that will exercise the full breadth of a scope without the implicit self-restraint a human operator applies.

Concrete examples of scope failure in MCP implementations are already on record. The Kubernetes MCP server tool access bypass is a case where declared restrictions did not hold, and LiteLLM's allowed-routes privilege escalation is the same category in the gateway layer. Our own data on what agents ask for is in the most requested AI permissions, and the principle is worked through in least privilege for AI agents and AI access control and least privilege.

A practical rule: treat scope as something reviewed on promotion, not on creation. The scope that was reasonable on a laptop against a test project is the scope that becomes a production incident when the same config is copied to a shared runner.

Path 5: the connector itself

The strongest evidence in the piece is CVE-2025-6514 in mcp-remote, an OAuth proxy for MCP with more than 400,000 downloads, where a malicious server could trigger OS command injection and achieve remote code execution on the machine running the proxy. We covered it in mcp-remote OS command injection. The lesson is not that one package was flawed. It is that the MCP supply chain now includes proxies, bridges, and inspectors that developers install from a README without any of the review a production dependency would attract.

That class is well populated at this point: the MCP Inspector proxy unauthenticated RCE, the MCP Connect bridge unauthenticated RCE, Atlassian MCP SSRF to RCE, the Windows MCP unauthenticated PowerShell RCE, and the design-level exposure in stdio transport as an RCE surface by design. Add the fURI SSRF pattern across the ecosystem and the shape is clear: connectors are code, they run with the developer's privileges, and they were adopted at a speed no review process matched.

The mitigations, ordered by what they actually fix

Two entries in that table deserve emphasis because they are routinely treated as complete answers when they are not. Human approval degrades predictably: a reviewer approving twenty tool calls an hour is not reading them by the fifth, which is the approval-fatigue dynamic behind every blanket allow rule and the reason Claude Code's dangerously-skip-permissions flag gets set. And logging answers questions after the fact. An audit trail is essential evidence and it is not a control until something evaluates the call before it runs, which is the distinction drawn in how Claude Code hooks work.

The inventory is the precondition, not the last step

The article's final recommendation is to inventory all MCP servers to eliminate shadow AI, and it belongs at the top rather than the bottom. Every other control in the list binds to a specific server: you cannot vault credentials for a server you have not found, cannot scope its permissions, cannot review its supply chain, and cannot rotate what it holds.

In practice the gap between the architecture diagram and the endpoints is where the exposure lives. Developers install MCP servers from README snippets and one-click deeplinks, which is exactly how DeepJack worked, and the resulting population is invisible to provider-native tooling because it spans providers. How to build an MCP server registry covers the approval path, how to build an AI agent inventory covers the enumeration, and MCP security explained covers the protocol-level context. For the authentication design itself, OAuth for MCP servers and AI gateway OAuth passthrough explain why token passthrough patterns quietly widen the blast radius.

A working sequence

• Enumerate MCP servers from endpoints rather than from documentation, and reconcile the two lists. Expect the endpoint list to be longer.
• Sort the result by which servers hold credentials to production systems, and treat that subset as in-scope for immediate remediation.
• Empty the plaintext configs into a managed store, and switch to runtime injection so nothing durable remains on disk.
• Re-scope on promotion. Any server moving from a laptop to shared infrastructure gets its permissions reviewed as a gate, not as a follow-up ticket.
• Add tool-call evaluation for the specific pattern that matters: sensitive file contents appearing in the arguments of an outbound call.
• Alert on MCP servers appearing on endpoints outside the registry, and on installed servers whose tool surface changes after installation.
• Rotate anything a hostile or unreviewed server could have read, on the assumption that static credentials in an agent's reach have already been read once.

Where Anomity fits

Anomity supplies the enumeration the whole list depends on. A lightweight, unprivileged Endpoint Sensor inventories eight AI artifact types per machine - agents, MCP servers, skills, extensions, plugins, hooks, CLIs, and secrets - so plaintext credentials sitting beside an MCP config are a finding rather than an assumption. It is provider-agnostic, which matters because the same developer typically has servers wired into more than one client. Metadata only leaves the endpoint over HTTPS, and secrets are redacted on the endpoint before anything is transmitted, so the tool that finds your exposed credentials does not become another copy of them.

On agents that expose a hook, such as Claude Code's PreToolUse, runtime governance returns allow, deny, or log on each tool call before it executes, which is the layer that catches path three when filtering has already failed. Every added, changed, and removed artifact lands in a queryable 90-day audit trail, and violations route to your SIEM, Slack, email, and Jira through continuous policy evaluation. Anomity complements a secrets manager rather than replacing one: the vault fixes where credentials live, and Anomity tells you which servers still have credentials somewhere else. To see which MCP servers and secrets are present across your fleet today, book a 30-minute demo.