EVIDENCE TRAIL
Cross-client isolation
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The three named threats (T42 Cross-Client Interference, T43 Network Exposure, T45 Insufficient Isolation of MCP Server Permissions) are defined verbatim in the MAESTRO Multi-Agentic System Threat Modeling Guide v1.0. The MCP specification defines per-client session IDs but does not yet formalise multi-tenant isolation; the isolation mechanisms are supplied by the deployment environment (Linux namespaces, gVisor).
Last cross-checked against upstream sources: · 8 sources
References
Each entry shows what the source supports and what it does not prove.
MAESTRO Multi-Agentic System Threat Modeling Guide v1.0
MAESTRO Vulnerability Identification: Anthropic MCP — Layer 3: Agent Interaction Protocols
"Agent-to-Agent Communication (T42 - Cross-Client Interference via Shared Server): Multiple MCP clients (potentially belonging to different agents or users) connect to the same MCP server. A vulnerability in the server's implementation allows one client to interfere with the operations of other clients, for example, by modifying shared data, hijacking sessions, or triggering unintended actions."
Supports: Verbatim definition of T42, the primary named threat this control addresses. Confirms the threat model: shared MCP server, multi-client, session hijacking and shared-data interference as the attack surface.
Does not prove: Does not prescribe a specific isolation mechanism. The mitigation is Helmwart's synthesis of isolation primitives; the MAESTRO document names the threat but leaves countermeasures to implementors.
MAESTRO Multi-Agentic System Threat Modeling Guide v1.0
MAESTRO Vulnerability Identification: Anthropic MCP — Layer 4: Deployment Infrastructure
"T43 - Network Exposure of MCP Server: An MCP server is deployed without proper network security controls (e.g., firewalls, access control lists), making it accessible to unauthorized clients or attackers on the network. This is a deployment vulnerability."
Supports: Verbatim definition of T43. Establishes network exposure as a deployment-layer threat distinct from the application-layer isolation failure of T42. Supports the two-layer framing (application-layer session isolation + per-client network policy).
Does not prove: Does not address per-client network policy (mTLS, per-client egress rules) as a mitigation technique. Helmwart's mapping of mTLS to T43 blast-radius reduction is an extension beyond the MAESTRO text.
MAESTRO Multi-Agentic System Threat Modeling Guide v1.0
MAESTRO Vulnerability Identification: Anthropic MCP — Layer 6: Security & Compliance
"Identity Management (T45 - Insufficient Isolation of MCP Server Permissions): The MCP server itself is granted excessive permissions on the host system or network. This means that if the server is compromised, the attacker gains access to a wider range of resources than necessary. This is a violation of the principle of least privilege at the server level."
Supports: Verbatim definition of T45. Establishes excessive aggregate server permissions as the threat. Supports the per-client permission scoping layer: each client's tool calls evaluated against that client's permission set, not the server's aggregate set.
Does not prove: T45 as stated describes server-level over-privilege (a deployment misconfiguration), not the per-client scoping problem. Helmwart extends the T45 framing to cover the scenario where individual clients can reach the server's aggregate permissions — a refinement of the original threat statement.
Model Context Protocol Specification 2025-03-26 — Transports
§Streamable HTTP — Session Management
"A server using the Streamable HTTP transport MAY assign a session ID at initialization time, by including it in an Mcp-Session-Id header on the HTTP response containing the InitializeResult. The session ID SHOULD be globally unique and cryptographically secure (e.g., a securely generated UUID, a JWT, or a cryptographic hash)."
Supports: The MCP specification introduces an explicit per-client session model: session IDs are cryptographically unique, tied to initialization, and required on all subsequent requests from that client. This is the specification-level basis for per-client session-scope isolation.
Does not prove: The spec defines the session ID mechanism for a single client-server pair, not for multi-tenant server deployments serving multiple simultaneous clients. Multi-client isolation is an integration-time concern the spec does not yet formalise.
Model Context Protocol Specification 2025-03-26 — Transports
§Streamable HTTP — Security Warning
"When implementing Streamable HTTP transport: Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks … Servers SHOULD implement proper authentication for all connections."
Supports: The MCP spec explicitly REQUIRES per-connection origin validation and RECOMMENDS authentication for all connections — both are preconditions for the per-client isolation model this control implements.
Does not prove: The security warning addresses DNS rebinding and authentication; it does not address cross-client state leakage or per-client permission scoping within an already-authenticated multi-tenant session.
NIST SP 800-190 Application Container Security Guide
§2.2 Technical Capabilities — Container Runtime capabilities
"Namespace isolation limits which resources a container may interact with. This includes file systems, network interfaces, interprocess communications, host names, user information, and processes. Namespace isolation ensures that apps and processes inside a container only see the physical and virtual resources allocated to that container."
Supports: Verbatim description of Linux namespace isolation as the container security baseline. Directly supports the OS-level isolation layer in this control: running each client session in a separate Linux namespace to prevent cross-client process and resource access.
Does not prove: Does not address MCP servers or agentic AI. Applies to containers generically; the adaptation to per-client MCP session isolation is Helmwart's.
gVisor Architecture Guide — Security Model
gVisor Architecture Guide — Security Model — primary isolation goal
"gVisor was created in order to provide additional defense against the exploitation of kernel bugs by untrusted userspace code. The application's direct interactions with the host System API are intercepted by the Sentry, which implements the System API instead. Applications are not able to directly craft specific arguments or flags for the host System API, or interact directly with host primitives."
Supports: Verbatim statement of gVisor's isolation guarantee. Supports the highest-assurance deployment option named in this control: running client sessions in separate gVisor sandboxes for near-VM-level isolation without the full VM overhead.
Does not prove: Does not mention MCP or agentic AI. The applicability to per-client MCP session isolation is derived from the general "untrusted userspace workload" framing.
CWE-653 Improper Isolation or Compartmentalization
CWE-653 — Description and Extended Description
"The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions. When a weakness occurs in functionality that is accessible by lower-privileged users, then without strong boundaries, an attack might extend the scope of the damage to higher-privileged users."
Supports: Canonical weakness class for the failure mode this control prevents. "An attack might extend the scope of the damage to higher-privileged users" maps precisely to T42: a compromised lower-trust client exploiting shared state to reach data belonging to a higher-trust client.
Does not prove: Does not name MCP, agentic AI, or multi-tenant server deployments. Language-agnostic weakness definition; the MCP application context is Helmwart's.