If your team has connected an AI assistant to anything real in the last year, there is a good chance an MCP server is running somewhere in your infrastructure. It might have been set up in an afternoon, by someone who needed the assistant to reach a database, and it is probably still running.
That server holds credentials. A risk analysis published on 17 August 2026 sets out what happens when nobody treats it as the security boundary it has become.
What the server actually is
The Model Context Protocol is an open standard, originally introduced by Anthropic, that lets AI assistants connect to external tools and data. Instead of being limited to what a model already knows, an agent can pull a record from a database, open a file, or call an API.
The piece that makes this work is the MCP server: a small program sitting between the assistant and the system it wants to use, exposing the specific actions the agent is allowed to perform.
And that is exactly where the risk concentrates. To act on a system, the server needs that system’s credentials. As the analysis puts it, the server “typically holds the keys to everything it touches: credentials, service account keys, API tokens and other secrets.”
The shift that matters: agents no longer only produce answers, they take action. A leaked secret from an MCP server does more than expose data. It hands an attacker the ability to act on it.
Five ways the secrets get out
Plaintext credentials in config files. Getting a server running often means pasting a configuration string that contains the credentials themselves. That file sits on disk, gets copied between machines, and occasionally gets committed to a repository.
Credential sprawl across ungoverned servers. Without a central place to store secrets, every agent manages its own. The same keys scatter across config files and environment variables, duplicated between development, staging and production. Because nobody holds a full inventory, they rarely get rotated and stay valid indefinitely.
Prompt injection. Agents read and act on the material they are given, which makes any text they process a potential instruction channel.
Over-permissioning. A server set up quickly tends to get broad access, because narrowing it takes time and breaks things during setup.
Exposed servers. The analysis notes that this exposure often develops before security teams know the server is running at all.
The named example is worth keeping: mcp-remote, described in the analysis as “an OAuth proxy downloaded over 400,000 times that runs on the client machine,” through which “a malicious server could trigger OS command injection.” That is CVE-2025-6514.
What that number is and is not
Four hundred thousand is a download count for one proxy tool. It is not a count of vulnerable installations, and the analysis does not give one.
That distinction matters more than it looks, because a download figure is the easiest number in the story to reach for and the least meaningful one to quote. Nobody has published how many MCP servers are exposed. If you see that number somewhere, ask where it came from.
The five countermeasures, as written
The analysis lists five, and they read as a checklist rather than a strategy:
- “Stop hardcoding secrets and centralize them”
- “Use short-lived credentials and rotate them automatically”
- “Enforce least privilege”
- “Keep a human in the loop for sensitive actions”
- “Encrypt secrets with a zero-trust, zero-knowledge model”
None of this is novel security thinking. That is the point. These are the practices that were already standard for production credentials, applied to a class of server that frequently got set up outside the process that would have enforced them.
The awkward question to ask on Monday
Anyone running agent tooling can work through the list above in an afternoon. The value sits in the inventory.
Start with the question the analysis implies rather than states: does anyone have a list of which MCP servers are running, who set them up, and what each one can reach? In a lot of organisations that list does not exist, because each server was added to solve one problem by one person, and none of those additions felt like infrastructure at the time.
The second question follows from the first. For each server on that list, what would an attacker be able to do with what it holds, beyond reading it. An agent with write access to a ticketing system, a deployment pipeline or a customer database is a different exposure from one that can only fetch documents.
And the third is about the material your agents read. Prompt injection works because agents act on text they are given, which means every document, page and message an agent processes is part of the attack surface. Most organisations publish and ingest a great deal of text without ever asking what an automated reader would do with it.
None of these questions require a security team to answer. They require someone to write the list.
Sources
- The Hacker News, “How MCP Servers Can Expose Enterprise Secrets”, 17 August 2026: https://thehackernews.com/2026/08/how-mcp-servers-can-expose-enterprise.html (retrieved 26 August 2026). Source of the five exposure categories, the five countermeasures quoted verbatim, the description of MCP and the MCP server’s role, and the mcp-remote example including the download figure and CVE-2025-6514.
