{"slug": "sandbox-boundaries", "title": "Sandbox Boundaries", "summary": "Cantelop runs each active AI agent Session in a separate Firecracker microVM, isolating compute, host, network, resources, and lifecycle to limit the blast radius of untrusted code, according to a blog post by Stepan Arsentjev. The company bounds guest memory and vCPU count per microVM and tracks host CPU and memory usage through per-Sandbox cgroups, though hard host CPU quotas and memory caps are not currently enforced per Sandbox. Cantelop maintains a warm pool of fresh microVMs and jails for fast activation, and files saved in /workspace survive Sandbox termination while all other state is discarded.", "body_md": "# Running AI agents as untrusted code\n\n[Stepan Arsentjev](https://github.com/stepandel)\n\nSandboxing is a well established process for running AI agents. Any provider that offers infrastructure for running untrusted code follows similar principles.\n\nSo this blog doesn't propose anything new. It's a summary of established disciplines and Cantelop's implementation of them.\n\nTo sum up, a great sandbox preserves the capabilities an agent needs while minimizing the blast radius of those capabilities.\n\nThis could be achieved by establishing the following boundaries:\n\n1. **[Compute](#1-compute-boundary):** execution, memory, and filesystem isolation\n2. **[Host](#2-host-containment):** prevent process accessing the host\n3. **[Network](#3-network-policy):** firewall ingress and egress policy\n4. **[Resources](#4-resource-isolation):** bound resource consumption\n5. **[Lifecycle](#5-lifecycle-boundary):** enforce ephemeral state destruction\n\n### 1. Compute boundary[#](#1-compute-boundary)\n\nThis is the boundary that could limit the agent the most. At the very least, the agent needs access to processes, memory, and a filesystem.\n\nA full VM would provide a flexible environment with its own guest kernel, enabling arbitrary code, browsers, and other demanding software to run.\n\n**Firecracker** is well suited for providing this environment. It's a lightweight virtualization\ntechnology behind [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html)\nand [Fly Machines](https://fly.io/docs/machines/guides-examples/functions-with-machines/).\n\nIn Cantelop, each active Session runs in a separate Firecracker microVM limited by a set of permissions that prevent it from accessing other workloads.\n\n### 2. Host containment[#](#2-host-containment)\n\nA compromised guest could still access the host if it exploits the host-side Firecracker process.\n\nSo we need to further isolate the host process. This involves running the Firecracker process with a non-root UID/GID and a per-VM chroot. This isolation is called a \"jail\" in Firecracker.\n\nThis essentially gives the guest process its own restricted filesystem root on the host.\n\n```\nActual path:  [jailer-base]/firecracker/[vm-id]/root/firecracker\nVisible path: /firecracker\n```\n\nIn addition to the restricted filesystem root and unprivileged identity, Cantelop places each VMM in its own host-side resource hierarchy and only exposes the files and devices required to run that microVM.\n\n### 3. Network policy[#](#3-network-policy)\n\nA good network boundary lets a workload reach the services it needs while only accepting inbound connections from trusted sources.\n\nCantelop enforces network access via host firewall which restricts outbound access to private and infrastructure addresses.\n\nEdge API is built specifically for user's customization and ingress management. It authenticates callers and authorizes access. Sandboxes do not expose public ingress ports directly.\n\n### 4. Resource isolation[#](#4-resource-isolation)\n\nSandbox resources should be constrained such that one workload cannot materially interfere with others on the same host.\n\nCantelop bounds guest memory and vCPU count per microVM and tracks host CPU and memory usage through per-Sandbox cgroups. Physical host resources remain shared; hard host CPU quotas and memory caps are not currently enforced per Sandbox.\n\n### 5. Lifecycle boundary[#](#5-lifecycle-boundary)\n\nDestroy everything that was not explicitly made durable.\n\nWhen a Sandbox terminates, Cantelop stops its Firecracker process and removes its VM-specific jail. The microVM's processes, memory, temporary files, and writable root filesystem changes are discarded. The next activation uses a completely new instance and does not reuse the previous Sandbox.\n\nTo keep activation fast, Cantelop maintains a warm pool of fresh microVMs and jails. Used Sandboxes never return to this pool.\n\n#### Workspaces\n\nThe explicit exception is `/workspace`: files saved there survive Sandbox termination.\nWorkspaces are durable volumes that can be shared between Sessions of the same App.\n\nTerminating a Sandbox unmounts the workspace without deleting its data.\n\nTo dive deeper into sandbox isolation, you can refer to the [Sandbox isolation reference](/docs/sandbox-isolation).", "url": "https://wpnews.pro/news/sandbox-boundaries", "canonical_source": "https://cantelop.com/blog/running-agents-as-untrusted-code", "published_at": "2026-09-11 14:34:15+00:00", "updated_at": "2026-09-11 14:45:29.791921+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-safety"], "entities": ["Cantelop", "Stepan Arsentjev", "Firecracker", "AWS Lambda", "Fly Machines"], "alternates": {"html": "https://wpnews.pro/news/sandbox-boundaries", "markdown": "https://wpnews.pro/news/sandbox-boundaries.md", "text": "https://wpnews.pro/news/sandbox-boundaries.txt", "jsonld": "https://wpnews.pro/news/sandbox-boundaries.jsonld"}}