What is Sandbox Escaping?

MCP tools execute operations on the host system — reading files, running commands, making network requests. Sandboxing constrains these operations to a defined boundary: a specific directory, a restricted network, a limited set of system calls. Sandbox escaping defeats these constraints.

In the MCP context, sandbox escapes typically exploit tool capabilities that are broader than intended. A file system tool meant to access /workspace/ might be tricked into reading /etc/passwd through path traversal (../../etc/passwd). A code execution tool sandboxed to a specific runtime might escape through system calls, environment variable access, or network sockets.

The risk is magnified by the agent's role as an orchestrator. Even if individual tools are sandboxed, the agent can chain multiple tool calls to achieve an escape. Tool A reads a configuration file (within its sandbox), Tool B uses information from that file to construct a network request (within its sandbox), and the combined effect is accessing a resource neither tool should reach individually.

Sandbox escaping converts a constrained agent into an unconstrained one — and an unconstrained agent with access to production systems, credentials, and networks is an insider threat with machine speed.

Intercept adds a policy enforcement layer outside the sandbox boundary. Even if a tool escapes its local sandbox, the tool call must pass through Intercept's YAML policies first. Path validation rules reject traversal patterns, argument constraints block access to sensitive directories, and network policies restrict outbound destinations. This defence-in-depth means sandbox escaping must defeat both the local sandbox and the proxy-level policies.