The short version
A sandbox puts a hard boundary around execution. NVIDIA OpenShell isolates each sandbox in its own container, or a microVM, with policy-enforced egress routing and minimal outbound access by default. Cloudflare Sandbox runs untrusted code in isolated containers at the edge. E2B provides cloud sandboxes through an SDK. ToolHive and Docker MCP Gateway containerize each MCP server. All of them decide where the agent may run and what it may reach.
An agent firewall reads what the agent sends through the connections that boundary allows. Pipelock inspects HTTP, WebSocket, and MCP traffic routed through it for credential leaks, injection, SSRF, and tool poisoning, and can emit signed action receipts for mediated decisions when a signing key is configured.
The sandbox is the wall. The firewall is the inspection at the gate in the wall.
How the sandboxes describe themselves
NVIDIA OpenShell is an Apache-2.0 runtime for autonomous agents. Its README describes each sandbox isolated in its own container with policy-enforced egress routing, a gateway that intercepts every outbound connection, minimal outbound access by default, and a short YAML policy the proxy enforces at the HTTP method and path level. NemoClaw builds on it.
Cloudflare Sandbox runs untrusted code in isolated containers with a full Linux environment, on the Workers Paid plan, for coding agents and CI-style workloads.
E2B ships an Apache-2.0 SDK for cloud sandboxes where agent-generated code runs.
ToolHive and Docker MCP Gateway contain MCP servers rather than the agent, each in its own container with network restrictions.
What a sandbox catches that a firewall doesn’t
Escape and host access. A malicious tool that tries to read host files or spawn processes is stopped by the container or microVM boundary. Pipelock’s own process sandbox is lighter than that.
Unlisted destinations, before any request. OpenShell’s default is minimal outbound access with an operator-approved allowlist. Nothing reaches a destination that is not on it.
Blast radius. A fully compromised agent inside a sandbox is still inside the sandbox.
What a firewall catches that a sandbox doesn’t
Content on allowed connections. An allowlist decides which hosts. A credential in a POST body to an allowed API passes the allowlist. Encoding-aware DLP on the wire catches it.
Injected responses from allowed servers. A permitted web page or MCP server can return instructions that hijack the agent. Response scanning catches it.
Poisoned and drifting tool descriptions. An allowed MCP server can change its tool description mid-session. Fingerprinting catches the change.
Evidence. Docker MCP Gateway documents logging and call tracing; the other sandboxes here do not document their block logs on the pages read. With a signing key and allow-path receipt enforcement configured, Pipelock refuses to forward an allowed mediated request whose signed receipt cannot be emitted. Its signed receipts verify offline against the operator’s key.
Side-by-side
| Agent sandbox | Agent firewall | |
|---|---|---|
| Boundary | Around execution: files, processes, destinations | Around traffic: what crosses the network boundary |
| Decides | Where the agent may run and reach | Whether what it sends and receives is safe |
| Reads | Policy and destination | Request and response bytes, tool descriptions |
| Failure it stops | Escape, host access, unlisted destination | Leaked secret, injection, poisoned tool, SSRF on an allowed path |
| Evidence | Sandbox and gateway logs | Signed, hash-linked receipts that pipelock verify-receipt checks offline against the operator’s published key, once a signing key is configured |
| Open-source examples | OpenShell, E2B, ToolHive, Docker MCP Gateway | Pipelock |
How to use both
[sandbox: minimal egress, filesystem and process limits]
agent -> Pipelock (inspect, decide, sign) -> allowed destinations
Run the firewall inside the sandbox as the proxy the agent is forced through, and make the forcing real: the agent’s container or network namespace gets no default route except the proxy, or host rules drop every outbound packet that did not come from the proxy’s user (pipelock contain installs and verifies nftables rules of that shape on Linux). An environment variable such as HTTPS_PROXY is a hint the agent can ignore, not a boundary. Wired that way, the failure direction is closed: if the proxy is down, misconfigured, or restarting, the agent has no route out and its requests fail rather than slip past. The firewall reads what goes there and signs the outcome. Inside HTTPS tunnels, payload scanning needs TLS interception enabled; without it Pipelock decides on hostname, SSRF, and rate limits at CONNECT time. For a single agent on one host, Pipelock’s own sandbox provides the process-level version of the first line.
Further reading
- Pipelock vs NemoClaw: NVIDIA’s reference stack on OpenShell
- Pipelock vs ToolHive: containerized MCP servers
- Pipelock vs Docker MCP Gateway: Docker’s container gateway
- Agent firewall vs guardrails: the other layer readers confuse with a firewall
- Pipelock on GitHub
Sources checked
Third-party descriptions on this page come from the public materials below, read on the dates shown. Features and pricing change; check the current documentation before you decide.
- NVIDIA/OpenShell README
- Cloudflare Sandbox SDK docs
- e2b-dev/E2B repository
- stacklok/toolhive README
- Docker docs: MCP Gateway
Third-party product names and marks belong to their owners. PipeLab is not affiliated with, sponsored by, or endorsed by the makers of any product compared on this page. Descriptions of other products come from their own public materials on the dates listed above and reflect PipeLab's reading of them. If something here is wrong or out of date, tell us and it will be corrected.