Le moteur qui ne peut que lire et répondre

Quand PoisonZero analyse un changement sur l'appareil, le moteur fait exactement deux choses : lire le modèle et répondre sur localhost - et c'est le noyau du système d'exploitation qui impose cette frontière. Parce qu'il lit du texte contrôlé par l'attaquant, c'est le composant le plus étroitement enfermé que nous livrons : un exploit se transforme en un crash de processus inoffensif, pas en un point d'ancrage.

Sur chaque plateforme, la règle est stricte : si le sandbox n'est pas disponible, le moteur ne démarre pas. Il n'y a aucune dégradation silencieuse vers un run sans sandbox ; le changement suspect est conservé sur place et exposé comme événement d'audit structuré, jamais annulé en silence. Une fois un empoisonnement prouvé, le daemon privilégié met en quarantaine le fichier de mémoire concerné sur place, et cette quarantaine tient. Plus à ce sujet : Pourquoi le fail-closed l'emporte.

Comment la cage fonctionne selon le système d'exploitation

macOS : le moteur tourne dans le sandbox du noyau (Seatbelt) sous un profil deny-by-default qui est livré comme fichier auditable à côté du modèle, et il redescend vers l'utilisateur non privilégié nobody. Comment fonctionne la cage macOS →

Linux : Landlock (un LSM du noyau, deny-by-default) ne permet au moteur que de lire le modèle, d'exécuter son propre binaire et de se lier à un port local ; le noyau refuse toute connexion sortante avant qu'un octet ne quitte le système. Comment fonctionne la cage Linux →

Windows : le moteur tourne dans un AppContainer isolé du réseau, sans aucune capacité réseau - pas même localhost - avec en complément un token restreint, une intégrité basse et un Job Object (exactement un processus, pas d'enfant, mémoire plafonnée), de sorte qu'il n'a aucune voie vers le réseau. C'est le chemin CPU. Un démarrage GPU sous Enterprise Ultra quitte le conteneur et abandonne l'abaissement d'intégrité ; jeton, job object et blocage réseau demeurent. Comment fonctionne la cage Windows →

Avec Ultra, le moteur peut utiliser le GPU pour la vitesse. Sur macOS et Linux, ce chemin bénéficie de la même isolation imposée par le noyau que le chemin CPU. Sur Windows, non : le démarrage GPU quitte l'AppContainer et s'exécute sans l'abaissement d'intégrité, car le chargeur Vulkan ne peut pas y créer de fabrique DXGI et le moteur ne peut lire ni son fichier de clé ni le modèle sous un jeton abaissé. Ce qui subsiste sur tous les chemins : un jeton restreint sans privilèges, un job object limité à un seul processus avec plafond mémoire, un accès fichiers deny-by-default et le blocage réseau par App-ID en IPv4 et IPv6 - le tout fail-closed, le moteur ne démarre donc pas si l'une de ces couches manque. Le scoring reste sur l'appareil dans les deux modes. Le compromis exact est détaillé dans le whitepaper technique.