MCP security risks expose a new identity governance gap

At a glance

What this is: This analysis says MCP security problems arise because local, tool-connected runtimes expose command execution, prompt influence, and authorization weaknesses in one protocol stack.

Why it matters: IAM and NHI teams need to treat MCP servers as governed identities and execution surfaces, because the risks span credential scope, lifecycle control, and privileged tool access.

Context

MCP security is not just an application-layer problem. The protocol often runs local servers on user machines, where those binaries can reach files, network connections, and system commands, so the trust boundary looks much closer to NHI execution than to ordinary web software.

That matters because the identity question is not whether an LLM can call a tool, but whether the tool-connected runtime has been scoped, authenticated, and offboarded like any other privileged non-human identity. When those controls are loose, classic flaws become governance failures rather than isolated coding mistakes.

The article also points to a second problem: MCP is bidirectional, so servers can influence client behaviour and consume model capabilities in ways traditional API security does not fully capture. That makes lifecycle and authorization discipline part of the protocol decision, not an afterthought.

Key questions

Q: What breaks when MCP servers are not governed like integrations?

A: What breaks is the trust boundary. If an MCP server can connect an agent to tools or data without clear ownership, logging, and access limits, the server becomes part of the effective attack path. That creates hidden delegation and makes it harder to prove which actions were authorised.

Q: Why do MCP servers create more risk when they inherit user or service privilege?

A: Because they can become confused deputies. If the server performs actions with more privilege than the requesting user needs, an attacker can exploit the server’s authority to reach data or systems that should have remained out of scope. The risk is not only compromise, but over-delegation of trust.

Q: How do you know if MCP security controls are actually working?

A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Q: What should organisations do when a third-party MCP server changes behaviour?

A: Treat the change as a new trust event, not a routine update. Re-approve the server, verify the new capability set, and confirm that any added tool paths still operate under the same user-context and least-privilege constraints. If those checks cannot be completed, remove the server from use until they can.

Technical breakdown

Why local MCP execution expands the trust boundary

MCP servers often run as local executables through stdio, which means they operate inside the user environment rather than behind a hardened service perimeter. That gives them direct access to files, processes, and network resources, so any flaw in command handling or configuration becomes an execution problem, not just a data-validation issue. Remote HTTP transport changes the path but not the core exposure: the protocol still lets external capabilities touch local or sensitive resources. In identity terms, the runtime behaves like a non-human executor with broad ambient reach unless tightly constrained.

Practical implication: Treat each MCP server as a privileged runtime that needs explicit scoping, isolation, and inventory control.

How command injection and tool injection converge in MCP

Command injection in MCP appears when user-controlled fields are passed into system commands without sanitisation, allowing shell metacharacters to trigger arbitrary execution. Tool injection is adjacent but different: the model is steered toward a malicious tool name, description, or update path that looks legitimate at selection time. In practice, both problems exploit trust in the server’s declared behaviour. One attacks the command path, the other attacks the semantic layer the model uses to decide what to call. Together they show that MCP security depends on both code integrity and capability integrity.

Practical implication: Validate inputs, pin tool descriptions and versions, and review capability metadata as part of the approval process.

Why authentication and authorization failures become confused-deputy risk

The article highlights MCP cases where servers may act with elevated privileges rather than on behalf of the user, which is the classic confused-deputy pattern. In identity terms, the server becomes a proxy for privilege it should not inherit, especially when the protocol leaves authentication guidance minimal or inconsistent. That is an authorization design problem, not just a login problem. If the server can call tools, access data, or trigger actions without clear user-context enforcement, the system has effectively created a reusable privilege path that is broader than the task requires.

Practical implication: Bind every sensitive action to user context and remove service-level privilege inheritance wherever possible.

Threat narrative

Attacker objective: The attacker aims to turn a trusted MCP integration into a privileged execution and data-access path that can be used to steal information or run commands.

1. Entry begins when a user installs or runs a locally hosted MCP server from a third-party or community source, often through a configuration file that also defines executable commands.
2. Credential or capability abuse follows when the server receives untrusted input, uses deceptive tool naming, or exposes sampling and prompt channels that let the server influence or consume model resources.
3. Escalation occurs when the server acts with excessive permissions, reaches local files or system commands, or leverages confused-deputy behaviour to perform actions outside the requesting user’s intent.
4. Impact is achieved when the attacker gains arbitrary command execution, confidential data exposure, or uncontrolled access to connected services through the compromised MCP runtime.

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

