MCP server security failures expose a hidden agentic attack surface

At a glance

What this is: This is an analysis of how MCP server security failures can turn agentic infrastructure into a hidden remote code execution and data exposure path.

Why it matters: It matters because identity teams now have to govern non-human access at the protocol layer, where agent actions, tool permissions, and downstream API exposure can outrun traditional IAM visibility.

By the numbers:

• Over 7,000 publicly accessible servers were in scope, and more than 150 million downloads were affected across the ecosystem.

👉 Read Salt's analysis of MCP server security failures and agentic execution risk

Context

MCP server security is now an identity governance problem as much as a software supply chain problem. The article describes a vulnerability in the Model Context Protocol SDK that can convert a trusted agent connection into remote code execution, which means the actor being governed is not the model alone but the non-human identity that carries tool access into internal systems.

For IAM, PAM, and NHI teams, the issue is that agentic workflows inherit authority through MCP servers, yet those servers are often deployed faster than they are inventoried, scoped, or reviewed. Once a prompt or tool call can pivot into OS command execution, the control boundary shifts from application logic to the identity and authorization model around the server itself.

The starting position described in the article is typical of modern agentic rollouts: low-friction deployment, broad connectivity, and weak visibility into what the intermediary layer is allowed to do. That is exactly why this issue escapes normal application security review.

Key questions

Q: How should security teams design MCP server access for AI agents?

A: Security teams should design MCP access around a small set of agent goals, not a mirrored list of REST endpoints. Group related backend calls into workflows, expose known data as resources, and reserve tools for actions that truly change state. That keeps the agent oriented, reduces context churn, and makes the access surface easier to review and govern.

Q: Why do MCP servers create a bigger risk than model prompts alone?

A: Because the dangerous outcome is not a bad model response, it is the trust bridge from prompt input to tool execution and enterprise access. Once an intermediary can act on behalf of an agent, the attacker can pivot into host commands, credentials, and data stores. The risk is therefore authority, not just content manipulation.

Q: What breaks when an agent middleware layer is not monitored as an identity?

A: Teams lose visibility into who or what can reach internal systems, which means access reviews, secret governance, and incident response all start too late. The failure mode is shadow non-human identity: a server acts with real authority, but no one owns its lifecycle or can quickly revoke its reach.

Q: Who is accountable when an agent leaks data through an MCP server?

A: Accountability sits with the teams that defined the trust boundary and the controls that failed to enforce it, usually identity, platform, and security owners together. If tool authorization, context validation, or monitoring was missing, the breach is a governance failure, not just a runtime incident. Shared ownership must be explicit before deployment.

Technical breakdown

How MCP server trust becomes execution risk

Model Context Protocol is designed to let agents call tools and data sources through a common interface. In practice, that means the MCP server sits between runtime decisions and enterprise resources, often with credentials or network reach that the agent itself never directly holds. When the server trusts inputs that can be influenced by prompt content or configuration state, the boundary between tool invocation and operating system execution collapses. The article's key point is not that models are unsafe on their own, but that the intermediary identity layer inherits too much authority with too little verification.

Practical implication: inventory every MCP server as a privileged non-human identity, not just as an integration component.

Why prompt injection at the MCP layer matters

Prompt injection is usually discussed as a model problem, but the real damage occurs when injected content can alter tool routing, configuration, or execution paths. In this case, the vulnerability can redirect a STDIO-based workflow into arbitrary OS command execution, which is a much stronger outcome than a bad answer from an LLM. That distinction matters because the security boundary is no longer the prompt itself. It is the trust relationship between the agent, the MCP server, and the underlying host environment.

Practical implication: separate prompt handling controls from host execution controls and assume the MCP layer can be attacker-influenced.

Why downstream API exposure is the endgame

Once an attacker reaches the MCP host, the valuable targets are usually not the server process itself but the secrets and sessions it can reach. API keys, database credentials, chat histories, and internal records are attractive because they let attackers move from execution to persistence and exfiltration. That is why MCP exposure is structurally similar to other NHI failures: one over-trusted credential or service path can open multiple systems at once. The governance issue is not isolated compromise, but concentrated blast radius.

Practical implication: classify MCP-linked secrets and backend connections by blast radius, then reduce the access each server can reach.

Threat narrative

Attacker objective: The attacker aims to turn a trusted agent integration into host-level execution and then extract sensitive data and credentials from the systems that MCP can reach.

