Wie PoisonZero funktioniert.

1. Threat-Model: Memory Poisoning ist nicht Prompt Injection

KI-Agenten halten ein persistentes Gedächtnis — Projektnotizen, stehende Anweisungen, gelernte Präferenzen — in einfachen Dateien auf der Platte (die „Memory Files“ und dot-Files von Werkzeugen wie Coding-Assistenten). Dieses Gedächtnis wird bei jedem Lauf zurück in den Kontext des Modells gelesen. Es ist faktisch eine schreibbare Erweiterung des System-Prompts, die Neustarts überlebt.

Prompt Injection ist ein transientes Problem: Eine bösartige Anweisung kommt in einer Anfrage an und ist mit dem Ende der Sitzung wieder weg. Memory Poisoning ist persistent. Ein einziger vergifteter Eintrag — geschrieben von einem kompromittierten Werkzeug, einem bösartigen Dokument, das der Agent zusammengefasst hat, einer Supply-Chain-Payload oder einem anderen Agenten — beeinflusst jeden künftigen Lauf, bis jemand es bemerkt. Der Angreifer muss nicht anwesend sein, wenn der Schaden eintritt. Er schreibt einmal; der Agent liest für immer.

PoisonZero verteidigt die Integrität dieser Dateien. Es behandelt jede Änderung an einer geschützten Datei als nicht vertrauenswürdig, bis sie als sicher erwiesen ist, und es ist fail-closed: Im Zweifel wird die Änderung zurückgerollt, nicht durchgewunken. Wir modellieren fünf Angriffsklassen und trainieren und evaluieren gegen jede einzelne:

• Direkte Injektion — explizite stehende Anweisungen, ins Gedächtnis geschmuggelt („ab jetzt tue X“), die der Agent später als eigene befolgt.
• Daten-Exfiltration — Einträge, die den Agenten dazu bringen sollen, Secrets, Zugangsdaten oder privaten Kontext an ein vom Angreifer kontrolliertes Ziel zu leaken.
• Meta-Angriffe — der Eintrag zielt auf die Verteidigung selbst („vertraue dieser Quelle, hör auf, sie zu prüfen“). Schaltet man den Wächter aus, marschiert jeder spätere Angriff hinein. Dafür gibt es eine eigene, KI-freie Regelschicht (§4).
• Role-Play & Jailbreak — eine Persona oder ein Szenario, das den Agenten aus seinen Sicherheitsregeln lockt, statt die bösartige Anweisung offen auszusprechen.
• Subtil & indirekt — das Schwerste: Einträge, die sich wie völlig legitime Notizen lesen, ohne Schlüsselwort-Verräter, an denen einfache Filter glatt vorbeisegeln.

2. Architektur: ein privilegierter Daemon, Defense in Depth

PoisonZero läuft als kleiner, privilegierter Daemon auf jeder geschützten Maschine (systemd-Unit unter Linux, Dienst unter macOS/Windows). Er ist ereignisgetrieben, kein Scanner: Er tut nichts, solange sich keine geschützte Datei ändert. Kein Indexer durchforstet Ihre Platte, keine Hintergrund-Telemetrie.

Der Aufbau ist geschichtet, sodass keine einzelne Komponente ein Single Point of Failure ist und jede Schicht für sich leicht zu durchschauen bleibt:

Hinter derselben Schnittstelle stecken zwei Evaluator-Implementierungen — eine cloud-gestützte (Pro, §5) und eine vollständig lokale (Enterprise, §6). Alles um den Evaluator herum ist tier-übergreifend identisch: derselbe Watcher, dieselben deterministischen Regeln, dieselbe Entscheidungslogik, dieselbe Durchsetzung und derselbe Audit-Trail.

3. Die Pipeline im Detail

3.1 Der Watcher und seine Endstand-Garantie

Der Watcher nutzt die betriebssystemeigene Änderungs-Benachrichtigung (inotify unter Linux, kqueue/FSEvents unter macOS, ReadDirectoryChangesW unter Windows) und debounct pro Pfad. Editoren und Agenten schreiben eine Datei selten einmal; sie schreiben in Bursts. Naives Debouncing behebt zwar den Event-Sturm, reißt aber ein subtiles Loch, durch das ein Angreifer einen Lastwagen fahren kann.

