Wie der poison0-Agent schützt
Der poison0-Agent läuft auf derselben Maschine wie Ihr Agent und wirkt auf die Änderung einer Datei, nicht auf die ruhende Datei. Jede Änderung an einer geschützten Memory-Datei wird geprüft, bevor sie wirksam wird, und das Ergebnis ist eines von drei Ergebnissen. Diese Seite beschreibt das Verhalten, nicht die Modell-Interna.
Wo der Schutz ansetzt
Die Einheit des Schutzes ist die Änderung, nicht die Datei:
- An der Änderung: eine Datei wird nur gelesen, gedifft und bewertet, wenn sie sich ändert; im Ruhezustand wird nichts beurteilt.
- Bevor sie wirksam wird: die Prüfung läuft im Moment des Schreibens, nicht einmalig bei der Installation.
- Lokal: die Überwachung und die Bewertung laufen auf derselben Maschine wie Ihr Agent.
Der Geltungsbereich ist eine Allowlist: nur Memory-, Anweisungs- und Konfigurationsdateien eines Agents werden überwacht, alles andere auf der Maschine wird nie geöffnet. Siehe was der poison0-Agent überwacht. Tool-Aufrufe prüft der poison0-Agent mit exec0, bevor sie laufen.
Was eine Prüfung auslöst
Die Überwachung lauscht auf Dateisystem-Events an den geschützten Pfaden und bewertet nur Inhalte, die erstellt oder geschrieben werden:
| Event | Was passiert |
|---|---|
| Datei erstellt | Als neue Änderung bewertet |
| Datei geschrieben oder geändert | Der hinzugefügte Inhalt wird gegen den letzten sauberen Stand gedifft und bewertet |
| Datei entfernt oder umbenannt | Nicht bewertet: Inhalt zu entfernen ist kein Vergiftungsvektor |
Verzeichnis-Events und die eigenen Laufzeitdateien des Daemon werden vor der Bewertung herausgefiltert; nur Memory-Dateien im Geltungsbereich erreichen das Modell.
Die drei Ergebnisse
Jede bewertete Änderung endet in genau einem von drei Ergebnissen:
| Ergebnis | Wann | Was der poison0-Agent tut |
|---|---|---|
| Durchlassen | Die Änderung wird als harmlos bewertet | Die Änderung wird angenommen und wird zum neuen sauberen Stand |
| Fragen | Die Änderung ist weder eindeutig sicher noch ein bewiesener Angriff | Die Datei bleibt in ihrem letzten sicheren Zustand und Sie werden gefragt, bevor sie wirksam wird. Bei einer erstmalig angelegten Datei gibt es keinen früheren Zustand - eine Ablehnung legt die ganze Datei in Quarantäne, umkehrbar |
| Zurückrollen | Die Änderung wird als bewiesener Angriff bewertet | Die Änderung wird automatisch rückgängig gemacht und die Datei kehrt in ihren letzten sauberen Stand zurück |
Die genaue Bewertung wird hier nicht offengelegt; entscheidend ist das Verhalten: Sicheres geht durch, Unsicheres fragt, Gefährliches rollt zurück. Das unsichere Mittelband behandelt der Nutzer-Dialog.
Zurückrollen ist umkehrbar
Ein Zurückrollen zerstört nie Inhalt. Die gefährliche Änderung wird rückgängig gemacht, indem die letzte bekannt-saubere Version wiederhergestellt wird, und der verdrängte Inhalt wird aufbewahrt, nicht gelöscht:
- Wiederherstellen, nicht löschen: die Datei wird auf ihren letzten sauberen Stand zurückgeschrieben; die Änderung wird in Quarantäne gelegt, beiseitegehalten statt gelöscht.
- Wiederherstellbar: der verdrängte Inhalt bleibt wörtlich erhalten, sodass eine Entscheidung immer rückgängig gemacht werden kann.
- Protokolliert: jedes Ergebnis wird in das lokale Audit-Log geschrieben - was sich änderte, wann und warum.
Weil ein Zurückrollen eine umkehrbare Quarantäne ist, wird ein Eintrag, den der poison0-Agent nicht freigeben konnte, nie stillschweigend zu einer Überzeugung Ihres Agents, und ein Fehlalarm kostet Sie nichts als einen Klick zum Behalten.
Fail-closed: ist der Bewerter nicht verfügbar oder liefert er nichts Verwertbares, wird die Änderung in ihrem sicheren Zustand gehalten, nie durchgewinkt. Sicherheit ist der Standard. Siehe fail-closed als Prinzip.
Weiterlesen
Die genaue Menge der überwachten Dateien: was der poison0-Agent überwacht. Das unsichere Mittelband: der Nutzer-Dialog. Die Haltung sicher-per-Standard: fail-closed.
Hinweis bei Abwehr: das Fenster nach einer Quarantäne
Optional zeigt der poison0-Agent nach einem automatischen Zurückrollen ein Fenster auf dem Gerät. Standard: aus.
| Punkt | Verhalten |
|---|---|
| Einschalten | Konsole: Profil, Einstellung Hinweis bei Abwehr. Private Geräte: sudo poisonzero notify on; die lokale Einstellung hat Vorrang vor dem Profil |
| Inhalt | Datei, entfernter Inhalt und Grund je Fall |
| Häufigkeit | Fälle kurz hintereinander kommen in ein Fenster, höchstens ein Fenster je 10 Minuten |
| Headless-Geräte | Ohne Desktop-Sitzung kein Fenster; die Fälle stehen in sudo poisonzero status und im Audit-Log |
| OK | Fall bleibt in Quarantäne. Schließen oder 5 Minuten ohne Antwort zählen als OK |
| Fehlalarm, wiederherstellen | Nur für Administratoren. Das Betriebssystem fragt je Fall die Anmeldung als Administrator ab; erst nach dieser Anmeldung stellt der Dienst genau den gezeigten Inhalt wieder her |
| Als Fehlalarm melden | Für Nutzer ohne Administratorrechte. Der Fall wird als Fehlalarm vermerkt und bleibt in Quarantäne; das Fenster zeigt den Befehl zum Wiederherstellen |
| Vermerk in der Konsole | Nur Cloud-Geräte mit aktivem Urteil-Teilen; der Fall zeigt dann in der Audit-Ansicht, dass das Gerät ihn als Fehlalarm gemeldet hat. Private Geräte melden nie |
| Claude Code | Ein Hook zeigt neue Fälle als Hinweis für den Menschen, ohne den entfernten Inhalt. poisonzero setup-claude trägt ihn ein |
Hinweis bei Abwehr: Befehle
| Befehl | Wirkung |
|---|---|
poisonzero notify | Zeigt, ob das Fenster an ist und woher die Einstellung kommt (lokal, Profil, Standard) |
sudo poisonzero notify on / off | Lokaler Schalter, gilt vor dem Profil |
sudo poisonzero notify clear | Lokalen Schalter entfernen; das Profil gilt wieder |
sudo poisonzero quarantine false-alarm <id> | Fall als Fehlalarm vermerken; er bleibt in Quarantäne |
sudo poisonzero quarantine restore <id> | Fall wiederherstellen |
poisonzero setup-claude --notice-off | Den Hook wieder aus ~/.claude/settings.json entfernen; andere Einträge bleiben |
Windows: die Befehle mit
sudo in einem Terminal als Administrator ausführen, ohne sudo.