Shadow MCP servers are the new shadow IT
Engineers are connecting AI agents to company systems through MCP servers and agent skills installed outside any approval process. Security researchers report thousands of malicious skills, exposed servers, and a real case of a compromised package that copied emails to an outside server.
- An audit of 2,857 skills on ClawHub identified 341 overtly malicious packages, Noma reports, and 36.8% of 4,000 public agent skills contained exploitable security flaws, with 13.4% carrying critical remote execution or exfiltration vulnerabilities. Self-reported m:…3524
- Over 1,800 MCP instances were discovered exposed directly to the public web, and 100% of tested MCP endpoints enumerated their full tool catalogs to unauthenticated, external queries, according to Noma. Self-reported m:…3524
- The postmark-mcp package on npm was compromised in version 1.0.16 to blind-copy outbound communications to an external server, and the malicious package was downloaded 1,643 times before deletion. Self-reported m:…3524 m:…3948
- A published MCP server's tool instructs AI agents to obtain a GitHub token without user consent, using the gh auth token command to extract the GitHub CLI authentication token, Knostic reports. Self-reported m:…5245
- Serval says third-party MCP servers should undergo the same vendor review as other software, and requires OAuth 2.1 authentication for every MCP connection. Self-reported m:…3856
Installed in one command, trusted with everything
Shadow MCPs and agent skills represent the next phase of the operational evolution of shadow IT, according to Noma Security. Connecting an MCP server or installing an agent skill bypasses enterprise change-control pipelines and procurement checkpoints, because a developer types one command and the agent gains a new tool. The Model Context Protocol provides a standard way to connect AI agents to real systems, and MCP consists of a host, a client and a server, so the plumbing is simple by design. That simplicity is the risk. m:…3524
Shadow MCP servers and agent skills operate as active execution engines that inherit the full credentials and local access privileges of the deploying engineer, and local MCP servers run with the same privileges as the client. An MCP server is not a document the agent reads. It is code the agent can run, with the engineer's keys, files and network access behind it. Developers often install MCP servers from public registries using single commands, and MCP servers supply tool names, descriptions, input schemas and results to the model, which means the model takes instructions from whatever the server tells it. m:…3524 m:…3948
Traditional security tools like EDR, CASB and SCA fail to monitor agentic threats because they operate within local socket pipes, loopback calls and stdio. The traffic never leaves the machine in a way those tools watch, so the usual safety net has a hole exactly where agents operate. m:…3524
The registries are already poisoned
An audit of 2,857 skills on ClawHub identified 341 overtly malicious packages, and 36.8% of 4,000 public agent skills contained exploitable security flaws, with 13.4% carrying critical remote execution or exfiltration vulnerabilities. Public registries for agent skills are targeted with typo-squatted packages and malicious pre-install hooks, so the danger is not hypothetical. Roughly a third of public skills have a flaw an attacker can use, and about one in eight has a flaw that lets an attacker run code or steal data. m:…3524
The postmark-mcp package on npm was compromised in version 1.0.16 to blind-copy outbound communications to an external server. Security researchers reported in September 2025 that the postmark-mcp npm package copied a legitimate server, and the malicious package was downloaded 1,643 times before deletion. Version 1.0.16 of postmark-mcp added a line to blind-copy emails to an external address. A package that looked like a trusted email tool was quietly sending copies of everything it handled to someone else, and 1,643 installs happened before anyone stopped it. m:…3524 m:…3948
Knostic found a smaller, sharper example: a published MCP server, @agentdance/node-webrtc-mcp version 1.0.13, contains a prompt injection in its get_started tool description. The tool instructs AI agents to obtain a GitHub token without user consent, and uses the gh auth token command to extract the GitHub CLI authentication token. If a token is obtained, the server attempts to star the agent-dance/node-webrtc repository. The starring action is not required for the tool's primary function of generating WebRTC starter code, which makes the token grab look like a test of what agents will hand over when a tool description tells them to. m:…5245
The attack surface grows with every tool
Connecting an AI agent to more tools increases the potential attack surface, and prompt injection can influence which tools an LLM calls. Tool poisoning involves hiding malicious instructions in tool metadata, so the poison arrives inside the tool description itself, the part of the system the model is supposed to trust. Invariant Labs demonstrated tool shadowing, where a malicious server changes how an agent uses a trusted server, and Microsoft's Defender Experts team documented a case where an agent's tool combination created a security weakness. m:…3856
MCP servers can execute startup commands that download packages and exfiltrate SSH keys, and local MCP servers retrieve credentials from the environment rather than using OAuth 2.1 flows. Remote MCP servers introduce a third-party security dependency, and over 1,800 MCP instances were discovered exposed directly to the public web, with 100% of tested MCP endpoints enumerating their full tool catalogs to unauthenticated, external queries. An exposed server tells any stranger exactly what tools it offers, and then the stranger can try them. m:…3948 m:…3524
Authentication is not authorization in MCP server interactions, and the MCP specification warns against publishing omnibus scopes like admin:* and files:*. OWASP classifies software supply chain attacks and dependency tampering in MCP as MCP04. The message from the standards side is consistent: knowing who connected is not the same as deciding what they may do, and a server that asks for everything should be treated as a risk, not a convenience. m:…3856 m:…3948
What good control looks like
Third-party MCP servers should undergo the same vendor review as other software, Serval argues, and Serval MCP tool calls are governed by the same RBAC layer as its REST API. Serval requires OAuth 2.1 authentication for every MCP connection, uses OAuth for user connections to eliminate credential copying, and returns a 403 error for unauthorized MCP tool calls. The pattern is to route agent tool calls through the identity and permission layers the company already has, rather than letting agents connect directly. m:…3856
The MCP Security Specification mandates explicit command visualization and scoped approval prior to server registration. In plain terms: show the engineer what the server will run, and approve only the narrow permissions it needs, before it is registered. That is the control that would have caught the poisoned packages, the token grab and the exposed servers, if anyone had applied it. m:…3524
What is still unresolved
- How many shadow MCP servers are already running inside enterprises that have not inventoried them
- Whether registries will add vetting or whether enterprises must block unreviewed installs
- How the MCP Security Specification's approval rules will be enforced in practice
Provenance by Synorb. Every claim links to its source. This story was written by an agent from the Manifests listed below. Read the methodology and limitations, or send a correction.
Free to reuse, including commercially. Credit “Hanging Context, with provenance by Synorb” and link to this story. Keep the cited Manifest ids. Reuse terms v1.