1. Entry occurs when a crafted prompt reaches a public-facing interface connected to an MCP-backed agent workflow and influences the tool layer rather than the model output alone.
2. Escalation follows when the compromised MCP path redirects STDIO handling into arbitrary OS command execution on the server hosting the agentic workflow.
3. Impact occurs when the attacker reaches internal databases, API keys, chat histories, and potentially a live shell on the host.

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

MCP server security is now identity security, not just application security. The article shows that the exposed layer is neither the model nor the downstream database alone, but the non-human identity path that binds them together. When an MCP server can execute actions and reach internal systems, it becomes a privileged identity subject with governance requirements that look much closer to PAM and NHI control than to standard app review. Practitioners should treat every MCP deployment as a governed identity surface.

Protocol-level trust is the new attack surface. The dangerous part of MCP is not that it exists, but that it can inherit broad trust from the surrounding agent workflow without strong scoping. That creates an identity blast radius problem: one intermediary server can bridge prompt input, host execution, and enterprise data access in a single chain. Security teams need to think in terms of constrained authority, not just secure code.

Unmonitored agent middleware creates shadow NHI. The article describes a layer that many teams deploy faster than they can inventory, which is the classic shape of unmanaged non-human identity sprawl. If a server can act on behalf of an agent, touch APIs, and execute commands, it should not be treated as invisible middleware. The field needs to stop assuming that “agent platform” means lower risk than a service account.

OWASP NHI Top 10 is a better lens than model-centric AI security alone. The issue here maps to over-privileged access, missing inventory, and weak credential governance more than to model hallucination or content safety. That is why AI security programmes that stop at prompt filtering miss the real exposure. The right question is whether the agent's trusted execution path is bounded, reviewable, and revocable.

Runtime containment matters more than static approval of the protocol. The article makes clear that a design can be “expected” by the protocol author and still be operationally dangerous in enterprise use. That means practitioners cannot rely on upstream assurance once the MCP server is given real authority inside a production environment. Security ownership has to shift to the team running the identity and access path, not the team consuming the protocol.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, which is why configuration hygiene is now an access-control issue as much as a deployment issue.
• For a deeper threat-model view, see OWASP NHI Top 10 for the control patterns that map directly to agentic tool and secret exposure.

What this signals

MCP server sprawl is likely to become the default blind spot in agentic programmes. Teams that can name their models but not their intermediary servers are already behind, because the server is where execution authority, credentials, and host reach converge. This is the point at which identity governance moves from user access to runtime control, and that shift deserves the same rigor as privileged access in traditional infrastructure.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the governance problem is no longer hypothetical. Security programmes should expect more agent middleware to appear as unmanaged NHI unless inventory, scoping, and revocation are built into deployment workflows from the start.

Identity blast radius: When a single MCP server can bridge prompts, tools, APIs, and host execution, the limiting control is not model safety but the size of the server's reachable trust zone. Practitioners should use that lens to decide which agentic integrations are safe to operationalise and which need to be isolated or removed.

For practitioners

• Inventory every MCP-linked non-human identity Build a complete list of MCP servers, the agents that use them, and the internal systems each one can reach. Treat missing inventory as an exposure, because untracked servers can hold database access, API keys, or command execution paths that no one is monitoring.
• Scope tool permissions by business function and host reach Limit each MCP server to the smallest set of tools, APIs, and host actions required for its role. Remove default trust in STDIO-based execution paths and document which commands or data sources are explicitly authorized.
• Separate prompt handling from execution authority Do not let untrusted prompt content influence operating system commands, configuration changes, or credential retrieval. Use distinct controls for input validation, command mediation, and secret access so that one compromised interface cannot become full host control.
• Review secrets reachable from agent middleware Identify API keys, database credentials, and sessions that MCP-connected services can access, then reduce those privileges until the server cannot reach more than it needs. Prioritise secrets that would let an attacker move from execution to exfiltration.

Key takeaways

• MCP server security failures turn agent middleware into a privileged non-human identity problem, not just an application bug.
• The exposure is measurable: thousands of servers, tens of millions of downloads, and large volumes of secrets sitting in configuration paths.
• Teams need inventory, scope reduction, and execution containment before agentic workflows can be trusted in production.

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 AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Salt's full analysis covers the operational detail this post intentionally leaves for the source:

• The article's step-by-step explanation of how the vulnerable MCP path can reach arbitrary OS command execution.
• The specific languages, libraries, and downstream projects affected by the SDK issue.
• The article's view of which internal systems become reachable once an MCP server inherits real authority.
• The source article's recommended questions for teams trying to locate MCP servers and their permissions.

👉 Salt's full post covers the attack path, affected components, and the questions teams should ask now.

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 programme, it is worth exploring.