Architecture

The engine that can only read and answer

The analysis engine can do exactly two things: read the model and answer on localhost. Nothing else — and it's the operating-system kernel, not our code, that enforces it.

~6 min read · Architecture

Why this component is caged hardest

When PoisonZero analyses a change on-device, the engine is the component that reads attacker-controlled text — the very memory diff someone may have crafted to break out. So we treat it as the most exposed surface in the system and lock it down accordingly: it's the most tightly caged component we ship. The design goal is blunt — an engine exploit should turn into a harmless process crash, not a foothold. And when the engine crashes, the daemon doesn't shrug: it reverts the suspicious change (fail-closed).

Note the deliberate split. The daemon runs privileged on purpose — as a root service (LaunchDaemon / systemd) — because it has to watch protected memory files it doesn't own and revert them in place; that job can't be done without privilege. The engine is the exact opposite: it never touches the things the daemon protects, it only reads the input under suspicion, so it's stripped to almost nothing. That asymmetry is the architecture: the most exposed component is the most confined one, and breaking it can't reach the privileged daemon.

The engine reads attacker-controlled input for a living. We assume it can be broken — and build so that breaking it accomplishes nothing.

macOS: the 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. 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. If the service runs as root, the engine itself drops to an unprivileged user (nobody).

Verified live on Apple Silicon — and the sandbox costs no measurable latency: a warm evaluation runs in about 1.1 seconds either way.

Linux: Landlock, enforced by the kernel

On Linux the cage is Landlock, a kernel security module (LSM), again deny-by-default. The engine may:

read only the model file — nothing else on disk;
execute only its own binary — it cannot launch other programs;
bind to the one local port it answers on — and nothing more.

Outbound connections are refused by the kernel with “permission denied” — before a single byte leaves the system. This isn't a promise in our code; it's proven on a real kernel in CI on every build. No writing to disk, no spawning of foreign processes, no network egress.

“Read only the model file” is only true if the engine genuinely needs nothing else from disk. That's why the Linux engine is built fully statically against musl — no dynamic loader, no shared libc — on both architectures (amd64 and arm64). A normally linked binary would have to read and execute /lib64/ld-linux and the system libc at startup, forcing those paths into the allowlist; the static engine reads exactly one file and executes exactly one binary, itself.

On Linux the kernel denies the engine's outbound connection before one byte leaves the machine. The guarantee lives below our code — where attacker input can't reach it.

Windows: restricted token + Job Object

On Windows the engine runs under a restricted token with a kernel Job Object — and it's live and verified, fail-closed exactly like macOS and Linux. The token is created so that every privilege is stripped (only the harmless “notify on change” privilege remains), and the process runs at low integrity, so it cannot write objects at normal integrity. The Job Object lets the engine run exactly one process — it cannot spawn a child, the kernel blocks it — and caps its memory. It still binds localhost only, with no outbound connection.

This is verified live on GitHub Actions windows-latest: child-process spawning is blocked by the kernel, and the real Windows engine loads and evaluates correctly under the token and Job constraints. (An even stricter AppContainer stage is on the roadmap; the current profile already ships, live and fail-closed.)

Strictly fail-closed: no sandbox, no analysis

On every platform the rule is the same and it's strict: if the sandbox isn't available, the engine does not start. There is no silent degradation to an unsandboxed run. Instead, suspicious changes are reverted rather than waved through unevaluated. On-device analysis without the kernel cage simply doesn't happen.

That's an honest limit — and it's the point. “Fail-closed” means: without Landlock (or Seatbelt), there is no on-device analysis on that host. We'd rather protect you by reverting than expose the most attacker-facing component without its cage. The limit is the feature.

What it needs from your machines

macOS: nothing special — the kernel sandbox is always there.

Linux: a kernel ≥ 5.13 with Landlock active. That covers Ubuntu ≥ 22.04, Debian ≥ 12 and RHEL ≥ 9.6 out of the box; on other distributions you enable it with the boot parameter lsm=landlock,…. Inside containers, the default Docker seccomp profile blocks the Landlock syscalls — so you need an adjusted profile there.

Windows: nothing special — the restricted token and Job Object are standard kernel features.

For environments where Landlock can't be enabled, there's an opt-in alternative: cloud evaluation as a remote backstop. The protection stays in place; the data flow is documented transparently rather than hidden.

The short version

Read the model, answer on localhost — nothing else, enforced by the OS kernel.
An engine exploit becomes a process crash; the daemon reverts fail-closed.
No sandbox → the engine won't start → suspicious changes are reverted, never waved through.

The full design, including the verifiable egress contract, is in the technical whitepaper. Related: Why fail-closed wins and Memory Poisoning.

Analysis that can't be turned against you.

PoisonZero runs the on-device engine in a kernel-enforced cage — read the model, answer on localhost, nothing else.

Sign me up

All articles