No host filesystem access. The sandbox should have access only to a purpose-built ephemeral working directory, not to the host's filesystem, mounted volumes, or home directories. Verified through explicit filesystem namespace restrictions, not just file permission settings.
No host process visibility. Processes running in the sandbox should not be able to see or interact with host processes. Container namespaces (PID, network, IPC, user) must be properly configured and verified.
No subprocess escalation. Calls to os.system(), subprocess.run(), and equivalent functions should be blocked or restricted to a pre-approved list of commands. This is enforced via seccomp profiles, syscall filtering, or a restricted interpreter that does not expose these functions.
No environment variable inheritance. The sandbox's environment should be a clean, minimal set — not inherited from the host process. All platform secrets (API tokens, connection strings) should be excluded from the sandbox environment entirely.
gVisor / Firecracker MicroVMs: Kernel-level isolation via a user-space kernel (gVisor) or hardware virtualization (Firecracker). The strongest available option. Used by Google and AWS respectively for production code sandbox workloads.
Seccomp-restricted containers: Docker or OCI containers with a strict seccomp profile that blocks all non-essential syscalls. Substantially stronger than default container configuration.
Restricted Python interpreter: Running code in a Python environment that blocks imports of os, subprocess, socket, and similar modules. Weaker than OS-level isolation but meaningful as a defense-in-depth layer.
Ask your team: when your AI agent runs code, is that code running directly on your company's servers — or in a separate, locked-down environment where it can't touch anything else? Ask what would happen if the code it ran turned out to be malicious.