Sandbox isolation and network access
Understand how E2B sandboxes isolate workloads, what agents can reach, and which security controls remain your responsibility.
An agent in one hosted sandbox cannot read the memory, processes, or local filesystem of another sandbox. It can still make network requests to public services, including services exposed by another sandbox.
This distinction matters when you run untrusted agent code: compute isolation does not imply network isolation.
The isolation boundary
Section titled “The isolation boundary”Dreadnode runs each hosted sandbox in a separate E2B Firecracker microVM. Each microVM has its own Linux kernel, memory, processes, and local filesystem. A process must escape both the guest and the Firecracker virtualization boundary to reach the host or another microVM directly.
Agents may have broad privileges inside their own sandbox. They can run arbitrary commands, install packages, and modify local files. Those privileges stop at the microVM boundary.
| Resource | Isolated between sandboxes? | Enforcement |
|---|---|---|
| Memory and processes | Yes | Firecracker microVM |
| Local filesystem | Yes | Separate microVM storage |
| E2B project API | Yes | The E2B project API key stays in the Dreadnode control plane |
| Dreadnode runtime API | Yes | Per-sandbox bearer token |
| Public network services | No | Each service must authenticate its callers |
| Public internet | No | Outbound internet access is enabled for hosted sandboxes |
Evaluation agents and task environments also run in separate sandboxes. The agent cannot inspect the task environment’s files or processes. Dreadnode gives the agent only the public URLs declared by the task so it can interact with the intended services.
Access to another sandbox
Section titled “Access to another sandbox”A sandbox cannot enumerate or manage other sandboxes through the E2B project API because Dreadnode does not inject its E2B project API key into agent workloads. Dreadnode also checks the requesting user’s organization, workspace access, and sandbox ownership before allowing sandbox operations through the platform API.
Network services are a separate boundary. E2B assigns public URLs to services running inside a sandbox. By default, anyone who knows one of these URLs can send requests to it.
Dreadnode’s agent runtime API requires a per-sandbox bearer token. Services supplied by a task, such as a web application or API under test, define their own authentication. If a task service has no authentication, another sandbox or internet client that learns its URL can request it.
E2B supports traffic access tokens for restricting public sandbox URLs. Dreadnode does not currently expose this as a customer-configurable setting. See E2B’s public access controls for the provider capability.
Internet and private networks
Section titled “Internet and private networks”Hosted E2B sandboxes have outbound public internet access. Agents can download packages, clone repositories, call public APIs, and send data to external hosts.
E2B blocks traffic to private and link-local address ranges outside the guest, including:
10.0.0.0/8100.64.0.0/10127.0.0.0/8169.254.0.0/16172.16.0.0/12192.168.0.0/16
This prevents direct access to common private-network and cloud metadata addresses. It does not restrict public destinations. Dreadnode does not currently expose per-sandbox internet disable, domain allowlists, or IP allowlists for hosted E2B workloads.
E2B provides these controls at its network edge, including deny-all egress and domain or CIDR allowlists. See E2B’s internet access documentation for the provider capability.
Self-hosted OpenSandbox workloads follow your cluster’s network policy instead. See Sandbox runtime when choosing between E2B and OpenSandbox.
Credentials and customer data
Section titled “Credentials and customer data”Dreadnode limits the credentials available inside each sandbox:
| Credential or data | Control |
|---|---|
| E2B project API key | Held by the Dreadnode API and never injected into agent sandboxes |
| Evaluation and job API keys | Restricted to the platform scopes required by that workload |
| Interactive runtime API keys | Follow the initiating user’s platform permissions |
| Runtime bearer token | Unique to the sandbox and required by the Dreadnode runtime API |
| Workspace storage | Uses temporary credentials limited to one organization and workspace prefix |
| Model gateway key | Limited to permitted models, expires, and cleanup requests revocation |
| User secrets | Injected only when selected for the workload |
Processes inside a sandbox can read credentials and secrets injected into that sandbox. Because public egress is available, compromised or malicious code can send those values to an external host. Inject only the secrets the workload needs, and use the narrowest permissions available.
Lifetime and audit trail
Section titled “Lifetime and audit trail”Dreadnode gives sandboxes a bounded lifetime. Ephemeral evaluation and job sandboxes terminate after use or timeout. Durable interactive runtimes pause on timeout and terminate when reset or deleted. Cleanup requests revocation of linked platform and model-gateway credentials.
Dreadnode records sandbox ownership, provider identity, state transitions, runtime duration, and lifecycle events. Public sandbox traffic passing through Dreadnode’s proxy produces access logs. The platform does not currently provide a complete audit trail of every shell command, filesystem operation, DNS query, or outbound connection inside a sandbox.
Responsibility split
Section titled “Responsibility split”| Layer | Responsibility |
|---|---|
| E2B | Firecracker isolation, sandbox infrastructure, and provider network enforcement |
| Dreadnode | User authorization, workload credentials, runtime authentication, lifecycle, and cleanup |
| You | Data and secret selection, task-service authentication, and assuming agent code can reach the public internet |
For workloads that require deny-all egress, private-only service access, or complete network audit logs, reach out to us before deployment so we can review the architecture.