MCP servers are the new shadow AI surface

In July I wrote that your agents are shadow AI with credentials. Since then the conversation with almost every engineering leader I meet has moved on to something more specific. It is no longer the scheduled script in the corner. It is the coding agent on every developer's laptop, and the growing list of MCP servers plugged into it.

The pattern is always the same. A developer installs a coding agent, finds it useful, and within a week has given it a way to read the ticket queue, query the staging database, search Slack, and open pull requests. None of that went through anyone. It went through a JSON file in a dotfolder. And the security team, which has spent two years learning to see ChatGPT in the browser, has no idea it happened.

What MCP actually is

The Model Context Protocol is an open standard for connecting an AI application to external tools and data. An MCP server exposes a set of tools, each with a name, a description, and a schema. The agent asks the server what it offers, the model reads the descriptions, and when the model decides a tool is useful it calls it, gets the result back, and keeps going. The protocol is deliberately simple. That is why every major coding agent supports it and why there are now servers for nearly every system a developer touches.

The part security teams need to internalize is how a server gets attached. In the common local setup, the developer adds a few lines to a config file: a command to run, and the environment variables it needs, which usually means a token. The agent launches the server as a child process on the laptop. The MCP project's own security guidance asks clients to warn users that "MCP servers run with the same privileges as the client". In practice that means the same privileges as the developer.

Here is what a typical config looks like. Two of these lines are a production database credential with write access and a personal GitHub token, and the file sits in plain text in the developer's home directory.

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://app_rw:S3cret@db.internal:5432/prod"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_XXXXXXXXXXXXXXXXXXXX" }
    }
  }
}

Why this is shadow AI, not tooling

It is tempting to file MCP under developer tooling and leave it to the platform team. Three properties make it a security matter, and together they make it a sharper version of the shadow AI problem you already have.

What 2026 has shown so far

The risk stopped being theoretical this year, and the three cases below are worth knowing in detail because each hits a different layer of the same setup.

The protocol layer. On April 15, OX Security disclosed that the official MCP SDKs for Python, TypeScript, Java, and Rust pass the command in a server's STDIO configuration to the operating system without sanitization. Any process named in that config runs on the host, whether or not it is an MCP server. OX counted the affected SDKs at more than 150 million downloads, found over 7,000 servers reachable on the public internet, and estimated up to 200,000 vulnerable instances. Cursor, VS Code, Windsurf, Claude Code, and Gemini CLI were all in scope; in Windsurf's case exploitation needed no user interaction at all. Anthropic's position, as OX reports it, was that the behaviour is by design and that sanitizing the command is the developer's responsibility. Whichever side of that argument you take, the practical result is the same: the config file that attaches a server is itself an execution surface.

The agent layer. On July 1, Cato AI Labs published two flaws in Cursor, CVE-2026-50548 and CVE-2026-50549, both rated 9.8. Instructions hidden in content the agent reads, and the researchers named MCP server responses and web search results as the carriers, could make the agent write a file that disabled its own sandbox and then run commands with the developer's privileges. No click, no approval prompt. Cursor fixed it in 3.0, but the mechanism is the point: the data a tool returns is an input the model obeys, and the sandbox around the agent is only as good as the model's judgment about what it read.

The supply chain. On June 17, the npm organization behind Mastra, an open-source TypeScript framework for building AI agents, was compromised and a typosquatted dependency was added across more than 140 packages with a combined 1.1 million weekly downloads, according to StepSecurity's write-up. The payload went looking for exactly what lives on an agent developer's machine: OpenAI, Anthropic, and Google API keys, AWS and Azure credentials, database connection strings, and CI tokens. MCP servers are installed from the same registries with the same one-line commands. The people distributing malware have noticed where the credentials are.

Microsoft's incident response team put the underlying shift plainly in a June 30 post: "A prompt injection against a summarizer can bias an output. A prompt injection against an agent can trigger an action." And on MCP specifically: "Every MCP server an agent can call is a production dependency." That is the right frame. Most organizations are not managing these servers as dependencies. They are not managing them at all, because they do not know which ones exist.

Then there is the quieter failure, the one that needs no attacker. The database server was set up with a read-write account because that was the one the developer had handy. The file server was pointed at the home directory instead of the project. Every query result, every file the agent opened while working, went to the model provider under whatever terms the developer accepted when they signed up. Nobody chose any of that. It was the default.

Why your controls miss it

The tools you already trust were built to watch people in browsers. Your web proxy and your DLP see a request to a chat website and can act on it. An MCP setup does not look like that from any angle they have. The server runs as a local process and talks to the agent over standard input and output, so there is no network traffic to inspect between them. The agent then talks to the model provider over an encrypted API connection that, on most allowlists, is already permitted because you sanctioned that vendor for something else. From where your controls sit, a developer is using an approved AI service. What that service is being fed, and what it is being allowed to do, never crosses their field of view.

The MCP specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations". Every serious coding agent offers that prompt. Microsoft's advice in the post above is to turn off "Allow all" tool access. The reason they have to say it is that developers turn it on, because approving the fortieth tool call of an afternoon is not a security decision anyone makes carefully. DuneSlide needed no approval anyway.

Five questions to ask about every developer machine

As with agents, you do not need a platform to start. You need to be able to answer five questions. Where you cannot, you have found your first project.

1. Which MCP servers are configured? Across every coding agent in use, on every laptop. The config files have known locations. This is an inventory problem before it is anything else.
2. Which credential does each one hold? Whose token, with what scope, stored where. A personal access token with full repository rights in a plain-text config is a finding on its own.
3. What can each server read, and what can it write? A read-only server and a read-write server are different risks, and the difference is often one flag the developer never set.
4. Which model provider receives the output, under which account? A personal subscription and an enterprise agreement carry different data terms, and the config decides which one is in use.
5. Can you show what it did? When an incident or an auditor asks what the agent read and changed last Tuesday, is there a record anywhere outside the developer's terminal scrollback?

What governing MCP actually looks like

The instinct will be to ban it, and I would push back on that harder here than anywhere else. Coding agents with real tool access are the biggest change to how software gets written that most engineering teams have seen. Ban them and developers use them on personal machines with personal accounts, which is the shadow AI story again, with write access this time.

Governing it looks like this. Start with an allowlist of MCP servers, so "trusted server" in the specification's sense is a decision your organization has made, and the snippet a developer found on a forum is not on it by default. Give each server its own least-privilege credential: a read-only database role, a repository token scoped to the repositories the work needs, issued to that integration rather than borrowed from the person. Treat everything a tool returns as untrusted input, because that is where the injection arrives.

Then put the model calls themselves through a control point you own. When the agent reaches the model through a gateway instead of directly, every developer and every agent gets a virtual key bound to their identity, the data leaving for the provider passes a guardrail that can catch an injection or a secret on the way out, spend has a ceiling per key, and there is a tamper-evident record of every call. The five questions above stop being research projects and become a report. This is the same answer as for any other programmatic AI, which is the point: MCP is not a new category. It is the fastest-growing member of one you already need to govern.

Where this leaves you

A year ago the shadow AI conversation was about what employees paste into a chat window. This year it is about what their tools read on their behalf, and what those tools are allowed to do about it. The developer who wires four MCP servers into a coding agent on a Tuesday afternoon is not doing anything wrong. They are doing their job with the best tool available. The failure is if nobody on the security side knows it happened, and nothing sits between that setup and the systems it can now reach.