Tool-connected identity is becoming the real MCP governance unit: MCP servers are not just software components, they behave like non-human executors with direct access to commands, files, and connected tools. That means the governance boundary is the server identity, its permissions, and its lifecycle, not the prompt alone. Security teams that still treat MCP as a simple integration layer will miss the real control point, which is whether the runtime is approved, scoped, and revocable.

Classic application flaws are now identity failures in a new wrapper: Command injection, deceptive naming, and confused-deputy behaviour are old patterns, but MCP turns them into identity governance issues because the exposed action surface is the tool-bearing runtime. The protocol’s bidirectional model means a server can influence behaviour as well as perform work, which widens the blast radius of any trust mistake. The practical lesson is that privilege, not protocol novelty, determines exposure.

MCP exposes an enterprise identity assumption that no longer holds: Tool-connected identities were designed for environments where action authority is stable enough to review, scope, and audit after issuance. That assumption fails when a local MCP runtime can appear, change, or disappear quickly while retaining access to system resources and connected services. The implication is that lifecycle governance has to cover ephemeral non-human execution paths, not just long-lived service accounts.

Ephemeral trust debt is the right concept for MCP: Every new server, description update, or local install adds temporary trust that often exceeds the actual verification performed. Because MCP can be sourced from community tooling and updated dynamically, organisations accumulate trust faster than they can validate it. That creates an approval debt that should be measured like any other identity risk. Practitioners should treat each newly enabled MCP server as a time-boxed exception until it is fully governed.

Protocol hardening will not succeed without governance hardening: Better authentication guidance and safer transport mechanics help, but they do not remove the need for inventory, version control, sandboxing, and offboarding. The article shows that security failures emerge at the intersection of local execution, capability exposure, and delegated authority. The field should stop framing MCP as a pure standards problem and start treating it as a non-human identity governance problem with protocol dependencies.

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

Ephemeral trust debt: MCP environments accumulate trust faster than they accumulate verification. The operational problem is not simply that servers exist, but that installations, updates, and local execution can outpace inventory, review, and revocation.

Access reviews alone are not enough when a server can be installed, altered, or removed faster than a certification cycle can react. Governance has to move closer to issuance time, version control, and runtime isolation, or the protocol will keep widening the gap between what is approved and what is actually running.

For practitioners

• Inventory every MCP server as a governed non-human identity Track each server, its source, transport mode, permitted tools, and connected systems. Treat unapproved community servers and ad hoc local installs as unmanaged identity risk, not as informal developer utilities.
• Sandbox MCP runtimes before granting system reach Run local servers in constrained environments with minimal file, command, and network permissions. Isolation should be the default until the runtime has been reviewed and its behaviour is understood.
• Validate tool metadata and freeze approved versions Pin tool names, descriptions, and package versions so updates cannot silently change behaviour. Re-review any server when its declared capabilities or prompt-facing descriptions change.
• Bind MCP actions to user context instead of service privilege Ensure that sensitive operations execute only under the requesting user’s authority. Remove inherited service-level privilege wherever the server can act on behalf of multiple users or workflows.
• Monitor MCP behaviour for prompt influence and command abuse Log server actions, sampling requests, and unexpected command patterns. Unusual capability use should trigger review before the runtime is allowed to keep operating.

Key takeaways

• MCP security failures are governance failures when local runtimes, tool selection, and delegated authority are trusted without sufficient scoping.
• Command injection, deceptive naming, and confused-deputy behaviour show that the main risk is not the protocol itself but the permissions it inherits.
• The practical control point is the governed lifecycle of each MCP server, including inventory, sandboxing, version pinning, and user-context enforcement.

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.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Bidirectional Protocol Abuse: Bidirectional protocol abuse occurs when a server or client can influence the other side’s behaviour as part of normal communication. For MCP, that means a server may not only execute tasks but also shape prompts, sampling, or tool selection, which expands the trust boundary beyond simple request and response.
• Capability Metadata: Capability metadata is the descriptive information that tells a client what a tool can do, how it should be called, and what name it presents to the model. If that metadata can change without governance, the model may route sensitive work to a tool whose behaviour no longer matches the approved intent.

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.