What is Container Escape (Agent)?
Container escape in the agent context is when an agent running inside a containerised MCP server breaks out of the container boundary to access the host system.
WHY IT MATTERS
Containerisation is a common deployment pattern for MCP servers — each server runs in its own Docker container with isolated file systems, networks, and process spaces. Container escape defeats this isolation, giving the agent (or a tool running within the container) access to the host machine and potentially to other containers.
Escape vectors include exploiting kernel vulnerabilities accessible from within the container, abusing mounted host directories or Docker sockets, leveraging excessive Linux capabilities granted to the container, and using network access to reach the container orchestration API (e.g., Kubernetes API server).
In MCP deployments, the risk is elevated by common configuration mistakes. Developers mount host directories for convenience (giving tools access to the host file system), run containers in privileged mode for compatibility, or expose the Docker socket to enable container management tools. Each of these practices weakens container isolation.
A successful container escape is catastrophic in multi-tenant environments. If multiple users' agents share a host (each in separate containers), an escape from one container can compromise every other container on the same host — accessing other users' data, credentials, and tool outputs.
HOW POLICYLAYER USES THIS
Intercept operates as an external policy layer, enforcing rules before tool calls reach the containerised server. Even if the container is compromised, Intercept's YAML policies restrict which tools can be invoked and with what arguments — limiting the operations available for exploitation. Policies that block shell execution tools, restrict file paths, and deny network access to infrastructure endpoints reduce the attack surface available for container escape attempts.