The sandbox was isolated. The shared service was not.

Isolation fails at the services around the sandbox

The strongest 2026 agent-security incidents keep returning to infrastructure that sits beside the model. Package services, local control planes, task stores, browser origins and connected apps decide what an agent can actually reach. A model can be inside a container while the surrounding service graph still connects it to another account or to the host.

The Check Point shared-clipboard research is the cleanest example. Separate ChatGPT code-execution environments could not communicate directly, but they could reach the same internal package service. The researchers used that service as a cross-account command and return channel.

The proof of concept then exercised the victim session's own authority. A hidden task caused the session to retrieve connected Gmail data and relay the result across accounts while the visible conversation still looked normal.

Shared infrastructure already mattered in the Hugging Face incident

OpenAI's July evaluation incident also crossed a shared service. According to OpenAI, agents exploited Artifactory paths, obtained unintended internet access and later reached third-party systems. Hugging Face's reconstruction follows the downstream chain into production.

The exact mechanisms differ from the Check Point proof of concept, but the architectural question is the same: which services are common to workloads that are described as isolated, and what authority do those services carry?

A useful isolation diagram therefore has more nodes than "model -> sandbox -> internet". It has package proxies, caches, credential stores, task queues, tool brokers, local agent services and connected apps.

MCP exposes the same problem at protocol level

Two MCP Python SDK advisories make the boundary easier to see because the defects are ordinary authorization and transport issues.

The experimental tasks vulnerability, CVE-2026-52870, did not bind a task to the session that created it. Another connected client could use task operations against work it did not own.

CVE-2026-59950 affected a deprecated WebSocket transport that did not apply Host or Origin validation. A hostile page in the victim browser could therefore reach a local or LAN MCP WebSocket if an application had explicitly wired that deprecated transport.

Neither advisory supports a claim that every MCP deployment is vulnerable. The task issue required the experimental tasks feature. The WebSocket issue did not affect FastMCP, stdio, SSE or Streamable HTTP. Those constraints are part of the finding.

Localhost is a location, not an authorization decision

AutoJack and Windows-MCP reinforce the same lesson. AutoJack combined hostile web content, a local browsing agent, a weak MCP WebSocket boundary and attacker-controlled process parameters. Windows-MCP's affected HTTP modes exposed a powerful PowerShell tool behind weak transport controls.

Loopback and LAN binding can reduce exposure. They do not prove that every process able to originate a request is trusted. Once an agent browses attacker-controlled content on the same machine, the browser becomes part of the threat model.

What to ask in an assessment

A good isolation review should enumerate shared services explicitly:

• Which services can every sandbox or session reach?
• Can one account create state that another account can read?
• Which local services trust Host, Origin or loopback location?
• Which long-lived tasks are bound to a client identity?
• Which connected apps can a hidden task invoke?
• Which package and proxy credentials are shared across workloads?
• Can accepted tool actions be correlated with the user-visible request?

The answer should be a system map and a set of tested controls, not a statement that the model "runs in a sandbox".

The recurring pattern is less exotic than the agent behavior around it. Isolation is only as strong as the shared infrastructure that remains reachable from both sides.