What is seccomp?

seccomp is a Linux kernel feature that limits which system calls a process may make, using a fixed list or BPF filters.

Runtime's boundary does not rest on a system-call filter alone: each sandbox is a Firecracker microVM with its own Linux kernel, and Firecracker applies seccomp filters to itself by default. Code in the sandbox gets a full guest kernel and sudo, and a new sandbox ran its first Python command 351 ms after the request at the median on 24 September 2026 (speed).

How does seccomp work?

A process installs a filter with the seccomp() system call, a superset of the older prctl(PR_SET_SECCOMP) operation. The man page describes two modes:

Strict mode allows only read, write, _exit (but not exit_group) and sigreturn. Any other call kills the thread.
Filter mode runs a Berkeley Packet Filter program on every system call. The program sees the call number, the architecture, the instruction pointer and up to six arguments, and returns a verdict.

An unprivileged process must first set no_new_privs with prctl(PR_SET_NO_NEW_PRIVS, 1), so it cannot apply a malicious filter and then run a set-user-ID program under it. Children made by fork or clone get the same filters, and filters are kept across execve; more can be added later.

Filter verdicts

Return action	What happens
`SECCOMP_RET_KILL_PROCESS`	The whole process is killed (Linux 4.14 and later)
`SECCOMP_RET_KILL_THREAD`	Only the calling thread is killed
`SECCOMP_RET_TRAP`	The thread receives `SIGSYS`
`SECCOMP_RET_ERRNO`	The call is skipped and returns an error number
`SECCOMP_RET_USER_NOTIF`	A user-space supervisor decides (Linux 5.0 and later)
`SECCOMP_RET_TRACE`	A ptrace tracer is notified
`SECCOMP_RET_LOG`	The call runs and is logged (Linux 4.14 and later)
`SECCOMP_RET_ALLOW`	The call runs

The seccomp() system call itself arrived in Linux 3.17.

Who uses seccomp?

Docker. Its default profile "disables around 44 system calls out of 300+", including mount, kexec_load, bpf, ptrace and clone with new namespaces. Docker calls it "moderately protective while providing wide application compatibility". --security-opt seccomp=unconfined turns it off.
Firecracker. Its design says seccomp filters "are used by default to limit the host system calls Firecracker can use", installed per thread before guest code runs. Its production guide calls the default, most restrictive filters "the recommended option for production usage".
gVisor. Its default platform since mid-2023, systrap, "relies on seccomp's SECCOMP_RET_TRAP feature" to intercept an application's system calls (gVisor).

Why seccomp matters for AI agent sandboxes

For a container, seccomp shrinks the host kernel surface the container can reach, which is the surface a container escape attacks. It cannot remove it: the allowed calls still run in the shared kernel. For a microVM, seccomp plays a different part. It fences the monitor process on the host, so even a compromised VMM has few system calls to work with.

How Runtime relates to it

Each Runtime sandbox runs its own kernel, so code inside can make any system call its guest kernel supports, and root inside controls the guest and nothing else. CPU, memory, disk, network rules and billing are enforced on the host (security).

Sources

Checked 25 September 2026.

Facts on this page were checked on 25 September 2026.