Skip to main content
This guide covers production patterns for deploying BoxLite as a sandboxed execution environment for AI agents. It assumes you’ve already worked through the Tutorials and know how to create boxes, run code, and transfer files.
Using BoxRun? If your agent communicates via HTTP, BoxRun’s REST API or Python SDK may be a simpler integration path. BoxRun handles sandbox lifecycle, file upload/download, and SSE streaming out of the box. See the AI agent patterns section in the BoxRun SDK docs.

Workload-Type Reference

Starter Configuration

Security Presets

SecurityOptions has three presets: For AI agents running untrusted code, use SecurityOptions.maximum():

Concurrency Model

A single box can run many exec() calls. Each call spawns a new process inside the same VM. This avoids repeated VM boot overhead and is safe because the VM provides hardware isolation from the host.
When to use: Most AI agent scenarios. Keeps VM boot cost to one-time.

One Box Per Agent

Use separate boxes when you need strict isolation between agents, different images, or independent resource limits.
When to use: Multi-tenant isolation, different language runtimes, or strict resource separation.

Timeout Handling and Zombie Prevention

The Problem

asyncio.wait_for() cancels the Python coroutine but does not kill the guest process. Without explicit cleanup, the process continues running inside the VM indefinitely.
The following pattern leaves a zombie process running inside the box:

Correct Pattern

Always kill the execution in the timeout handler:

Defensive Helper

For maximum safety, combine timeout handling with a try/finally block:

Security Boundaries

SecurityOptions Fields

Network Isolation

To prevent an agent from accessing the network:
In the Python bindings, network_enabled is currently a macOS-only control. On Linux and other platforms, network isolation is typically enforced by the container/runtime networking configuration (for example, running in an isolated network namespace and not publishing ports), and network_enabled may not itself hard-disable all outbound connectivity.

Resource Limits as Security Boundaries

Resource limits prevent a rogue agent from consuming all host resources:

Memory Limits and OOM

The memory_mib setting is a hard limit enforced by the hypervisor. When a guest process exceeds this limit, the Linux OOM killer terminates the offending process inside the VM — but the box itself stays running. This means you can detect OOM and retry or report the failure. How to detect OOM:
  • The process exit code will be 137 (128 + SIGKILL)
  • stderr may contain Killed or Out of memory
OOM kills the guest process, not the box. The box remains running and can accept new exec() calls. If your agent needs to detect and handle OOM, check for exit code 137 after each execution.

Terminal Resizing

When running interactive TTY sessions (e.g., an AI agent controlling a shell), use resize_tty() to set the terminal dimensions. This ensures proper line wrapping and avoids garbled output from programs that query terminal size.
resize_tty() / resizeTty() only works on executions started with tty=True / { tty: true }. Calling it on a non-TTY execution returns an error.

Complete Example

Putting it all together: security configuration, concurrent execution with timeouts, and cleanup.

See also