How do sandboxed MCP servers still create security risk?

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.

Why This Matters for Security Teams

Sandboxing is useful, but it is not a complete trust boundary for MCP. A sandbox can limit file, network, or process access on the server side while still leaving the client exposed to manipulated outputs, coerced follow-on tool calls, or cross-context data propagation. That matters because MCP is not just about isolated execution. It is about how the client interprets and routes results across sessions, tools, and identities.

Security teams often assume the server is the only thing that needs containment. In practice, the real risk emerges when a sandboxed server can shape orchestration decisions elsewhere, especially in multi-server or agentic workflows. The same pattern appears in broader AI risk reporting, where autonomous systems exceed intended scope even without obvious compromise, as described in AI Agents: The New Attack Surface report. For MCP-specific risk, NHIMG’s The State of MCP Server Security 2025 shows that access scoping and secret hygiene are still weak in real deployments. In practice, many security teams discover the boundary failure only after a client has already relayed the wrong instruction, not during initial sandbox design.

How It Works in Practice

Sandboxed MCP servers still create risk because the attack surface shifts from direct server compromise to influence. A server may not be able to escape its container, but it can still return crafted content, trigger client-side prompt injection, or induce the client to call another tool with attacker-shaped context. In other words, the sandbox protects the server process, but not necessarily the decision chain around it.

That is why current guidance suggests treating MCP as an orchestration problem, not just an execution problem. The practical controls are usually layered:

• Restrict what tools the client can invoke per session, not just what the server can access.
• Validate server outputs before they are used in downstream prompts or tool calls.
• Separate trust zones so one MCP server cannot silently influence unrelated servers through shared context.
• Use explicit approval steps for actions that move data, alter state, or access secrets.
• Log the full request chain so prompt relays and tool cascades can be reconstructed later.

This aligns with the broader control thinking in the OWASP Top 10 for Agentic Applications 2026, which emphasizes tool misuse, indirect prompt influence, and trust boundary confusion. It also maps closely to NHIMG’s OWASP Agentic Applications Top 10, where the issue is not merely whether a server is sandboxed, but whether the surrounding client and orchestration layer can be manipulated into doing more than intended. These controls tend to break down when multiple MCP servers share a session state or a common prompt workspace because one server’s output can become another server’s implicit input.

Common Variations and Edge Cases

Tighter sandboxing often increases operational overhead, requiring organisations to balance containment against developer friction and workflow latency. That tradeoff becomes more pronounced when MCP servers are used for code execution, retrieval, or chained agent workflows, where every additional approval step can slow legitimate work.

There is no universal standard for this yet, but best practice is evolving toward context-aware authorization and per-tool scoping rather than broad sandbox claims. A sandboxed server that only returns read-only data is lower risk than one that can influence write actions through a shared client session, especially if secrets or credentials are present in the environment. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the same operational point: identity, scoping, and secret exposure matter even when execution is isolated. Sandboxes also lose effectiveness when clients automatically trust tool output as instruction, because the weakest link becomes the orchestration logic, not the server host.

Related resources from NHI Mgmt Group

• Why do authenticated agents still create security risk in MCP environments?
• Why do header-based routing controls create new MCP security risks?
• Why do AI agents create new risk in non-human identity management?
• What is MCP in the context of AI security?