Fundamentals

How PoisonZero protects

PoisonZero runs on the same machine as your agent and acts on the change to a file, not the file at rest. Every change to a protected memory file is checked before it takes effect, and the result is one of three outcomes. This page is the behavior, not the model internals.

~5 min read · Fundamentals

Where the protection sits

The unit of protection is the change, not the file:

  • On the change: a file is only read, diffed and scored when it changes; nothing is judged at rest.
  • Before it takes effect: the check runs at the moment of the write, not once at install.
  • Local: the watcher and the evaluation run on the same machine as your agent.
Scope is an allowlist: only an agent's memory, instruction and configuration files are watched, and everything else on the machine is never opened. See what PoisonZero watches.

What triggers a check

The watcher listens for filesystem events on the protected paths and evaluates only content that is created or written:

EventWhat happens
File createdEvaluated as a new change
File written or modifiedThe added content is diffed against the last clean state and evaluated
File removed or renamedNot evaluated: removing content is not a poisoning vector
Directory events and the daemon's own runtime files are filtered out before evaluation; only in-scope memory files reach the model.

The three outcomes

Every evaluated change ends in exactly one of three outcomes:

OutcomeWhenWhat PoisonZero does
AllowThe change is evaluated as harmlessThe change is accepted and becomes the new clean state
AskThe change is neither clearly safe nor a proven attackThe file is held in its last safe state and you are asked before it takes effect. For a file that is being created for the first time there is no earlier state, so declining moves the whole file into quarantine - reversibly
Roll backThe change is evaluated as a proven attackThe change is undone automatically and the file returns to its last clean state
The exact scoring is not exposed here; the behavior is what matters: safe passes, uncertain asks, dangerous rolls back. The uncertain middle band is covered in user confirmation prompts.

Rolling back is reversible

A roll-back never destroys content. The dangerous change is undone by restoring the last known-clean version, and the displaced content is kept, not deleted:

  • Restore, not delete: the file is rewritten to its last clean state; the change is quarantined, held aside rather than erased.
  • Recoverable: the displaced content is preserved verbatim, so a decision can always be undone.
  • Logged: every outcome is written to the local audit trail - what changed, when, and why.
Because a roll-back is a reversible quarantine, an entry PoisonZero could not clear never quietly becomes one of your agent's beliefs, and a false alarm costs you nothing but a click to keep.
Fail-closed: if the evaluator is unavailable or returns nothing usable, the change is held in its safe state, never waved through. Safety is the default. See fail-closed by design.

The exact set of watched files: what PoisonZero watches. The uncertain middle band: user confirmation prompts. The safe-by-default stance: fail-closed.

Was this helpful?

Protection that acts on the change, before your agent does.

Watched locally, scored before it takes effect, and every roll-back reversible. Free for Linux, macOS and Windows.

Sign me up