MCP security misconceptions are creating avoidable trust gaps

At a glance

What this is: This is a Pynt analysis of three MCP misconceptions, showing that local servers are executable code, usually client-specific, and still able to influence other components through the client even when sandboxed.

Why it matters: IAM and security teams need to model MCP as a trust-boundary problem, because server installation, permission inheritance, and indirect influence can change the effective blast radius of AI-integrated workflows.

Context

Model Context Protocol security is not just about transport or tool access. The core problem is where teams place trust when an MCP server is installed locally, runs as executable code, and inherits the permissions of the client that launched it.

The article argues that common mental models are misleading: MCP servers are usually not centralized shared services, and sandboxing alone does not remove indirect influence through the client. For identity and access practitioners, that shifts the discussion from network placement to trust boundaries, privilege inheritance, and server provenance.

That makes MCP a governance issue as much as a technical one. If a client can mediate actions across multiple servers, then the effective security model depends on how those servers are allowed to affect decisions, data access, and downstream execution.

Key questions

Q: What breaks when MCP tools are exposed through one shared server?

A: Shared exposure collapses role separation. A requester, approver, and auditor may all inherit more capability than they need, which makes it harder to prove who did what and why. The result is weaker accountability, more difficult recertification, and a larger blast radius if the server is misused.

Q: How do sandboxed MCP servers still create security risk?

A: Sandboxing blocks some direct access paths, but it does not stop a server from shaping the client's next action or influencing other servers through shared orchestration. If the client can relay prompts, data, or follow-on requests across contexts, the security boundary has shifted from the sandbox to the client session.

Q: How should security teams govern MCP server privilege inheritance?

A: Treat inherited privilege as a delegated authority problem. Teams should restrict which servers can be installed, verify their origin, and map the client actions they are allowed to influence before granting access to host resources or sensitive data. The question is not whether the server is active, but how much authority the client passes to it.

Technical breakdown

Why local MCP servers are not shared services

MCP servers are often deployed as locally installed components tied to a single client rather than as centrally shared APIs. That matters because the trust model is closer to software you run on the host than to a neutral network endpoint. In practice, the server is part of the client’s execution context, so its permissions, data reach, and operational risk are determined by where and how it is installed. Security teams that model MCP as a shared back-end service will miss the real boundary: local code operating with client-adjacent privilege.

Practical implication: inventory MCP servers as locally trusted software components, not as ordinary API endpoints.

How executable MCP servers inherit privilege

An MCP server is not just a passive responder. When installed locally, it behaves as executable code and typically inherits the permission level of the launching client application. That means the server can perform privileged actions by design, without any exploit being required. The trust problem is therefore not only malicious compromise, but also whether the server’s origin, packaging, and permitted actions are trustworthy enough for the access it receives. This is a classic trust amplification pattern: a small trusted component can extend its reach through the client’s authority.

Practical implication: verify server provenance and restrict the privileges a client can delegate to installed MCP code.

Why sandboxing does not eliminate indirect influence

Sandboxing reduces direct access, but it does not remove the ability of one MCP server to shape client behaviour that affects other servers. The article’s example shows a malicious server using the client as an intermediary to trigger additional actions and expose sensitive data. That creates an indirect influence path rather than a direct server-to-server path. In security terms, the aggregated capability of the ecosystem can exceed the apparent capability of any single isolated server, because the client becomes the decision bridge between them.

Practical implication: treat client-mediated influence as part of the threat model even when servers are isolated in containers or VMs.

Threat narrative

Attacker objective: The attacker aims to use the MCP client as a trust bridge to obtain sensitive user data without needing direct server-to-server access.

1. Entry occurs when a malicious MCP server is installed alongside a benign server in a client environment and the user invokes a normal request through the client application.
2. Credential or data access follows when the malicious server manipulates the client into retrieving sensitive transaction data under the guise of a challenge.
3. Escalation happens when the client submits that sensitive data back to the malicious server, expanding the server’s reach through client-mediated trust.
4. Impact is the exfiltration of user data through a path that bypasses the assumption that sandboxed servers cannot meaningfully influence one another.

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

