MCP server security risks expose the blind spot in agent tooling

At a glance

What this is: This analysis says MCP servers create a hidden security layer where vulnerable or poisoned servers can be installed and abused before teams notice.

Why it matters: It matters because practitioners need governance over NHI and agent toolchains, not just endpoint or registry visibility, to stop credential theft and supply-chain compromise.

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.

👉 Read Onyx's analysis of shadow MCP servers and the agent-layer control gap

Context

MCP server security is becoming an identity problem as much as a software supply-chain problem. Once an agent installs a server and begins calling tools through it, the server inherits trust from the surrounding workflow even if its provenance, permissions, or runtime behaviour were never properly reviewed.

The practical gap is visibility. Teams can miss both the vulnerable package that turns a benign install into code execution and the poisoned package that waits until first run to steal secrets or alter behaviour. That creates a governance blind spot across NHI, developer tooling, and agent-connected workflows.

Key questions

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. A server can be installed, connected, and used before anyone checks provenance, scope, or runtime behaviour. That creates a path for credential theft, data exfiltration, or injected commands inside workflows that teams assumed were controlled.

Q: Why do MCP servers create a bigger governance problem than ordinary third-party packages?

A: Because they sit inside an active decision layer. The server is not just code on disk, it is a tool path that an agent can invoke with real permissions and live data. That makes install-time trust, runtime intent, and revocation all part of the same governance decision.

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. Strong warning signs include localhost servers accessible from the browser, public endpoints with no auth, and tool catalogs that exceed the intended use case.

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.

Technical breakdown

Why shadow MCP servers evade normal software controls

Shadow MCP servers sit in a difficult middle ground. They are not always centrally deployed software, and they are not simple browser plugins either. In practice, developers install them directly into agent workflows, often from public registries, then connect them to tools and data sources with little review. That makes provenance, versioning, and trust decisions happen outside traditional application governance. When a package like mcp-remote has a critical command-injection flaw, the exploit path can begin at install time and finish during the first connection to an untrusted server. The control gap is that standard asset inventory and EDR tooling do not always treat this as a distinct runtime identity risk.

Practical implication: inventory MCP servers as identity-bearing software and block unknown installers or unreviewed packages at intake.

How poisoned MCP servers abuse trusted installation patterns

A poisoned MCP server is a supply-chain trap. It behaves normally long enough to earn adoption, then changes behaviour after trust has been established. In the Postmark case described by Onyx, a malicious npm package released benign versions before introducing backdoor behaviour that could send emails to attacker-controlled destinations. This pattern is effective because teams often review the name, not the runtime behaviour, and because the first harmful action may occur only when the server is invoked through a legitimate agent session. The security problem is not just malicious code. It is the delay between trust establishment and abuse.

Practical implication: verify installed-server posture continuously, not just at approval time, and compare declared toolsets with observed runtime behaviour.

Why agent-layer visibility is the only control plane that sees the full picture

The agent layer is where install context and runtime calls converge. A registry sees a package, an endpoint sees a process, and a DLP tool may see fragments of content, but none of them alone can answer whether the agent is invoking an unreviewed server, whether that server has drifted from its approved posture, or whether it is exfiltrating data through legitimate-looking tool calls. That is why agent-layer monitoring is not a nice-to-have overlay. It is the place where inventory, posture inspection, and runtime detection can be correlated fast enough to matter. Without that correlation, teams are left with partial evidence after the damage is done.

Practical implication: route MCP findings into a developer workflow that can block, review, and revoke access before the next agent session begins.

Threat narrative

Attacker objective: The attacker wants to turn trusted agent tooling into a covert path for credential theft, data exfiltration, and persistence inside developer workflows.

1. Entry occurs when a developer installs a shadow MCP server from a public registry or connects to a remote server through a vulnerable client path.
2. Escalation follows when the server exploits trust at first run, executes injected commands, or abuses legitimate tool permissions to access credentials and environment variables.
3. Impact is reached when the server exfiltrates secrets, sends data to attacker-owned destinations, or establishes persistence through backdoor behaviour.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Ephemeral trust debt: MCP environments create a window where a server is trusted before it has earned that trust operationally. That concept matters because the first harmful action may happen within minutes, long before routine review cycles can react. This is a supply-chain and runtime control problem at once, which means governance has to track who installed the server, what it can do, and whether observed behaviour still matches approval.

Agent-layer visibility is the only control that can reconcile install provenance with runtime intent. Onyx is pointing to a structural truth: the registry does not see post-install behaviour, the endpoint does not understand tool semantics, and email or DLP controls do not capture the agent's full decision path. The implication is that MCP governance cannot be outsourced to a single point product. Security teams need a control plane that can inspect installation, posture, and execution together.

Onyx's analysis validates a broader identity lesson for autonomous tool ecosystems: trust is not a property of the package name. Trust depends on whether the server is scoped, observed, and revocable throughout its life cycle. That is the same governance logic practitioners already apply to privileged service accounts and other NHI classes, and the MCP case shows how quickly it breaks when runtime visibility is absent.

From our research:

• 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.
• For broader agent governance context, see AI Agents: The New Attack Surface report for visibility and policy findings across enterprise deployments.

What this signals

Ephemeral trust debt: Teams should expect MCP risk to move faster than quarterly review cycles. If a server can be installed and abused within a single session, governance must shift from periodic approval to continuous intake, posture, and runtime correlation.

The operating model should also reflect broader agent risk data. With 80% of organisations reporting AI agents have already performed actions beyond their intended scope, the adjacent lesson for MCP is that tool access cannot be assumed safe simply because the server appears legitimate at install time.

Practitioners should align MCP controls with agentic AI guidance and NHI governance together, using the OWASP Top 10 for Agentic Applications 2026 and NIST Cybersecurity Framework 2.0 as baseline references for inventory, detection, and response.

For practitioners

• 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. Treat unknown or unreviewed servers as blocked until they are explicitly approved and tied to an owner.
• 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.
• Route detections into the developer workflow that can act immediately Send findings to the team that owns the agent or server, so they can revoke access, remove the package, or quarantine the workflow before the next session continues.

Key takeaways

• Shadow MCP servers create an identity blind spot because install trust and runtime abuse can happen before normal controls react.
• The evidence points to both supply-chain poisoning and vulnerable client paths, which means governance must cover provenance, posture, and live execution together.
• Practitioners should treat MCP servers as governed non-human access paths and block unknown tools by default until they are reviewable and revocable.

Key terms

• 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 visibility: The ability to see what an agent installed, what tools it can call, and what it actually does at runtime in one place. This matters because neither registry data nor endpoint monitoring alone can reliably show the full identity and control story for MCP-based workflows.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the hidden risk that appears when short-lived tokens create a false sense of safety while permissions remain broad. The credential expires quickly, but the underlying blast radius stays large unless identity scope, revocation, and audit controls are also tightened.

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.

👉 The full Onyx post covers the vulnerable-server and poisoned-server patterns, plus the runtime visibility controls behind them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 identity security programme, it is worth exploring.