Technical whitepaper

PoisonZero - Technical Whitepaper

The architecture document for the people who evaluate PoisonZero: security engineers and CISOs who want the design, not the pitch. It specifies the threat model, the event-driven processing pipeline, the decision engine with its real default thresholds, both evaluation flows (cloud-assisted and fully on-device), the on-device detection model, and the integrity and data-handling guarantees that back them. Residual risks are stated honestly. The risk it addresses is catalogued as OWASP ASI06 (Memory & Context Poisoning) in the OWASP Top 10 for Agentic Applications.

Download the whitepaper (PDF)

Version 2.6 · August 2026 · 22 pages · English

Abstract

AI agents retain persistent memory (standing instructions, project notes, learned preferences) in plain files read back into the model context on every invocation. An attacker who writes a single malicious entry influences all subsequent agent behaviour without being present when the damage occurs. PoisonZero treats every change to a protected file as untrusted until proven safe and is fail-closed by construction: when evaluation is impossible or ambiguous, the change is recorded and surfaced as a structured audit event rather than waved through unevaluated. This document specifies the five-class threat model, the processing pipeline (a watcher with a trailing-edge final-state guarantee, a deterministic Unicode-normalised rule layer, layered defence-in-depth filters that can only tighten the model's verdict, the decision engine, and the enforcer), the cloud-assisted flow with its verifiable egress contract, the fully on-device flow with its minimal-privilege sandbox, the decoder-only detection model with fully customised weights, the at-rest integrity of the on-device model, which is held authenticated-encrypted and tamper-evident so any alteration fails closed, and the license and integrity architecture. The per-platform sandbox detail (Seatbelt, Landlock, network-isolated AppContainer, restricted token and Job Object) is in the engine sandbox overview.

Why fail-closed wins →

Melira Enterprise Ultra - GPU-accelerated detection

Within the Enterprise tier, a GPU-accelerated variant is offered: Melira Enterprise Ultra runs GPU-accelerated on hosts with a capable GPU, for lower latency and higher throughput. It is part of the Enterprise tier, not a product tier of its own. The inference contract stays the same. CPU-only inference remains the recommended secure default and the baseline described above. GPU acceleration is an opt-in choice that enlarges the trusted computing base; it ships as a separate, hardened build in which network access stays denied at the operating-system level. Hardened GPU support ships on all three platforms: macOS (Apple Silicon, Metal), Linux (Vulkan) and Windows (Vulkan). On macOS and Linux it runs under the same kernel-enforced isolation as the CPU path; on Windows the GPU start leaves the AppContainer and drops the integrity lowering, while restricted token, job object and the network block remain.

How the GPU security model works →

Questions for your security team?

Send us the specifics of your environment (private setup constraints, fleet size, DLP requirements) and we'll walk your engineers through the details.

Contact sales

← Back to Enterprise