Local MCP deployment breaks the shared-service assumption: MCP servers are not usually centralized resources that many clients consume in a uniform way. They are commonly installed locally and attached to a single client, which means their trust boundary sits much closer to the endpoint than teams expect. That changes governance from API-style access management to software provenance and host-level containment. Practitioners should stop treating MCP as a generic integration layer and start treating it as locally trusted execution.

Executable code with inherited privilege is the real trust pivot: An MCP server is not merely answering requests, it is code running in the same operational context as the client. The article’s key point is that privilege is inherited by design, so the risk is not only compromise but over-trust. This is a direct NHI governance problem because the server’s effective authority comes from delegated runtime access rather than static network placement. Teams need to evaluate what authority the client is implicitly lending to each server.

Sandboxing does not remove client-mediated influence: The security mistake is assuming that isolation ends the threat. A sandboxed server can still steer the client into actions that affect other connected servers or data sources, which makes the client itself part of the attack surface. Client-mediated influence collapse: the control boundary that matters is not server-to-server communication, but whether the client can be induced to relay trust across isolated components. Practitioners should redesign trust boundaries around mediated action, not just process separation.

Assumption collapse for MCP is about decision locality, not just isolation: The security model assumes a server’s influence stays within the scope of the session or component that launched it. That assumption fails when the client aggregates multiple servers and reuses its authority to satisfy chained requests. The implication is that boundary enforcement must account for how trust is recombined inside the client, not only where code is executed. Security teams should rethink delegated execution as a governed relationship, not a simple deployment choice.

The category is moving toward trust-boundary governance, not endpoint hygiene: MCP security will increasingly be judged by how well organisations constrain provenance, privilege inheritance, and cross-server influence. That is a stronger test than merely checking whether the code is sandboxed or locally installed. For identity leaders, the practical takeaway is that AI integration now creates a new class of governed delegation path, one that sits between application control, workload identity, and runtime trust.

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

Trust-boundary drift: MCP programmes fail when teams collapse software provenance, runtime privilege, and client-mediated influence into one approval step. The effective control boundary is the client’s delegated action path, not the presence of a sandbox alone.

MCP adoption should push identity teams to separate installation trust from execution trust. That distinction matters because a local server can behave like trusted code even when it is sourced from a third party and connected to sensitive client workflows.

For practitioners

• Define MCP trust boundaries explicitly Document which MCP servers may run locally, what data they may access, and which client actions they are allowed to influence. Separate installation trust from runtime trust so that a server’s presence does not imply broad authority.
• Treat server provenance as a control point Require verified origin, packaging integrity, and change tracking for every MCP server before it is allowed to operate in a client environment. A locally executable server should be reviewed like software, not merely onboarded like an API integration.
• Segment privileged and untrusted servers Keep servers that can execute commands or reach sensitive resources away from servers that process untrusted inputs such as web content or email. The goal is to prevent a low-trust server from shaping client decisions that reach a high-trust server.
• Test for client-mediated influence paths Simulate cases where one server induces the client to call another server or retrieve protected data. Review whether sandboxing still allows the client to combine trust across components in ways the architecture did not intend.

Key takeaways

• MCP security is mainly a problem of trust placement, because local servers run as executable components rather than neutral shared endpoints.
• Sandboxing helps, but it does not stop a server from influencing the client and thereby affecting other connected servers or data flows.
• Teams should govern MCP servers by provenance, delegated privilege, and client-mediated action paths, not by isolation alone.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Client-mediated influence: Client-mediated influence is the ability of one connected component to affect another through a shared client rather than through direct peer communication. In MCP environments, this matters because a sandboxed server can still shape client behaviour and expand the effective blast radius of a trust failure.
• Privilege Inheritance: Privilege inheritance occurs when a system uses the permissions of the human or service identity that launched it. For agents, this means the workload can access anything the parent role can access, which makes entitlement design more important than the model’s natural-language capabilities.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.