Run code you don't trust, without betting the host.
Executing someone else's code, a user's script, an AI tool call, a plugin, is a security problem wearing a feature's clothes. We run it in a locked box: its own namespaces, a syscall filter, hard CPU and memory caps, no network, and an ephemeral filesystem, so the worst it can do is get killed for going over a limit.
Drive it: run the safe workload, then a CPU bomb, a memory bomb, an exfiltration attempt, a breakout. Watch each one hit a wall instead of the host.
Layers the code can't talk its way past.
What you just ran passed through these. Namespaces hide the host, seccomp filters the syscalls, cgroups cap the resources, and the run happens with no network on a disk that's thrown away. Each layer is enforced by the kernel, so there's nothing in the code's reach to disable.
Its own view of processes, mounts, users, and the network. It can't see the host or its neighbors.
A syscall allowlist. The code can make the calls it needs and nothing else, enforced by the kernel.
Hard CPU, memory, and pid limits. A runaway or a fork bomb hits the cap instead of the host.
It executes with no network and an ephemeral disk, every resource counted against its budget.
It returns under the limits, or it's killed for crossing one. Either way the host is untouched.
The box, declared up front.
Everything the code is allowed is in this file, and the default of everything else is no. No network unless you grant it, a filesystem that doesn't survive the run, and hard numbers on CPU, memory, and processes. The policy is data, so it's reviewable and the same on every host.
1// sandbox.json — the box the code runs in2{3 "network": "none", // no egress, ever4 "filesystem": "ephemeral", // wiped after the run5 "limits": { "cpu_ms": 2000, "memory_mb": 128, "pids": 64 },6 "seccomp": "allowlist", // only the syscalls it needs7 "namespaces": ["pid", "net", "mount", "user", "ipc"]8}Each of these is a real attempt in the runner above. None of them reaches anything it shouldn't.
What makes it safe to just run it.
The value of a sandbox is that you stop having to trust the code at all. These are the properties that let you take that stance and mean it.
Each execution gets a fresh, isolated sandbox, so one workload can't see or poison the next.
A workload that crosses a CPU, memory, or time limit is terminated by the kernel, not politely asked to stop.
Egress is off unless you allowlist a destination, so untrusted code can't phone home or exfiltrate.
The disk is a scratch space thrown away after the run, so nothing persists and nothing leaks between runs.
Sandboxes start in milliseconds, so isolating a tool call or a plugin doesn't cost you the latency budget.
Every run's CPU, memory, and time are measured, so you can meter, rate-limit, or bill by real usage.
The demo where nothing bad happens is the whole product.
It's tempting to run a user's script or an AI's tool call directly, because it works fine in testing, where nobody's trying. The trouble is the day someone is: the infinite loop that pins a core, the allocation that eats the box, the fetch that ships your secrets somewhere. A real sandbox makes those attempts boring, a killed process and a log line, because it assumed from the start that the code was hostile. That assumption is the feature, and it's the one we build in.
Untrusted code, run like you expect the worst.
Namespaces, a seccomp syscall filter, hard cgroup limits, no network, and an ephemeral disk, so the worst a workload can do is get killed for crossing a line.