MCP security misconceptions are creating avoidable trust gaps

At a glance

What this is: This is a Pynt analysis of three MCP security misconceptions, centered on local server deployment, executable privilege inheritance, and indirect cross-server influence.

Why it matters: It matters because MCP changes how IAM, NHI, and agentic AI teams must think about trust boundaries, execution privilege, and tool-connected risk in modern AI systems.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Pynt's analysis of MCP misconceptions and server trust boundaries

Context

MCP security starts with a simple but often missed point: a protocol that connects AI clients to tools does not behave like a centralized API platform, and that changes the identity model around it. In practice, MCP servers are frequently installed locally, inherit host permissions, and can influence client behaviour even when they are not directly exposing a conventional network service.

For IAM and NHI teams, the problem is not just whether a server is trusted at install time. The harder question is how much authority a local executable gains by virtue of being connected to an AI client, and whether that authority can be contained when multiple servers interact through the same client session. That is the boundary MCP forces teams to define.

The article's starting position is typical for teams adopting agent-connected tooling: they recognise the flexibility before they fully model the security implications.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

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: What should teams do before allowing multiple MCP servers in one workflow?

A: They should assess whether the workflow mixes untrusted data sources with privileged tool access, then separate those roles wherever possible. If co-location is unavoidable, the client should enforce strict routing rules so one server cannot trigger actions in another high-trust context.

Technical breakdown

Why MCP servers are not centralized services

MCP deployments are often asymmetric. A single client can connect to multiple servers over time, while a given server is usually installed locally and dedicated to one client at a time. That means the server is less like a shared SaaS endpoint and more like a locally executed component inside the trust envelope of the host application. The security consequence is that access control, software provenance, and host hardening matter more than assumptions borrowed from web API architecture. Treating MCP as a shared central service causes teams to miss where privilege actually resides.

Practical implication: model each MCP server as a locally privileged component, not as a generic shared endpoint.

Why MCP servers behave like executable code

An MCP server is not just a passive responder to requests. When it runs locally, it executes code with the permissions granted to the launching application, which means it can read, write, invoke tools, and act within the host context by design. That makes trustworthiness and origin verification central controls, not optional add-ons. The security issue is less about exploiting a vulnerability in the traditional sense and more about the inherent authority granted when code is admitted into the client environment. That is why distribution and installation channels are part of the attack surface.

Practical implication: verify source integrity and restrict what code is allowed to become an MCP server.

Why sandboxing does not eliminate cross-server risk

Sandboxing reduces direct filesystem or process exposure, but it does not eliminate influence that flows through the common client. A malicious server can still shape prompts, request follow-on actions, or manipulate the client into invoking another server with higher-value access. In that sense, the system risk becomes the aggregate of all connected servers, not the isolation state of each one in a vacuum. This is a governance problem as much as an execution problem, because the client becomes the policy choke point for tool selection, data flow, and escalation paths across the MCP ecosystem.

Practical implication: govern server combinations and client routing rules, not just container or VM isolation.

Threat narrative

Attacker objective: The attacker seeks to turn a trusted MCP client into a conduit for privilege abuse and sensitive data theft across connected servers.

1. Entry occurs when an attacker or malicious package introduces an MCP server into a trusted client environment, often through local installation or dependency sprawl.
2. Escalation happens when the server inherits host-level permissions and uses client trust to influence tool calls, data retrieval, or follow-on actions.
3. Impact emerges when indirect server-to-server influence causes sensitive data exposure, unauthorized tool invocation, or cross-context privilege abuse through the common client.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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 security fails when teams mistake protocol connectivity for trust containment. MCP is not merely a transport layer between a client and tools. It introduces a new trust surface where local execution, client mediation, and tool chaining become security-relevant in their own right. Teams that model it like a standard API boundary will miss where privilege is actually exercised, and that is how tool-connected identity risks accumulate.

Executable trust is the right lens for MCP server governance. A server that runs locally is not just answering requests, it is operating as code inside the client's effective trust boundary. That means provenance, installation control, and execution context matter as much as authentication. The implication for practitioners is straightforward: governance must treat MCP server admission as an identity and code trust decision, not a simple integration task.