Nehmen Sie ein simples „alles im Fenster verwerfen“-Debounce. Ein Angreifer, der Schreibvorgänge timen kann, setzt einen Burst ab: zuerst eine harmlose Version, dann wenige Millisekunden später die bösartige Endversion, innerhalb des Debounce-Fensters. Ein Debounce nur auf der Leading Edge bewertet die harmlose Version und verwirft die bösartige Endschreibung stillschweigend — genau den Stand, der auf der Platte landet und in den Agenten zurückgelesen wird. Der Angriff landet bewertungsfrei.

Der Watcher von PoisonZero ist mit einer Trailing-Edge-Endstand-Garantie gebaut. Er emittiert sofort auf der Leading Edge, und falls weitere Schreibvorgänge innerhalb des Fensters eintreffen, plant er genau eine Nachzügler-Bewertung nach Ablauf des Fensters ein — und liest dabei den aktuellen Stand der Datei in genau diesem Moment erneut. Egal wie ein Burst getimt ist: Die Version, die tatsächlich auf der Platte landet, ist die Version, die bewertet wird. Gezielt getimte Burst-Writes können keinen Endstand an der Bewertung vorbeischmuggeln. (Das ist bewusstes adversariales Engineering; es wurde gezielt gegen genau diesen Bypass gehärtet.)

3.2 Policy-Filter und Schleifenschutz

Vor jeder Bewertung laufen zwei billige Prüfungen. Erstens werden Änderungen an PoisonZeros eigener Agent-Notice-Datei ignoriert — der Daemon schreibt diese Datei selbst, um den Agenten über eine Aktion zu informieren, und sie erneut zu bewerten würde eine Rückkopplung erzeugen. Zweitens muss der Pfad unter einem vom Admin konfigurierten geschützten Profil liegen; alles andere wird ignoriert. PoisonZeros eigene Konfigurations- und Zustandsverzeichnisse sind reserviert und können nie als überwachtes Profil registriert werden (sie zu registrieren wäre selbst ein Angriffsvektor). Ist der neue Inhalt byte-identisch mit dem bekannten sauberen Stand, stoppt die Verarbeitung — das ist nur das Echo des eigenen Reverts oder Applys des Daemons.

3.3 Die deterministische Regelschicht läuft zuerst

Ein Unified-Diff aus Alt-gegen-Neu wird gebaut und zuerst an eine KI-freie Regelschicht (§4) übergeben. Ein harter Treffer kürzt die gesamte Pipeline direkt zu revert ab — schnell, deterministisch und nicht mit einem cleveren Score zu verwechseln. Nur wenn keine harte Regel greift, erreicht die Änderung den Evaluator.

3.4 Bewertung, Entscheidung, Durchsetzung — Audit an jedem Schritt

Der Evaluator liefert einen danger- und einen confidence-Wert (beide in [0,1]); die Decision Engine bildet diese auf eine Aktion ab (§5); der Enforcer setzt sie um. Jedes Ergebnis — erlauben, quarantänieren oder zurückrollen — erzeugt einen Audit-Eintrag mit Zeitstempel, Aktion, Pfad, Begründung und Scores. Der Audit-Trail liegt lokal und überlebt den Daemon; bei verwalteten Installationen wird er zusätzlich ins Panel des Owners gemeldet.

4. Deterministische Regeln, Scoring und Entscheidung

4.1 Die KI-freie Meta-Angriff-Schicht

Manche Angriffe sollten nie vom Urteil eines Modells abhängen. Ein Eintrag, der versucht, PoisonZeros eigene Schwellwerte zu ändern, das Produkt zu deaktivieren, zu deinstallieren oder zu beenden, oder ein klassisches „ignoriere alle vorherigen Anweisungen“-Override, ist von Natur aus feindlich. Die Regelschicht fängt diese deterministisch ab und rollt sofort zurück, ohne KI im Spiel.

