El motor que solo puede leer y responder

Cuando PoisonZero analiza un cambio on-device, el motor hace exactamente dos cosas: leer el modelo y responder en localhost - y ese límite lo impone el núcleo del sistema operativo. Como lee entrada controlada por el atacante, es el componente más encerrado que entregamos: un exploit se convierte en un fallo de proceso sin consecuencias, no en una cabeza de puente.

En todas las plataformas la regla es estricta: si la sandbox no está disponible, el motor no arranca. No hay degradación silenciosa a una ejecución sin sandbox; el cambio sospechoso se conserva en su sitio y se expone como evento de auditoría estructurado, nunca se revierte en silencio. Una vez que un envenenamiento queda probado, el daemon privilegiado pone en cuarentena el archivo de memoria afectado en su sitio, y esa cuarentena se mantiene. Más sobre esto: Por qué gana el fail-closed.

Cómo funciona la jaula en cada sistema operativo

macOS: el motor corre en la sandbox del núcleo (Seatbelt) bajo un perfil deny-by-default que viaja como archivo auditable junto al modelo, y cae al usuario sin privilegios nobody. Cómo funciona la jaula de macOS →

Linux: Landlock (un LSM del núcleo, deny-by-default) solo permite al motor leer el modelo, ejecutar su propio binario y enlazar un puerto local; el núcleo rechaza cualquier conexión saliente antes de que un byte salga del sistema. Cómo funciona la jaula de Linux →

Windows: el motor corre en un AppContainer aislado de red sin ninguna capacidad de red - ni siquiera localhost - superpuesto a un token restringido, integridad baja y un Job Object (exactamente un proceso, sin hijo, memoria limitada), así que no tiene ninguna vía hacia la red. Ese es el camino de CPU. Un arranque por GPU con Enterprise Ultra abandona el contenedor y renuncia a la rebaja de integridad; token, job object y bloqueo de red siguen. Cómo funciona la jaula de Windows →

Con Ultra el motor puede usar la GPU para ganar velocidad. En macOS y Linux ese camino tiene la misma aislación impuesta por el núcleo que el camino de CPU. En Windows no: el arranque por GPU abandona el AppContainer y se ejecuta sin la rebaja de integridad, porque el cargador Vulkan no puede crear ahí una fábrica DXGI y el motor no puede leer ni su archivo de clave ni el modelo con un token rebajado. Lo que sigue vigente en todos los caminos: un token restringido sin privilegios, un job object limitado a un solo proceso con tope de memoria, acceso a archivos deny-by-default y el bloqueo de red por App-ID en IPv4 e IPv6 - todo fail-closed, de modo que el motor no arranca si falta alguna de esas capas. El scoring sigue on-device en ambos modos. La contrapartida exacta está en el whitepaper técnico.