Answering the user confirmation prompt
When a change is neither clearly safe nor a proven attack, PoisonZero holds it and asks. This page covers answering: what the user confirmation prompt shows, what Keep and Reject do, and why no answer is a reject.
What the user confirmation prompt shows
The prompt shows only the added line, quoted from the file so it never reads as PoisonZero speaking:
| Shown | Meaning |
|---|---|
| File | Full path of the changed file |
| Changed | When the line was added, taken from the data |
| The new line | The added line only, quoted verbatim; rest of the file not shown |
| Recommendation | One plain sentence; nothing nudges you toward Keep |
Only the added line is shown, not the whole file and not a score. When PoisonZero decides to ask is covered in user confirmation prompts.
Keep or reject
Two buttons, each naming what happens to the held line:
| Answer | Outcome |
|---|---|
| Keep | Content left in place and recorded as approved by you. That exact content becomes the new reference point, so the same finding is not raised again; the approval is visible in the console. |
| Reject | Line removed, file put back to its safe state. Quarantined, not deleted, so it can be recovered. |
| No answer | Treated as Reject: rolled back to the safe state. |
No answer is a reject. Timeout, Escape, closing the prompt, a prompt that appeared mid-typing, or no desktop to show it on: every path that is not an explicit Keep rolls the change back.
The hold window
- Held, not applied: file keeps its last clean content until you Keep.
- Deadline to answer: a hotter change gets a shorter one.
- Absolute cap: an undelivered prompt rolls back once an outer time limit passes.
- Keep sets a reference point: the file is left as written and that exact content is recorded as approved by you, so it is not raised again. Visible in the console as a human approval.
A reject is a reversible quarantine, so a mistaken reject costs only rewriting the line. The safe-by-default stance is fail-closed.
How the user confirmation prompt is protected
Trustworthy because of where the question travels and who may reply, neither resting on a secret poisoned content could read:
- Local channel, never the network: a peer-credential channel on the machine, a Unix-domain socket on Linux and macOS or a named pipe on Windows.
- Kernel vouches for who answers: only the signed-in desktop session may reply, re-checked live on every answer.
- No forgeable token: authenticity comes from the kernel-vouched account boundary, not a nonce or token on the wire.
| Platform | How the responder's account is vouched |
|---|---|
| Linux | The kernel reports the connecting account (SO_PEERCRED), taken at connect time |
| macOS | The kernel reports the connecting account (LOCAL_PEERCRED), matched to the active console user |
| Windows | The pipe server reads the client's account token (ImpersonateNamedPipeClient, identification level) |
A poisoned agent or file cannot fake a Keep. Connecting proves nothing; only an answer from the active signed-in account is accepted.
Read next
More: user confirmation prompts and headless devices, fail-closed, and what Cloud mode sends in Cloud mode.
Was this helpful?
One line, one question, and no answer means reject.
You see only the change, Keep records it as yours, and every reject is a reversible quarantine. Free for Linux, macOS and Windows.
Sign me up