TL;DR: Shadow MCP servers create two recurring failure modes: vulnerable packages that can execute code within minutes of install, and poisoned servers that appear legitimate before exfiltrating credentials or messages on first run, according to Onyx and referenced research from JFrog and Snyk. The core issue is not protocol design alone, but the absence of visibility, posture review, and runtime control around agent-installed tools.
At a glance
What this is: This article shows how shadow MCP servers create two recurring risks, vulnerable code execution and poisoned packages that exfiltrate data at first run.
Why it matters: It matters because IAM, NHI, and platform teams need inventory, posture, and runtime controls around agent-installed tools, not just protocol-level trust assumptions.
Context
MCP server security risks sit at the intersection of agent tooling governance and non-human identity exposure. The core problem is that a developer can install a server that looks legitimate at install time, yet the organisation may not know whether that server is vulnerable, poisoned, or quietly abusing credentials once it runs.
In practice, the visibility gap is broader than a single bad package. Once an agent installs and invokes a remote MCP server, the relevant controls shift from software cataloguing to lifecycle oversight, posture inspection, and runtime observation of tool calls under the developer's identity.
The article's examples are typical of a fast-moving early-adoption pattern: useful servers, malicious lookalikes, and weak assurance at the point of use. That makes MCP a governance problem as much as a tooling problem.
Key questions
Q: What breaks when an MCP server is not the one the team intended to trust?
A: The failure is provenance, not just code quality. If a lookalike package can replace the intended MCP server, the agent may still function while sending data or messages through the wrong implementation. That means trust must be anchored in publisher verification, package integrity, and approval of the exact server artifact before the agent is allowed to use it.
Q: Why do shadow APIs and MCP servers increase compromise risk?
A: They increase risk because they expand the trusted call surface without necessarily inheriting mature authentication, authorisation, or lifecycle controls. If an attacker or agent can reach an interface that the security team never formally governed, that interface becomes a ready-made path into the environment.
Q: How can organisations tell if an MCP server is safe enough to use?
A: Look for evidence that every tool is bound to a narrow role, every session is logged, every credential is short lived, and unexpected outbound behaviour is blocked at runtime. If any one of those elements is missing, the environment is still relying on trust rather than control.
Q: What should teams do when an MCP server reaches privileged systems?
A: Treat privileged MCP servers as high-risk identity surfaces and require stronger approval, narrower scope, and auditable logging before connection. The key decision is not whether the server is convenient, but whether the control layer can still deny dangerous actions at the moment they occur.
Technical breakdown
Why vulnerable MCP servers create an execution path
A vulnerable MCP server is not risky only because it contains a CVE. In the scenario described here, the server can be connected to by a client, then process crafted input from an authorization response and turn that into command execution on the endpoint. The key technical point is that the exploit path sits in the connection flow, not in a separate malware dropper, so the malicious action can happen during an otherwise ordinary tool hookup. That makes trust in the server package and trust in the runtime behaviour two different questions.
Practical implication: treat server installation and first connection as an execution boundary, not a routine software add.
How poisoned MCP servers hide until first run
A poisoned MCP server is designed to pass install-time scrutiny and then misbehave at invocation. The article's example shows a trusted-looking package that shipped many benign versions before a backdoor version started diverting email flow. Technically, this is supply-chain abuse combined with runtime deception: the package reputation, registry presence, and name can all look normal while the tool performs credential theft, exfiltration, or persistence after execution begins. The pattern is especially dangerous when the server is remote and never visibly lands on the endpoint.
Practical implication: verify server behaviour after install, not just package provenance before download.
Why agent-layer visibility is the control point
The article argues that the agent layer is where install history, tool composition, and actual runtime calls converge. That matters because registries see packages, CASB sees broad cloud activity, and DLP sees content, but none of them cleanly ties a specific installed MCP server to a specific agent action in context. Without that joined view, posture drift and malicious tool use remain hard to distinguish. The technical control therefore lives where the agent's install record and tool invocation record can be correlated quickly enough to matter.
Practical implication: centralise install, posture, and runtime telemetry for agent-installed servers in one control plane.
Threat narrative
Attacker objective: The attacker wants to turn a trusted-looking MCP server into a launch point for credential theft, command execution, or persistence.
- Entry occurs when a developer installs a remote MCP server that appears useful or reputable enough to connect immediately.
- Credential harvesting or code execution follows when a vulnerable server is invoked or a poisoned server runs and exposes environment variables, secrets, or commands.
- Impact occurs when the attacker gains access to credentials or persistence that can be used beyond the original tool session.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shadow MCP servers create a governance blind spot, not just a software risk. The central failure is that install-time trust is being used as a proxy for runtime trust, even though the article shows those are different moments with different failure modes. Organisations need to treat agent-installed servers as governed identity-linked components, not as ordinary packages. The practitioner conclusion is that inventory without runtime correlation is not enough.
Install-time review does not substitute for posture assurance. A server can look legitimate when it is added, then drift through a dependency flaw or a malicious update before anyone notices. That means the review boundary has to include what the server is allowed to do after installation, not just what it claims to be. The practitioner conclusion is that posture inspection must be continuous, not ceremonial.
Identity blast radius is the right named concept for this problem. MCP servers inherit the developer's operating context, so a compromised or poisoned server can reach credentials, messages, and other tool-accessible data faster than most review cycles can react. That widens the consequence of a single bad install from one package to the surrounding identity footprint. The practitioner conclusion is to govern the blast radius around the agent, not the registry listing alone.
The protocol cannot enforce operational trust boundaries by itself. The article is explicit that the security question lives above the protocol, in how organisations inventory, inspect, and observe agent-installed tools. That makes this a control-plane problem: the field now needs policy that distinguishes approved servers, inspected servers, and actually used servers. The practitioner conclusion is that protocol adoption without control-plane governance will keep producing blind spots.
NHI governance now has to include tool provenance and runtime use. In practical terms, MCP servers behave like privileged non-human components because they can act on behalf of users while handling secrets and messages. That means lifecycle thinking has to extend from onboarding to offboarding, with a clear answer for who installed the server, who approved it, and who can revoke it. The practitioner conclusion is that delegated tool use is part of identity governance, not a separate silo.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Identity blast radius: MCP servers inherit enough of the user's context to make one bad install far more consequential than a simple package issue. Teams should assume that remote tools can move from utility to exposure channel in a single session, which is why install-time trust is not a sufficient control boundary.
The operational signal to watch is not just volume of server installs, but whether posture drift and runtime behaviour are being correlated in the same workflow. When those signals are separated, detection arrives after the agent has already used the server, which is too late for meaningful containment.
For practitioners
- Inventory MCP servers at install point Track what exists, who installed it, when it was added, which registry it came from, and what permissions it requested.
- Block unknown servers by default Allow only known-good MCP servers and require explicit approval before remote servers can be connected to by agents.
- Inspect installed server posture Compare the toolset and declared behaviour of each server with what was reviewed at install time, and treat drift as a warning signal.
- Correlate agent runtime calls Monitor what the agent actually does with each server so credential use, exfiltration, and suspicious tool chaining are visible in context.
- Route detections back to developers Send alerts into a workflow the engineering team will act on, rather than leaving MCP findings isolated in a security dashboard.
Key takeaways
- Shadow MCP servers create a trust gap between what looks safe at install time and what actually runs at invocation time.
- The article's examples show both code-execution and credential-exfiltration paths, which means package reputation alone is not a usable control.
- Inventory, posture inspection, and runtime correlation are the controls that move MCP governance from blind trust to enforceable oversight.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Poisoned MCP servers can exfiltrate credentials, environment variables, and secrets on first run. |
| NHI-03 — Vulnerable Third-Party NHI | The article centres on third-party MCP servers that look legitimate but are vulnerable or backdoored. | |
| Recommendation — Scan installed MCP servers for secret-handling exposure and revoke any tool that can leak credentials. Review third-party MCP servers for provenance, trust, and update integrity before allowing execution. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Agents can invoke MCP tools in ways that turn a trusted server into a code-execution or exfiltration path. |
| Recommendation — Map MCP tool calls to approved agent actions and block unsafe tool use at runtime. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes credential theft and secret exfiltration as the key attack outcomes. |
| Recommendation — Track MCP abuse as credential access and exfiltration activity in your detection pipeline. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is governed access to agent-installed tools and their permissions. |
| Recommendation — Apply PR.AA-05 to limit MCP permissions to the minimum required for each approved server. | ||
Key terms
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Shadow MCP Server: An MCP server that exists in an environment without being fully visible, approved, or governed by the teams responsible for identity and access. In practice, it becomes a hidden trust path for tools, data, and credentials, especially when developers install it directly into agent workflows.
- Poisoned Server: A seemingly legitimate server that behaves normally at first and then changes behaviour after trust has been established. The risk is not only malicious code, but delayed abuse that can exfiltrate secrets, alter outputs, or persist inside a workflow before security teams notice.
- Agent Layer: The agent layer is the part of an AI workload where the system makes runtime decisions and takes actions. It includes prompt handling, tool calls, code execution, network access, and data retrieval. In security terms, this is where control-plane visibility ends and behavior-based risk begins.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org