Security and limits

This page explains the security model, network rules, and limits of the Code Sandbox.

The security model

Model-generated code runs in an isolated sandbox container. Each sandbox runs exactly once and is destroyed right after. Code runs as a non-root user with no platform credentials. Code snippets have no network egress at all, not even DNS. If code loops forever, a hard timeout stops it. If code generates too much output, memory limits stop the sandbox safely.

Single-use sandbox execution

A sandbox environment is never reused across multiple executions. Consecutive runs always receive unique sandbox_id identifiers. Single-use execution eliminates cross-call state leakage and ensures a clean environment for every request.

Files written to the local filesystem during execution are permanently destroyed along with the sandbox container. Persistent data should be stored in an agent session or external database.

Network isolation and egress rules

Code snippet sandboxes invoked via run_python or POST /v1/execute operate under strict network egress controls:

• Snippet Sandboxes: No outbound connections of any kind. DNS is blocked too - a resolver that answers is an exfiltration channel, and model-written code has no reason to resolve anything. A lookup fails in about a second rather than hanging.
• Tool-call Sandboxes (/v1/call): Enable controlled external HTTP/HTTPS connectivity to reach external APIs. Access to internal cloud metadata addresses (169.254.0.0/16) and private network ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) is strictly blocked.

Tool-call sandboxes execute with an empty platform credential environment. Secrets and API keys are not mounted into the sandbox container.

Container security and isolation

Every Code Sandbox container runs under a hardened security profile:

• Non-Root Execution: Code executes under an unprivileged, non-root user account (UID 65532, the conventional nonroot user; the image has no root user to switch to).
• Capability Drops: All Linux kernel capabilities (CAP_SYS_ADMIN, CAP_NET_ADMIN, etc.) are dropped.
• Seccomp Filtering: Strict kernel system-call filtering limits available syscalls.
• No Credentials: Platform service tokens and control plane credentials are excluded from the container environment.

Timeouts and resource containment

• Wall-Clock Timeouts: Code snippets default to a 20-second timeout (maximum 60 seconds). Tool calls default to a 30-second timeout (maximum 120 seconds). When a timeout is reached, the platform sends SIGKILL to all processes in the container and returns exit_code: -1.
• Memory Limits: Snippet containers are allocated 512 MiB of RAM. Tool-call containers are allocated 1 GiB of RAM. Exceeding memory limits triggers container termination without impacting other platform workloads.

Resource limits and quotas

Limit	Snippet Sandbox (/v1/execute)	Tool-Call Sandbox (/v1/call)
Supported Language	Python 3.12	Python 3.12 (Agent Image)
Default Timeout	20 seconds	30 seconds
Maximum Timeout	60 seconds	120 seconds
Memory Allocation	512 MiB	1 GiB
CPU Allocation	1 vCPU	2 vCPUs
Request Body Limit	N/A	1 MiB
Response Size Limit	N/A	8 MiB
Network Access	None (DNS blocked)	Public Internet (Private IPs blocked)
Environment Reuse	Never	Never

Security summary

Property	Snippet Sandboxes (run_python)	Tool-Call Sandboxes
Single-Use Container	Yes	Yes
Internet Access	None	Public Internet (Metadata & Private ranges blocked)
Platform Credentials Mounted	None	None
Non-Root Execution	Yes	Yes
Hard Execution Timeout	20s default, 60s max	30s default, 120s max
Warm Pool Acceleration	Yes (~1s start)	No (Cold-start container execution)

Next steps

• Run code in the sandbox — use run_python and explore the execution API.
• Code Sandbox overview — high-level concepts and architecture.
• Data protection — platform security and encryption controls.