# 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](/docs/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](/glossary/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](/glossary/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](/docs/security#root-inside-the-sandbox)).

Related: [Firecracker](/glossary/firecracker),
[Linux namespaces](/glossary/linux-namespaces),
[gVisor vs Docker](/compare/gvisor-vs-docker),
[nsjail vs Firecracker](/compare/nsjail-vs-firecracker).

## Sources

Checked 25 September 2026.

- [seccomp(2), man7.org](https://man7.org/linux/man-pages/man2/seccomp.2.html)
- [Docker seccomp security profiles](https://docs.docker.com/engine/security/seccomp/)
- [Firecracker design](https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md)
- [Firecracker production host setup](https://github.com/firecracker-microvm/firecracker/blob/main/docs/prod-host-setup.md)
- [gVisor platforms](https://gvisor.dev/docs/architecture_guide/platforms/)

Facts on this page were checked on 25 September 2026.