Sandboxed Execution

Every code execution spawns a fresh, single-use container or microVM that is destroyed immediately after the task completes. No state persists between invocations.

• Zero state retention: Filesystem, memory, and network state are wiped on termination
• Prevents cross-contamination: A compromised execution cannot poison subsequent runs
• Implementation: Docker --rm flag, Firecracker microVMs, or gVisor sandboxes
• Cold start optimization: Pre-warmed snapshots reduce spin-up latency to < 100ms

The sandboxed process operates on a temporary, layered filesystem with no mount access to the host's root filesystem. Writes are confined to an ephemeral overlay.

• Read-only rootfs: The base image is immutable; any modification attempt triggers a copy-on-write to the ephemeral layer
• No host mounts: /proc, /sys, and host directories are either masked or mapped to sandbox-specific namespaces
• Disk quotas: Strict I/O limits prevent resource exhaustion attacks via disk bombing
• Example: A code interpreter agent can pip install packages into a temporary virtual environment that vanishes post-execution

Outbound network access is denied by default and granted only through explicit allowlists. This prevents data exfiltration and command-and-control callbacks.

• Default-deny firewall: All outbound connections are blocked unless explicitly permitted
• Domain allowlisting: Only pre-approved FQDNs are resolvable; wildcard domains are prohibited
• No internal network access: The sandbox cannot reach other containers, services, or the host's loopback interface
• DNS filtering: Custom DNS resolvers enforce policy at the name resolution layer, blocking tunneling via DNS

Strict cgroup-based limits constrain CPU, memory, and process counts to prevent denial-of-service attacks from runaway or malicious code.

• Memory limits: Hard ceiling (e.g., 512MB) triggers OOM kill if exceeded; no swap access
• CPU throttling: CFS quotas cap compute time; a fork bomb is contained within the sandbox's PID namespace
• Process limits: pids.max cgroup controller prevents process table exhaustion
• Timeout enforcement: A wall-clock deadline (e.g., 30 seconds) terminates execution regardless of resource consumption

A seccomp-bpf profile restricts the kernel syscalls available to the sandboxed process, blocking dangerous operations like ptrace, mount, or reboot.

• Allowlist approach: Only a minimal set of syscalls (e.g., read, write, exit) are permitted
• Architecture-specific filtering: Prevents 32-bit syscall exploits on 64-bit kernels
• gVisor integration: User-space kernel intercepts syscalls before they reach the host, providing defense-in-depth
• Audit logging: Violated syscall attempts are logged via SECCOMP_RET_LOG for forensic analysis without killing the process

Linux capabilities are stripped to the absolute minimum, ensuring even a root user inside the sandbox cannot perform privileged operations.

• No CAP_SYS_ADMIN: Prevents mounting filesystems, loading kernel modules, or accessing namespaces
• No CAP_NET_RAW: Blocks raw socket creation, preventing packet injection or ARP spoofing
• User namespace remapping: The sandbox's root UID maps to an unprivileged UID on the host
• Immutable root: Even with CAP_SYS_CHROOT, the pivot_root syscall is blocked by seccomp

An execution context that is created on-demand for a single task and destroyed immediately upon completion, leaving no residual state. Key properties include:

• Statelessness: No data persists between invocations
• Immutability: The environment image cannot be altered during execution
• Network isolation: Egress traffic is tightly controlled or blocked This pattern prevents cross-contamination between agent tasks and eliminates the risk of an attacker establishing persistence in a long-running container.

A Linux security practice that removes specific capabilities—granular privileges traditionally bundled into the root user—from a process. Even if an agent escapes its application-level sandbox, dropping capabilities like CAP_SYS_ADMIN, CAP_NET_RAW, and CAP_SYS_PTRACE severely limits what an attacker can do. Best practice is to start with all capabilities dropped and add back only those explicitly required.