macOS: the engine inside the Seatbelt sandbox

Seatbelt: the macOS kernel sandbox

On macOS the engine runs inside the kernel sandbox (Seatbelt / sandbox-exec) with a deny-by-default profile: everything is forbidden unless explicitly allowed. This is not a library inside our process that could be bypassed; it's a boundary the macOS kernel itself draws: filesystem, process spawning and network are shut until the profile opens a few narrowly scoped exceptions.

The profile ships with the daemon and sits as an auditable file next to the model - you can read exactly what the engine is permitted to do, rather than take our word for it. At its core only two things are allowed: read the model file and answer on localhost. No writing, no spawning of foreign programs, no outbound network traffic.

Dropping to nobody

If the service runs as root, the engine hands those rights straight back: it drops to the unprivileged user nobody before it reads the first line of attacker-controlled input. The sandbox profile and the privilege drop work together - even if an attacker talks the engine into doing something, the process has neither the rights nor the kernel-permitted paths to do it.

No noticeable latency

The kernel cage sits directly on the execution path and adds no noticeable latency: the sandbox does not measurably change how fast the engine answers.

When the sandbox is missing

On macOS the kernel sandbox is always there, so the exception is rare. Even so, the hard rule of every platform holds: no sandbox, no engine start. There is no degradation to an unsandboxed run; a suspicious change is then kept in place and surfaced rather than waved through unevaluated.

How the same cage looks on Linux and Windows, and why the whole protection is fail-closed, is in the engine sandbox overview.