Notifications
Clear all
Topic starter
01/08/2026 8:55 pm
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.
NHIMG editorial — based on content published by Onyx: An MCP Server Walks Into a Bar. It Orders on Your Tab
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What breaks when shadow MCP servers are allowed into agent workflows without review?
A: The main failure is that trust moves faster than governance.
Q: Why do MCP servers create a bigger governance problem than ordinary third-party packages?
A: Because they sit inside an active decision layer.
Q: How do security teams know if an MCP deployment is outside its intended boundary?
A: Look for any server that is reachable beyond its expected network scope, accepts tool calls without strong identity proof, or can act on systems it was not explicitly scoped to touch.
Practitioner guidance
- Inventory every MCP server as a governed identity object Capture who installed it, which registry it came from, what permissions it requested, and which agents can invoke it.
- Enforce block-by-default controls for untrusted servers Allow only known-good MCP servers and deny everything else by policy, especially in developer environments where local installs and remote connectors can bypass normal change control.
- Compare declared tool permissions with observed runtime behaviour Inspect whether the toolset at first run still matches the reviewed posture, and alert on drift, unexpected browser launches, credential access, or data movement that was not part of the approved use case.
What's in the full article
Onyx's full post covers the operational detail this analysis intentionally leaves for the source:
- The specific mcp-remote vulnerability chain, including how crafted authorization responses can lead to command execution.
- The malicious postmark-mcp release pattern, including the slow-roll trust strategy used before the backdoor behaviour appeared.
- The agent-layer control model for inventory, posture inspection, and runtime detection, with the operational workflow behind each.
- The references to JFrog and Snyk analysis that support the technical attack patterns discussed in the source.
👉 Read Onyx's analysis of shadow MCP servers and the agent-layer control gap →
MCP server security risks: what IAM and security teams are missing?
Explore further
01/08/2026 9:03 pm
Shadow MCP server sprawl is now an NHI governance problem, not just an application hygiene problem. Once a server is installed into an agent workflow, it becomes part of the identity surface that can move credentials, tokens, and data. Traditional software inventory is too static for that role because the meaningful risk appears at install time, approval time, and first execution time. Practitioners need to treat these servers as governed non-human access paths, not as ordinary developer convenience layers.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security's The State of MCP Server Security 2025.
- Astrix Security also found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which shows how often secret handling fails at the source.
A question worth separating out:
Q: Who is accountable when a malicious MCP server exposes enterprise data or actions?
A: Accountability sits with the organisation operating the agent, the team approving the server, and the owners of the connected systems. The important governance question is whether provenance checks, runtime policy, and audit logging were in place before the server was trusted. If they were not, the failure is shared and preventable.
👉 Read our full editorial: MCP server security risks expose the blind spot in agent tooling