Der Matcher ist gegen Umgehung gebaut. Jede Eingabe wird zuerst Unicode-normalisiert (NFKC) und kleingeschrieben, was Fullwidth-Zeichen, Ligaturen und Homoglyph-Tricks auf ihre Grundformen faltet, bevor irgendein Muster greift — ein Angreifer kann ein Override also nicht mit Look-alike-Zeichen oder gemischter Groß-/Kleinschreibung durchschmuggeln. Die Override- und „deaktiviere das Produkt“-Formulierungen werden über viele Sprachen hinweg erkannt, auch in nicht-lateinischen Schriften, denn die Sprache wählt der Angreifer — nicht der Verteidiger. Die Regeln sind auf Präzision getrimmt: Lateinische Verben werden an Wortgrenzen erkannt und ausdrücklich ausgeschlossen, wenn sie bloß Teil eines Settings-Namens sind (z. B. disable-notifications), damit legitimer Konfigurationstext nicht fälschlich zurückgerollt wird.

4.2 Scoring

Erreicht eine Änderung das Modell, liefert es zwei Zahlen in [0,1]: danger (wie bösartig die Änderung aussieht) und confidence (wie sicher der Evaluator ist). Confidence getrennt von danger zu halten, erlaubt es dem System, wirklich mehrdeutige Änderungen an einen Menschen zu leiten, statt zu raten.

4.3 Die Decision Engine und ihre Default-Schwellwerte

Die Decision Engine ist bewusst winzig und total — drei Schwellwerte, drei Ergebnisse:

• revert, wenn danger ≥ dangerBlock
• allow, wenn danger ≤ dangerSafe und confidence ≥ confidenceMin
• ask_user (Quarantäne) für alles dazwischen

Die Default-Schwellwerte sind dangerBlock = 0,7, dangerSafe = 0,3, confidenceMin = 0,6 (zentral vom Admin konfigurierbar). Eine Änderung mit danger 0,97 liegt also deutlich über der Block-Schwelle und wird ohne Umweg zurückgerollt; eine Änderung mit danger 0,1 bei confidence 0,9 wird erlaubt; eine Änderung mit danger 0,5 — oder eine harmlos wirkende, bei der das Modell unsicher ist — landet im Graubereich und wird zur Review quarantäniert.

Entscheidend: Die Engine ist fail-closed. Lässt sich die Bewertung gar nicht durchführen — das Modell fehlerte, lief in ein Timeout oder lieferte etwas Unparsbares — ist das Ergebnis nicht „im Default erlauben“. Es ist revert. Die Scores werden nur dann weitergereicht, wenn die Bewertung tatsächlich gelang.

4.4 Der Graubereich: Quarantäne und asynchrone Review

Ein ask_user-Ergebnis blockiert den Agenten nicht in der Warteschleife auf einen Menschen. Die Änderung wird quarantäniert, und der letzte bekannte saubere Stand wird sofort auf der Platte wiederhergestellt, sodass der Agent auf vertrauenswürdigem Inhalt weiterläuft. Die vergiftete Version wird out-of-band aufbewahrt, damit der Owner sie asynchron im Panel prüft; entscheidet er, wendet der Daemon sie an oder verwirft sie und protokolliert das Ergebnis. Reviews sind prinzipiell asynchron gedacht — der Schutz hängt nie davon ab, dass ein Admin im Moment des Ereignisses online ist.

5. Flow A — Cloud-gestützt (Pro)

Im Pro-Tier übernimmt ein gehärteter Cloud-Endpoint die Bewertung. Das prägende Merkmal dieses Flows: Er ist um einen überprüfbaren Datenvertrag gebaut, nicht um ein Versprechen.

5.1 Lokale Redaction, bevor irgendetwas das Gerät verlässt

