Sandboxing
Sandboxing is the practice of running code inside a restricted environment so that whatever it does — by design, by bug or because it was manipulated — can only affect a small, disposable part of the surrounding system. A sandbox limits what files the code can see, which system calls it can make, how much processor, memory and time it can use and which network destinations it can reach. For AI agents that execute shell commands, run generated programs and read untrusted web pages, sandboxing is the primary containment layer: it assumes the agent will sometimes do the wrong thing and aims to make the wrong thing survivable.
The strength of a sandbox depends on where the isolation boundary sits. An operating-system process is isolated from others by the kernel, but shares that kernel with everything else. Containers, built from Linux namespaces that restrict what a process can see and control groups that cap its resources, add a lightweight boundary, yet all containers on a host still share one kernel, so a kernel vulnerability can let code escape. Virtual machines place a hypervisor and a separate guest kernel between the code and the host, a much narrower interface and a stronger boundary at the cost of more startup time and memory. Hybrid approaches sit in between: Firecracker, open-sourced by Amazon in 2018 for services such as Lambda, boots minimal VMs in a fraction of a second, and gVisor, open-sourced by Google in 2018, intercepts an application's system calls in a user-space kernel so the host kernel is exposed to far fewer of them.
System-call filtering is a finer-grained tool that works at the boundary between a program and the kernel. Linux seccomp, introduced in 2005, originally let a process drop into a mode where it could use only a handful of calls; seccomp-bpf, added around 2012, lets a policy written as a small filter allow, deny or log each system call and its arguments. Browsers, container runtimes and many services use it to shrink the attack surface, and it complements other mechanisms such as dropping Linux capabilities, mandatory access control through AppArmor or SELinux, read-only filesystems and running as an unprivileged user. WebAssembly runtimes offer another model, where code can only touch what the host explicitly hands it.
For agents, the most important and most neglected control is network egress. A sandbox that can read a secret and then reach any server can leak it, so exfiltration depends on outbound connectivity as much as on file access. Typical policies deny outbound traffic by default and allow named hosts, such as a package mirror or the model provider's API, route traffic through a proxy that logs and filters it, and block access to cloud metadata endpoints and internal addresses that an attacker could use for credential theft. This matters especially for prompt injection: even if a malicious page persuades the agent to attempt something harmful, a closed network and absent secrets leave it nothing to send and nowhere to send it.
Agent sandboxes add requirements beyond traditional code isolation. They must be fast to create and cheap to discard, since each task or even each tool call may get a fresh environment, and they must be reproducible so that a run can be replayed. They need persistent state only where wanted, through mounted workspaces or snapshots, and should not mount home directories, SSH keys, cloud credentials or browser profiles. Hosted code-interpreter features, cloud agents and developer tools commonly combine container or microVM isolation with resource limits and an egress policy, while local agents often rely on operating-system sandboxes or on the user's approval for risky commands. Browser agents and computer-use agents are commonly given a disposable virtual desktop for the same reason.
A frequent misconception is that a container is a security boundary equal to a virtual machine, and that sandboxing makes an agent safe. Containers are designed primarily for packaging and resource control, and hardening them with seccomp, dropped capabilities and a user-space kernel such as gVisor narrows the gap rather than removing it. More fundamentally, a sandbox constrains what the agent can touch, not what it may legitimately do within the reach it is given: an agent allowed to push to a repository or send email from inside the sandbox can still make harmful choices there. Sandboxing therefore works together with least privilege, scoped credentials, approvals for consequential actions and monitoring, rather than replacing them.
Read sandboxing as drawing a boundary around code you do not fully trust and then shrinking what is on the inside: the choice of container, user-space kernel or virtual machine sets how strong the wall is, seccomp and network egress limits decide what can pass through it, and the whole arrangement only contains what the sandbox can reach, leaving the question of what the agent is permitted to do to its permission model.