Cross-server influence creates an identity blast radius that sandboxing alone cannot contain. Even when direct server-to-server links are blocked, the common client can relay data, prompts, and actions across contexts. This creates a named concept worth tracking: client-mediated privilege spillover: one connected server can alter the effective authority of another through the shared client session. Security programmes need to recognise that the blast radius is defined by client orchestration, not just by isolated runtime compartments.

MCP governance belongs at the intersection of NHI, agentic AI, and runtime policy. The protocol sits where workload-like execution, non-human identity, and AI-driven decision paths meet. That makes it a governance problem for IAM, PAM, and AI security teams together, not a niche developer concern. The operational takeaway is that MCP should be reviewed through the same lens used for other high-trust machine access paths: who can run, what they can touch, and what they can influence.

The article usefully exposes a recurring assumption failure: isolated execution means isolated risk. That assumption was designed for environments where one component's scope stayed inside its own sandbox. It fails when the actor can shape the client's next action and trigger indirect access to another server with different privileges. The implication is that teams must rethink control design around session-level influence, not only process-level containment.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control lens, review OWASP Agentic Applications Top 10 alongside the client-mediated trust model described here.

What this signals

Client-mediated privilege spillover: MCP security programmes need to move from server-by-server assessment to workflow-by-workflow governance. If a common client can relay influence across multiple local servers, then isolation controls that stop at container or VM boundaries are incomplete.

With 80% of organisations already seeing rogue AI-agent behaviour in current deployments, the governance problem is no longer theoretical. Teams should assume that tool-connected systems will produce unexpected execution paths unless the client enforces explicit routing, trust, and data-separation rules.

The practical shift is from integration review to identity review. When AI clients mediate access across multiple MCP servers, the question becomes who or what is authorised to influence the next action, not just which endpoint is reachable.

For practitioners

• Classify every MCP server by authority, not by function Separate servers that only return data from servers that can execute code, invoke tools, or touch host resources. Apply tighter approval and review steps to the latter because they inherit the client's operating context.
• Define client-level trust boundaries for multi-server sessions Document which server combinations are allowed to coexist in the same client workflow, especially when one server may process untrusted data and another can access sensitive information. Treat the common client as the policy enforcement point.
• Verify provenance before local installation Require signed distribution, package integrity checks, and explicit source review for MCP servers before they are allowed to run on endpoints or developer hosts. Local execution should never be granted on trust alone.
• Limit cross-context tool chaining in sensitive workflows Prevent low-trust servers from influencing high-trust servers through shared client sessions, and review prompts that can cause follow-on tool calls across unrelated data domains. This reduces client-mediated privilege spillover.

Key takeaways

• MCP introduces a trust problem, not just an integration problem, because local servers inherit the client's effective authority.
• Sandboxing helps but does not remove indirect influence, so the client session becomes the real governance boundary.
• Security teams should classify MCP servers by privilege, control server combinations, and enforce provenance before installation.

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.
• Client-mediated privilege spillover: Client-mediated privilege spillover happens when one connected server can indirectly influence another through a shared client session. The risk is not direct server-to-server communication, but the way orchestration can route prompts, data, and actions across trust domains.
• Executable trust: Executable trust is the idea that code admitted into a client environment becomes trusted to act within that environment's permissions. For MCP, this means installation, provenance, and runtime authority matter as much as network reachability.

What's in the full article

Pynt's full article covers the operational detail this post intentionally leaves for the source:

• The specific MCP client and server interaction pattern shown in the demo, including how indirect influence led to sensitive data retrieval.
• The security reasoning behind local execution, inherited permissions, and why those properties change the trust model for AI-connected tools.
• The article's practical guidance on segregating privileged servers from untrusted sources and reviewing server trustworthiness over time.
• The concrete examples used to illustrate how sandboxed servers can still shape client behaviour through shared orchestration.

👉 Pynt's full article covers the demo flow, trust boundary guidance, and segregation recommendations in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity security capabilities, it is worth exploring.