Bevor auch nur ein Byte zur Bewertung gesendet wird, durchläuft der Diff lokal auf dem Gerät einen Redaction-Schritt. Er strippt musterbasiert die Klassen von Secrets und strukturierter PII, die er offline zuverlässig erkennen kann: API-Keys (OpenAI-/Anthropic-Stil, GitHub, Slack, AWS, Google, Stripe), JWTs, generische key/token/secret/password-Zuweisungen (der Wert verschwindet, der Schlüsselname bleibt), E-Mail-Adressen, IBANs, Kreditkartennummern, IP-Adressen und internationale Telefonnummern. Ersetzt wird durch strukturerhaltende Platzhalter ([REDACTED:email], [REDACTED:apikey] …), damit das Modell die Änderung weiter beurteilen kann.

Wir sind ehrlich bei der Grenze: Freitext-Namen und unstrukturierte PII sind offline ohne ML nicht zuverlässig erkennbar, daher strippt der Redactor nur, was er sicher matchen kann — nicht mehr. Sie können genau sehen, was eine Bewertung senden würde, indem Sie eine Datei vorab über den redact-Befehl des Produkts leiten.

5.2 Der Datenvertrag: minimale Payload, feste Endpoints

Nach außen gehen nur ein Dateipfad und der redigierte Unified-Diff — nie Volltexte. Es gibt eine kleine, feste Menge an Endpoints mit je dokumentierter, minimaler Payload: Enrollment trägt App-ID und Einmal-Code; Bewertung trägt Pfad und redigierten Diff; Config-Polling trägt nichts außer einem Auth-Token; Audit- und Quarantäne-Meldungen tragen Zeitstempel, Aktionen, Pfade, Begründungen und Scores (die Quarantäne-Meldung enthält denselben redigierten Diff, größenbegrenzt). Dateien außerhalb der konfigurierten Profile, Volltexte, Verzeichnis- oder Prozesslisten und Systemtelemetrie verlassen das Gerät nie. Der gesamte Transport läuft über TLS.

5.3 Das Egress-Ledger: prüfen statt vertrauen

Jeder ausgehende Request wird lokal in einem menschenlesbaren Egress-Ledger protokolliert. Jede Zeile trägt Zeitstempel, Endpoint, Payload-Größe, den SHA-256 der Payload (nie den Inhalt) und den HTTP-Status:

Das ist die „telefoniert es nach Hause?“-Buchhaltung, geschrieben, damit Ihre DLP- und Audit-Teams prüfen können, statt uns zu glauben. Das Ledger lässt sich gegen das Netz selbst gegenprüfen — der Daemon kontaktiert ausschließlich das Bewertungs-Backend und den Auth-Token-Endpoint, und ein externer Beobachter (Firewall-Logs, ein Packet Capture, ein Egress-Filter-Proxy) muss exakt die Requests sehen, die das Ledger protokolliert, und nichts darüber hinaus.

6. Flow B — Vollständig on-device (Enterprise)

Im Enterprise-Tier wandert die Bewertung vollständig auf die Maschine. Ein kompaktes, eigens gebautes Erkennungsmodell und unsere eigene Inference-Engine laufen lokal, und kein Inhalt verlässt das Gebäude überhaupt — es gibt keine Analyse-Cloud, an die etwas leaken könnte, weil es keine Analyse-Cloud gibt.

6.1 On-Demand-Lebenszyklus

Die Inference-Engine läuft nicht dauerhaft. Sie wird bei einer eingehenden Memory-Prüfung lazy gestartet und nach einem kurzen Idle-Timeout wieder beendet. Die Modell-Datei ist etwas über 300 MB groß und wird beim Start per Memory-Mapping geladen; während einer Prüfung belegt die Analyse-Komponente diesen Footprint für wenige Sekunden, und im Ruhezustand besteht das Produkt nur aus dem Daemon — wenige MB RAM. Das kurze Idle-Fenster fängt Edit-Bursts ab, ohne den Footprint resident zu halten. Sie ist CPU-only und läuft auf gewöhnlicher Hardware; keine GPU nötig.

6.2 Die Inference-Engine läuft in einer Minimal-Privilegien-Sandbox

