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.
When the poison0 agent analyses a change on-device, the engine does exactly two things: read the model and answer on localhost, and the operating-system kernel enforces that boundary. Because it reads attacker-controlled input, it is the most tightly caged component we ship: an exploit turns into a harmless process crash, not a foothold.
On every platform the rule is strict: if the sandbox isn't available, the engine does not start. There is no silent degradation to an unsandboxed run; the suspicious change is kept in place and surfaced as a structured audit event, never silently reverted. Once a poisoning is proven, the privileged daemon quarantines the affected memory file in place, and that quarantine stays. More on that: Why fail-closed wins.
How the cage works per operating system
macOS: the engine runs in the kernel sandbox (Seatbelt) under a deny-by-default profile that ships as an auditable file next to the model, and it drops to the unprivileged user nobody. How the macOS cage works →
Linux: Landlock (a kernel LSM, deny-by-default) lets the engine only read the model, execute its own binary and bind one local port; the kernel refuses any outbound connection before a byte leaves the system. How the Linux cage works →
Windows: the engine runs in a network-isolated AppContainer with no network capability - not even localhost - layered over a restricted token, low integrity and a Job Object (exactly one process, no child, capped memory), so it has no path to the network at all. That is the CPU path. A GPU start under Melira Ultra leaves the container and drops the integrity lowering; token, job object and network block remain. How the Windows cage works →
With Ultra the engine can use the GPU for speed. On macOS and Linux the GPU path runs under the same kernel-enforced isolation as the CPU path. On Windows it does not: the GPU start leaves the AppContainer and runs without the integrity drop, because the Vulkan loader cannot create a DXGI factory inside the container and the engine cannot read its key file and model under a lowered token. What still applies on every path: a restricted token with all privileges stripped, a job object limited to a single process with a memory cap, deny-by-default filesystem access, and the App-ID network block for IPv4 and IPv6 - all fail-closed, so the engine does not start if any of it cannot be set up. Scoring stays on-device in both modes. The exact trade-off is in the technical whitepaper.