Windows: the engine inside a network-isolated AppContainer
On Windows PoisonZero runs the analysis engine inside a network-isolated AppContainer - the operating system denies it the network outright - layered over a restricted token, low integrity and a Job Object.
AppContainer: no network, enforced by the OS
On Windows the engine runs inside a network-isolated AppContainer - an operating-system cell created with no network capability at all. The engine cannot open a network connection, and nothing can reach it over the network - not even localhost. This is not a check in our code; it's a boundary the Windows kernel draws, the same idea as Seatbelt on macOS and Landlock on Linux: the on-device analysis has no way out to the network.
One exception: GPU acceleration
Melira Enterprise Ultra computes on the graphics card, and inside a Windows AppContainer that is not possible: Windows grants access to the graphics driver only to programs with an app identity, which a self-created container does not have. The driver fails to initialise inside it - no matter what permissions the container is given. Chromium solves it the same way: its GPU process does not run in an AppContainer either.
On Windows the engine therefore runs without an AppContainer only when GPU acceleration is active - and additionally without the integrity level being lowered. The reason is measured: at low integrity Windows denies the engine read access to its own model and key file in the data directory; neither an integrity label on the file nor an extra permission entry lifts that.
| Layer | CPU start | GPU start |
|---|---|---|
| Network-isolated AppContainer | yes | no |
| Restricted token, privileges stripped | yes | yes |
| Low integrity | yes | no |
| Job Object: one process, no child, capped memory | yes | yes |
| Network block on the program, fail-closed before start | yes | yes |
A GPU start therefore keeps the stripped privileges, the Job Object and the network block. That block depends on neither the container nor the token: it is an operating-system filter bound to the program itself, armed before the process starts; if it cannot be armed, the engine does not start. What is dropped is only the integrity level, which limits which objects the process could write: to that extent the GPU process runs at the same level as the service that starts it.
Layered with restricted token, low integrity and a Job Object
Inside that container the engine also runs under a restricted token with practically every privilege stripped (only the harmless 'notify on change' privilege remains) and at low integrity, so it cannot write objects at normal integrity. These layers shut, up front, the routes a broken process would otherwise use to spread.
The cage rests on four pillars:
- network-isolated AppContainer - no network capability, no egress, not even localhost;
- restricted token - the process's privileges are removed;
- low integrity - no writes to objects at normal integrity;
- Job Object - exactly one process, no child process, capped memory.
Job Object: exactly one process, no child
The Job Object lets the engine run exactly one process: it cannot spawn a child, the kernel blocks it, and its memory is capped. An exploit that would otherwise fetch or start a helper program runs into a wall: there is no network to reach and no second process to escape into.
Strictly fail-closed
As everywhere, the rule holds: if the cage isn't in place, the engine does not start. If the AppContainer can't be built there is no fallback to a less isolated run; the suspicious change is kept in place and surfaced rather than waved through unevaluated (fail-closed).
How the same cage looks on macOS and Linux is in the engine sandbox overview.
Analysis that can't be turned against you.
PoisonZero runs the on-device engine on Windows inside a network-isolated AppContainer - no network, one process, nothing else.
Sign me up