By Adam Wolf
The Model Context Protocol (MCP) is how an AI agent reaches tools and data: a database, a repository, a search index. An MCP server usually runs as a local process on a developer’s machine. It’s launched by the client and reads its credentials from a file in the home directory. That was a reasonable default for one person on one laptop. It is a poor one for a component with standing access to production systems.
Why does it matter where an MCP server runs?
A local MCP server is not expected to log in to anything. The protocol tells it to read its credentials out of the environment instead, which in practice means a long-lived token sitting in a file on someone’s laptop.
MCP has two transports, and the current specification revision names them stdio and HTTP. With stdio the client launches the server as a local subprocess, and with HTTP each message is a request to an endpoint. Authorization only applies to one of them. The authorization specification states that “Authorization is OPTIONAL for MCP implementations,” that HTTP-based transports “SHOULD conform to this specification,” and that implementations using stdio “SHOULD NOT follow this specification, and instead retrieve credentials from the environment.”
This has been measured. Trail of Bits reported in April 2025 that “many MCP environments store long-term API keys for third-party services in plaintext on the local filesystem, often with insecure, world-readable permissions,” and found a Claude Desktop configuration file on macOS carrying permissions that “allow any process or user on the system to read the file's contents.” GitGuardian’s State of Secrets Sprawl 2026 counted “24,008 unique secrets exposed in MCP-related configuration files across public GitHub, including 2,117 unique valid credentials.”
What did the protocol change, and why does it matter for deployment?
MCP itself became stateless. That is the change that makes it practical to run MCP servers the way you already run other services.
Before the current revision, every session began with a handshake and carried a session identifier, which the protocol’s own Transport Working Group said in December 2025 forced “‘sticky’ routing that pins traffic to specific servers, preventing effective auto-scaling.” The 2026-07-28 revision removed the handshake, and the architecture documentation now states that “MCP is a stateless protocol.” A stateless request that any instance can serve behind an ordinary load balancer is something your existing infrastructure already knows how to run.
The same revision tightened authorization for HTTP transports around OAuth 2.1 and requires servers to “validate that access tokens were issued specifically for them as the intended audience.” That rule kills token passthrough, where a server accepts a token it was never the audience for and forwards it downstream.
Is remote automatically safer?
No. The measured data on that is unambiguous.
A May 2026 study of real-world remote MCP servers identified 7,973 live servers and found that “40.55% expose tools without authentication.” Among the 119 that did implement OAuth it found “each server exhibits at least one flaw, with a total of 325 flaws identified,” obtaining nine CVE identifiers through responsible disclosure. Moving a server off a laptop changes which mistakes are available to make rather than removing the risk, and about two in five of the remote servers running have no authentication in front of their tools.
The supply chain matters wherever it runs. Koi Security documented an npm MCP package that shipped fifteen clean releases before a backdoor appeared and began copying mail to an external address at a reported “1,500 downloads every single week,” and CVE-2025-49596 was assigned against MCP Inspector at CVSS 9.4.
How many MCP servers are actually vulnerable?
Fewer than the most-quoted numbers suggest. The gap between what automated scanners flag and what survives manual review is wide enough to matter to any argument you build on it.
The framing you will see most often is that the great majority of MCP servers are vulnerable, and that number comes from automated scanners. MCPZoo, a July 2026 preprint covering 64,611 unique MCP servers, reports, "While existing scanners report that 96.89% of servers are risky, we find that these signals are unreliable. In particular, manual validation shows that less than 50% of sampled alerts are true positives.” Trend Micro's sweep of over 19,000 repositories put the true positive rate at roughly 4.1%, and exploitable vulnerabilities in a range of 3.1% to 8.6%.
So do not build a business case on a scanner percentage, because a technical reviewer who reads the underlying papers will take the argument apart.
The case for governing MCP does not need an inflated number. It rests on something structural: a component with standing credentials to production systems, invoked by a non-deterministic actor, deployed by individuals, with no inventory.
The UK NCSC's guidance on prompt injection makes this concrete: "When an LLM processes information from a party, the privileges it has drops to that of the party.” If a tool description or a returned document can influence the model, the tool’s privileges are the blast radius, wherever the server runs.
Where do the serious sources actually disagree?
They disagree about where the server should run, and it would be dishonest to pretend otherwise.
The NSA’s Artificial Intelligence Security Center recommends, in a May 2026 information sheet on MCP, that you “prefer a local instance of MCP server to reduce the risk of data leakage” when private data is involved. Cloudflare argues close to the opposite, writing in April 2026 that local deployments “prevent IT and security administrators from administrating these servers, leaving it up to individual employees and developers to choose which MCP servers they want to run.” Cloudflare also sells remote MCP hosting.
Both are defensible because they optimize for different risks: the NSA minimizes the paths by which sensitive data can leave a controlled boundary, and Cloudflare minimizes the number of unmanaged components in an estate. Most enterprises will land on the boundary mattering more than the topology. Run the server wherever the data policy requires, and run it as a managed component with an owner, a known version, and credentials the user never holds.
What does a governed MCP deployment need to contain?
There are six things no matter if the server sits in your data center or in a cloud region.
| What a governed deployment needs | Why |
|---|---|
| An inventory | You cannot govern what hasn’t been listed. |
| A known version | Pinned deliberately, rather than whatever a package manager resolved that day. |
| Credentials the human never holds | Held by the platform and injected when the server launches. |
| An authenticated network path | Reaching the server is itself an authorization decision. |
| Identity on the request | The action is attributable to a person or an agent, not to a shared process. |
| A lifecycle | A server that stops being used stops running. |
In Klique, this is what the MCP Server Deployment application is for. It deploys remote MCP servers as containerized services rather than local processes.
| What the application handles | How |
|---|---|
| Server type | Documented presets for filesystem, PostgreSQL, GitHub, Brave Search, memory, fetch, SQLite, Slack, an everything preset, and custom. Each carries a default container image and startup script, and the image can be overridden per deployment. |
| Network routing | Three modes: http for authenticated routing, tcp for raw TCP, and None to disable routing. The documentation states the application “uses the App Gateway Router which implements a secure, authenticated network endpoint.” |
| Route assignment | Either a persistent route from the ones an administrator has defined, or a dynamic one. |
| Configuration and credentials | Injected as environment variables and configuration files written into the container before the server launches. |
| Secret custody | Administrator Vaults hold configuration and third-party service credentials centrally rather than with the person launching the server, and administrators can define multiple vaults, each applied to designated user groups. |
| Lifecycle | An idle time limit shuts the instance down. |
| Compute | Each deployment runs on a Klique queue serviced by the orchestrator, on compute the platform already governs. |
Central custody plus injection at launch is what addresses the plaintext-config problem this post opened with.
Two qualifications. Injecting a credential centrally moves custody without abolishing the credential, so a GitHub token should still be scoped narrowly and rotated. And none of this addresses prompt injection, which the NCSC says “may never be totally mitigated in the way SQL injection attacks can be.” What deployment discipline buys is a bounded and attributable blast radius when injection succeeds.
So where should your MCP Server run?
Start by finding how many you have, because almost every organization has more than it thinks. Then decide location by data classification rather than by convenience, which is the substance of the NSA’s advice, and apply the six requirements above to whatever you decide.
MCP is not a fringe experiment. It was donated to the Linux Foundation’s Agentic AI Foundation in December 2025, with founding members including AWS, Anthropic, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. It will be in your estate whether or not anyone approved it, and the only question is whether the servers it depends on are deployed like infrastructure or accumulated like browser extensions.
FAQ
What is an MCP server? A service that exposes tools, data, or capabilities to an AI agent through the Model Context Protocol. Common examples give an agent access to a filesystem, a database, a repository, or a search API.
Why is a local MCP server a credential risk? Because the specification does not expect stdio servers to authenticate. It directs them to retrieve credentials from the environment, which in practice means long-lived tokens in configuration files. Trail of Bits documented world-readable permissions on those files, and GitGuardian counted 24,008 unique secrets in MCP-related configuration files on public GitHub.
Is hosting MCP servers remotely more secure? Not by itself. A May 2026 study of 7,973 live remote MCP servers found 40.55% exposing tools without any authentication. Remote hosting helps when it comes with authentication, version control, central credential custody, and an inventory. Without those it just moves the problem.
Are most MCP servers vulnerable? That claim comes from automated scanners and does not hold up. The largest study of the ecosystem found scanners flagging 96.89% of servers as risky while manual validation confirmed fewer than half of sampled alerts as true positives. An independent sweep of 19,000 repositories put confirmed exploitable vulnerabilities in the range of 3.1% to 8.6%.
Does governing MCP deployment stop prompt injection? No. The UK NCSC’s position is that prompt injection may never be fully mitigated. Deployment discipline limits what a successful injection can reach and makes the action attributable, which is a different and more achievable goal.
What changed in the 2026-07-28 specification? MCP became stateless, the initialize handshake and session identifier were removed, HTTP with SSE was deprecated on a one-year offramp, and authorization requirements for HTTP transports were tightened around OAuth 2.1, protected resource metadata, resource indicators, and audience validation.
To see MCP servers deployed as authenticated services on governed compute, request a Klique demo.
