PoisonZero's detection engine runs CPU-only by default: a minimal, locked-down trusted computing base. GPU acceleration is an optional speed choice you turn on deliberately. Here is exactly what it changes, and how we keep the GPU path safe.
The detection engine analyzes your agents' memory and configuration on-device. Keeping it CPU-only gives it the smallest, most auditable footprint, with no dependency on a graphics stack. If you want more throughput, you can opt into GPU acceleration — this page explains what that opt-in changes and how the GPU build is hardened.
None of this is optional — it is how every install runs unless you deliberately choose otherwise.
A single static binary with a small, well-understood set of linked libraries. Less code in the trusted path means less that can go wrong or be attacked.
The engine runs as a locked-down subprocess under a deny-by-default profile: no network, tightly scoped filesystem access, no ability to spawn other programs.
On the CPU-only path the memory footprint is small and bounded. The engine starts on demand for a check and then exits, leaving only a few megabytes at rest.
GPU acceleration is genuinely useful for throughput, but it widens the trusted computing base. That trade-off should be a deliberate choice, so it stays off unless you turn it on.
GPU work needs the graphics driver and a compute runtime — a large, closed, complex software layer that now sits inside the trusted path. That is more code to trust than the CPU-only build.
To reach the GPU, the sandbox must open a specific, narrow path to the graphics device. We keep that opening as small as the hardware allows, but it is not zero.
VRAM and the driver's allocations are less tightly controllable than the CPU-only build's minimal, bounded footprint.
Our fail-closed network guarantees are re-validated under the full GPU stack before we ship GPU support on each platform — never assumed to carry over.
The GPU path is engineered so its extra surface never touches the default install.
GPU support ships as its own binary. The relaxation exists only there — the CPU-only binary is unchanged and stays the recommended default.
The GPU build links only what the compute path needs. We keep the added dependency set as small as the platform permits.
Even on the GPU path, the engine is denied network access at the operating-system level. Opting into GPU speed does not open an egress path.
The engine will be signed and its hash pinned, and GPU mode will be entitlement-gated. It will not be possible to switch it on silently — only through an explicit, verified opt-in.
We ship GPU support platform by platform, only once its network isolation is re-validated under the GPU stack.
| Platform | Status |
|---|---|
| macOS (Apple Silicon, Metal) | First hardened GPU target — shipping soon. |
| Linux (Vulkan)Coming soon | Hardening in progress. |
| Windows (Vulkan)Coming soon | Held until network isolation is re-validated under the GPU stack. |
CPU-only stays the recommended default for the highest security. GPU acceleration is a transparent, opt-in speed choice — a separate, hardened build that never weakens the default install.
Install the daemon and it runs CPU-only out of the box. Opt into GPU acceleration later, deliberately, when it ships for your platform.
Get the daemon