Das ist eine bewusste Sicherheitsgrenze, nicht bloß Hygiene. Die Engine parst per Definition angreiferkontrollierten Text — eben die Memory-Diffs, die wir als potenziell vergiftet untersuchen. Eine ausnutzbare Schwachstelle in der Engine wäre sonst ein direkter Pfad von „Angreifer schreibt eine Memory-Datei“ zu „Code-Ausführung auf der Analyse-Komponente“. Die Antwort ist Isolation: Läuft die Engine gesandboxed, degradiert ein Engine-Exploit zu einem folgenlosen Prozess-Crash statt zu einer Kompromittierung. Der Daemon — das eigentliche Sicherheitsprodukt — bleibt unberührt und revertet im Zweifel.

Das Minimal-Privilegien-Profil, auf jeden kurzlebigen Engine-Prozess angewandt:

• Netz: bindet ausschließlich an 127.0.0.1, an einem ephemeren Port, den der Daemon vergibt. Kein anderes Interface, kein ausgehendes Netz, kein DNS. Das Modell ist offline; die Engine braucht zur Laufzeit null Netzwerkzugriff.
• Dateisystem: nur lesender Zugriff auf die gepinnte Modell-Datei und die eigenen Abhängigkeiten. Kein Schreibzugriff irgendwo.
• Prozess: spawnt keine Kindprozesse, läuft unprivilegiert mit gedroppten Capabilities.

Unter Linux wird dies Day-1 über systemd-Hardening und einen Syscall-Filter (seccomp) durchgesetzt — no-new-privileges, eine strikt read-only Systemsicht, ein leeres Capability-Set, Localhost-only-Adressierung, ein read-only Bind des Modellpfads — mit Dateisystem-LSM-Härtung (Landlock) als Fast-Follow, wo der Kernel es trägt. macOS und Windows wenden dasselbe Day-1-Minimum an — Localhost-only, read-only Modellpfad, kein Subprozess-Spawn — mit vollständigen Sandbox-Profilen (ein signiertes Sandbox-Profil auf macOS; ein Restricted Token und Job Object auf Windows) als Fast-Follow. Wir sagen ausdrücklich, was Day-1 und was Fast-Follow ist, statt ein einheitliches Maximum überall zu suggerieren.

6.3 Untrusted Output und Hash-Pinning vor jedem Start

Selbst innerhalb der Sandbox behandelt der Daemon die Antwort der Engine als nicht vertrauenswürdige Eingabe: Crasht sie, hängt sie oder liefert sie etwas Unerwartetes, ist die Entscheidung fail-closed (revert), nie ein stilles Erlauben. Und vor jedem Engine-Start verifiziert der Daemon den SHA-256 der Modell-Datei gegen einen gepinnten Hash, der in seinem signierten Lizenz-Manifest steckt. Das schützt die Distributionskette und schließt zugleich einen lokalen Exploit-Vektor — eine ausgetauschte oder korrumpierte Modell-Datei (z. B. ein präparierter Header, gebaut um den Loader zu exploiten) wird erkannt, bevor die Engine überhaupt startet; sie startet schlicht nicht.

6.4 Air-Gap-freundlich

Zwischen den Prüfungen läuft das Produkt vollständig offline. Die einzige Ausnahme ist ein monatlicher Lizenz-Check — nur Zugangsdaten und Version, nie Inhalt. Keine Telemetrie, kein Content-Egress, und nichts im Bewertungspfad braucht das Netz. Dasselbe Egress-Ledger (§5.3) protokolliert diesen Monats-Check, also ist auch er überprüfbar statt unterstellt.

7. Integrität und Supply Chain

Was Sie installieren, muss das sein, was wir gebaut haben. Jedes Release-Artefakt ist mit Cosign keyless (Sigstore) signiert und mit einem SHA256SUMS-Manifest veröffentlicht, sodass jedes Binary gegen eine signierte Prüfsummenliste verifizierbar ist, bevor es überhaupt läuft. Der Ein-Zeilen-Installer prüft die Prüfsumme automatisch; Air-Gap-Betreiber prüfen von Hand.

