Die Engine, die nur lesen und antworten kann
Die Analyse-Engine kann genau zwei Dinge: das Modell lesen und auf localhost antworten. Sonst nichts - und das erzwingt der Betriebssystem-Kern, nicht unser Code.
Bewertet der poison0-Agent eine Änderung on-device, kann die Engine genau zwei Dinge: das Modell lesen und auf localhost antworten - und diese Grenze erzwingt der Betriebssystem-Kern. Weil sie angreiferkontrollierten Input liest, ist sie die am stärksten eingesperrte Komponente, die wir ausliefern: Ein Exploit wird zu einem folgenlosen Prozess-Crash, nicht zu einem Brückenkopf.
Auf jeder Plattform gilt dieselbe, strikte Regel: Ist die Sandbox nicht verfügbar, startet die Engine nicht. Es gibt kein stilles Degradieren zu einem ungesicherten Lauf; die verdächtige Änderung bleibt liegen und wird als strukturiertes Audit-Ereignis sichtbar gemacht, nie stillschweigend rückgängig gemacht. Ist eine Vergiftung bewiesen, nimmt der privilegierte Daemon die betroffene Memory-Datei an Ort und Stelle in Quarantäne, und diese Quarantäne bleibt bestehen. Mehr dazu: Warum Fail-closed gewinnt.
So funktioniert der Käfig je Betriebssystem
macOS: Die Engine läuft in der Kernel-Sandbox (Seatbelt) unter einem deny-by-default-Profil, das als auditierbare Datei neben dem Modell liegt, und fällt auf den unprivilegierten Nutzer nobody zurück. Wie der macOS-Käfig funktioniert →
Linux: Landlock (ein Kernel-LSM, deny-by-default) erlaubt der Engine nur, das Modell zu lesen, ihr eigenes Binary auszuführen und an einen lokalen Port zu binden; jede ausgehende Verbindung verweigert der Kernel, bevor ein Byte das System verlässt. Wie der Linux-Käfig funktioniert →
Windows: Die Engine läuft in einem netzwerk-isolierten AppContainer ohne Netzwerk-Capability - nicht einmal localhost -, zusätzlich unter einem Restricted Token, niedriger Integrität und einem Job Object (genau ein Prozess, kein Kind, gedeckelter Speicher), sodass sie überhaupt keinen Weg ins Netz hat. Das ist der CPU-Pfad. Ein GPU-Start unter Melira Ultra verlässt den Container und gibt die Integritäts-Absenkung auf; Token, Job-Objekt und Netzsperre bleiben. Wie der Windows-Käfig funktioniert →
Mit Ultra kann die Engine die GPU für Tempo nutzen. Auf macOS und Linux gilt dort dieselbe kernel-erzwungene Isolation wie auf dem CPU-Pfad. Auf Windows nicht: Der GPU-Start verlässt den AppContainer und läuft ohne die Integritäts-Absenkung, weil der Vulkan-Loader darin keine DXGI-Factory erzeugen kann und die Engine mit abgesenktem Token weder Schlüsseldatei noch Modell liest. Was auf jedem Pfad bleibt: ein eingeschränktes Token ohne Privilegien, ein Job-Objekt mit genau einem erlaubten Prozess und Speicherdeckel, deny-by-default-Dateizugriff und die App-ID-Netzsperre für IPv4 und IPv6 - alles fail-closed, die Engine startet also nicht, wenn eine dieser Schichten fehlt. Das Scoring bleibt in beiden Modi on-device. Die genaue Abwägung steht im technischen Whitepaper.