How We Built Secure, Scalable Agent Sandbox Infrastructure
Key point
Browser Use put agents in sandboxes and relayed them through a control plane for security and scalability.
Details
Browser Use runs millions of web agents, and initially ran browser-only agents on AWS Lambda. It later added Python execution and shell commands, but as the agent loop and REST API shared the same backend, redeployments would disconnect running agents and memory-intensive tasks would destabilize the API.
The solution was not Pattern 1, which isolates only dangerous tools, but Pattern 2, which puts the entire agent into a secrets-free sandbox. The sandbox doesn't communicate directly with the outside; the control plane handles all requests on its behalf.
In production, the same image runs as an Unikraft micro-VM, while in development and eval it runs as a Docker container. A single sandbox_mode: 'docker' | 'ukc' switches the path, and in production it's provisioned on AWS's dedicated bare metal machines via the Unikraft Cloud REST API. Unikraft provides scale-to-zero by default, so VMs suspend when idle and resume instantly on the next request, and sandboxes are distributed across multiple Unikraft metros. The sandbox only contains SESSION_TOKEN, CONTROL_PLANE_URL, and SESSION_ID, and the VM has no permissions in the private VPC beyond reaching the control plane.
Security hardening was also added in stages.
- Python source is compiled into
.pycat build time, then the.pyfiles are deleted. - The entrypoint starts as root but immediately drops privileges to the
sandboxuser viasetuid/setgid. - Environment variables are read and then removed from
os.environto reduce exposure.
The control plane is a FastAPI-based stateless proxy that relays all LLM calls, S3 file storage, and billing. Each request is validated for its session via Bearer session_token, then executed with the actual credentials, and the full conversation history is kept in the DB. Changes to the sandbox's /workspace are synced to S3 via a session-scoped presigned URL, so AWS credentials never remain in the sandbox. Internally, a ControlPlaneGateway and a DirectGateway are used so that production and development paths share the same interface.
In the end, the control plane on ECS Fargate autoscales based on CPU in private subnets behind an ALB, and the Unikraft sandboxes and backend also scale independently according to their own bottlenecks. The trade-off is an extra network hop for every task and more services overall, but they judged the added latency to be nearly negligible compared to LLM response times. The core principle is simple: leave the agent with nothing worth stealing and nothing worth preserving.
This summary was generated automatically by AI. Check the original for the author's claims and context. Copyright belongs to the original author.
Our guide explains how the AI works. Report summary errors, attribution issues, or removal requests via Contact.