Im Enterprise-Tier reicht die Kette bis zum Modell selbst: Das Erkennungsmodell ist ein signiertes, integritätsgeschütztes Artefakt, dessen SHA-256 im signierten Lizenz-Manifest gepinnt und vor jedem einzelnen Engine-Start neu verifiziert wird (§6.3). Integrität wird nicht einmal beim Download geprüft, sondern fortlaufend bei jeder Nutzung.

8. Erkennungsleistung

Das Erkennungsmodell ist kein Standard-Klassifikator von der Stange. Es ist auf einem großen, eigens aufgebauten Korpus aus echten Angriffs- und Gutfall-Beispielen fine-getunt, mit einer Cloud-Labeling-Pipeline, die das On-Device-Modell scharf hält, während neue Angriffsmuster auftauchen — ohne dass Ihre Daten je einfließen.

Die Zahlen, die wir messen, relativ und ehrlich angegeben: Auf demselben Testset erkennt es mehr als 3× so viele Angriffe wie führende Guard-Modelle von der Stange und markiert zuverlässig die Klassen, für die jene Standard-Detektoren praktisch blind sind — subtile/indirekte Injektion und Daten-Exfiltration. Das Tuning senkte die Fehlalarme um rund 95 % gegenüber dem ungetunten Basismodell. Über breite, realistische interne Tests erkennt es über 94 % der Angriffe bei unter 5 % Fehlalarmen.

Methodik, kurz. Evaluiert wird auf Held-out-Daten, die das Modell nie gesehen hat, ausgewogen über die fünf Angriffsklassen (§1) und über viele Sprachen. Das Gutfall-Set ist bewusst adversarial — es enthält genau die Art legitimer Notizen, die alarmierend aussehen und Schlüsselwort-Filter stolpern lassen — sodass die Fehlalarm-Rate realistischen Inhalt widerspiegelt, keine einfachen Negative. Wir berichten relative Gewinne und einen gemessenen Betriebspunkt statt einer einzelnen Schlagzeilen-Genauigkeit, denn ein Detektor ist nur so gut wie seine schwächste Angriffsklasse und sein Verhalten bei schweren Gutfällen.

9. Ehrliche Grenzen und Restrisiko

Kein Detektor stoppt jeden Angriff überall, und wir behaupten keine 100-%-Trefferquote — die Zahlen oben sind die, die wir messen, und wir heben sie weiter an. Ein paar ehrliche Grenzen:

• Offline-Redaction ist musterbasiert. Im cloud-gestützten Flow sind Freitext-Namen und unstrukturierte PII offline ohne ML nicht zuverlässig erkennbar und können in einen redigierten Diff geraten. Teams mit strikten Anforderungen halten Memory Files PII-arm — oder nutzen den vollständig lokalen Flow, bei dem gar nichts das Gerät verlässt.
• Es bleiben Rest-Fehlalarme und -Falschnegative. Das Graubereich-zu-Quarantäne-Design existiert genau deshalb, weil das Modell nicht unfehlbar ist; mehrdeutige Änderungen gehen an einen Menschen, statt geraten zu werden, und das System ist fail-closed, wenn es nicht entscheiden kann.
• Die Sandbox-Härtung ist nach Plattform gestaffelt. Die strikteste Isolation ist Day-1 unter Linux; macOS und Windows erreichen ein dokumentiertes Day-1-Minimum mit stärkeren Profilen als Fast-Follow (§6.2). Wir sagen das, statt einheitliche Maximalhärtung zu suggerieren.
• PoisonZero schützt Datei-Integrität, nicht die Agenten-Laufzeit. Es verteidigt die persistenten Memory- und dot-Files, die ein Agent liest; es ist kein EDR für den Agenten-Prozess selbst und ergänzt Ihre bestehenden Endpoint-Kontrollen, statt sie zu ersetzen.

Das verbindende Prinzip durch all das ist dasselbe: fail-closed. Wenn das System unsicher ist, nicht bewerten kann oder seine Analyse-Komponente sich danebenbenimmt, wird die Änderung zurückgerollt und der letzte saubere Stand bleibt. Der Default-Fehlermodus ist Sicherheit, nicht stille Annahme.