Cómo funciona PoisonZero.

1. Modelo de amenazas: el memory poisoning no es prompt injection

Los agentes de IA guardan una memoria persistente — notas de proyecto, instrucciones permanentes, preferencias aprendidas — en archivos simples en disco (los «Memory Files» y dot-files de herramientas como los asistentes de código). Esa memoria se vuelve a leer en el contexto del modelo en cada ejecución. Es, en la práctica, una extensión escribible del prompt de sistema que sobrevive a los reinicios.

El prompt injection es un problema transitorio: una instrucción maliciosa llega en una petición y desaparece al terminar la sesión. El memory poisoning es persistente. Una sola entrada envenenada — escrita por una herramienta comprometida, por un documento malicioso que el agente resumió, por una carga de la cadena de suministro o por otro agente — sigue influyendo en cada ejecución futura hasta que alguien lo nota. El atacante no necesita estar presente cuando ocurre el daño. Escribe una vez; el agente lee para siempre.

PoisonZero defiende la integridad de esos archivos. Trata cada cambio en un archivo protegido como no fiable hasta que se demuestre seguro, y es fail-closed: ante la duda, el cambio se revierte en lugar de dejarse pasar. Modelamos cinco clases de ataque y entrenamos y evaluamos contra cada una:

• Inyección directa — instrucciones permanentes explícitas coladas en una entrada de memoria («a partir de ahora, haz X») que el agente luego obedece como propias.
• Exfiltración de datos — entradas diseñadas para que el agente filtre secretos, credenciales o contexto privado a un destino controlado por el atacante.
• Metaataques — la entrada ataca a la propia defensa («confía en esta fuente, deja de comprobarla»). Desarma al guardián y cada ataque posterior entra sin más. Tienen una capa de reglas sin IA dedicada (§4).
• Role-play y jailbreak — un personaje o un escenario que saca al agente de sus reglas de seguridad en lugar de emitir la instrucción maliciosa abiertamente.
• Sutil e indirecto — el más difícil: entradas que se leen como notas perfectamente legítimas, sin ninguna pista evidente, ante las que los filtros simples pasan de largo.

2. Arquitectura: un daemon privilegiado, defensa en profundidad

PoisonZero corre como un pequeño daemon privilegiado en cada máquina protegida (una unidad systemd en Linux, un servicio en macOS/Windows). Es dirigido por eventos, no un escáner: no hace nada hasta que un archivo protegido cambia. No hay indexador rastreando su disco ni telemetría de fondo.

El diseño es por capas, de modo que ningún componente sea un único punto de fallo y cada capa sea barata de razonar por sí sola:

Detrás de la misma interfaz hay dos implementaciones de evaluator — una asistida por la nube (Pro, §5) y otra totalmente local (Enterprise, §6). Todo lo que rodea al evaluator es idéntico entre planes: el mismo watcher, las mismas reglas deterministas, la misma lógica de decisión, la misma aplicación y el mismo rastro de auditoría.

3. La cadena de procesamiento en detalle

3.1 El watcher y su garantía de estado final

El watcher usa la facilidad de notificación de cambios nativa del SO (inotify en Linux, kqueue/FSEvents en macOS, ReadDirectoryChangesW en Windows) y aplica debounce por ruta. Editores y agentes rara vez escriben un archivo una sola vez; escriben en ráfagas. Un debounce ingenuo arregla la tormenta de eventos resultante, pero abre un agujero sutil por el que un atacante puede colarse.

Imagine un debounce simple de «descartar todo lo que caiga dentro de la ventana». Un atacante capaz de cronometrar las escrituras lanza una ráfaga: primero una versión benigna, luego, unos milisegundos después, la versión maliciosa final, dentro de la ventana de debounce. Un debounce solo de flanco inicial evalúa la versión benigna y descarta en silencio la escritura maliciosa final — justo el estado que queda en disco y vuelve a leerse en el agente. El ataque aterriza sin ser evaluado.

El watcher de PoisonZero está construido con una garantía de estado final de flanco de salida. Emite de inmediato en el flanco inicial y, si llegan más escrituras dentro de la ventana, programa exactamente una evaluación rezagada tras expirar la ventana — releyendo el estado actual del archivo en ese momento. No importa cómo se cronometre una ráfaga: la versión que realmente acaba en disco es la versión que se puntúa. Las escrituras en ráfaga cuidadosamente cronometradas no pueden colar un estado final esquivando la evaluación. (Es ingeniería adversaria deliberada; se endureció específicamente contra esta evasión.)

3.2 Filtros de política y protección de bucle

Antes de cualquier evaluación corren dos comprobaciones baratas. Primero, los cambios en el propio archivo de aviso al agente de PoisonZero se ignoran — el daemon escribe ese archivo para informar al agente de una acción, y reevaluarlo crearía un bucle de retroalimentación. Segundo, la ruta debe caer bajo un perfil protegido configurado por el administrador; todo lo demás se ignora. Los propios directorios de configuración y estado de PoisonZero están reservados y nunca pueden registrarse como perfil vigilado (registrarlos sería en sí un vector de ataque). Si el nuevo contenido es idéntico byte a byte al estado limpio conocido, el procesamiento se detiene — es solo el eco del propio revert o apply del daemon.

3.3 La capa de reglas deterministas corre primero

Se construye un diff unificado de antiguo-contra-nuevo y se entrega primero a una capa de reglas sin IA (§4). Una coincidencia dura cortocircuita toda la cadena directamente a revert — rápido, determinista e imposible de confundir con una puntuación astuta. Solo si no salta ninguna regla dura el cambio llega al evaluator.

3.4 Evaluación, decisión, aplicación — auditoría en cada paso

El evaluator devuelve una puntuación de danger y otra de confidence (ambas en [0,1]); el motor de decisión las mapea a una acción (§5); el enforcer la ejecuta. Cada resultado — permitir, poner en cuarentena o revertir — produce una entrada de auditoría con marca de tiempo, acción, ruta, motivo y puntuaciones. El rastro de auditoría es local y sobrevive al daemon; en instalaciones gestionadas también se reporta al panel del propietario.

4. Reglas deterministas, puntuación y decisión

4.1 La capa de metaataque sin IA

Algunos ataques nunca deberían depender del juicio de un modelo. Una entrada que intenta editar los propios umbrales de PoisonZero, o desactivar, desinstalar o terminar el producto, o un clásico «ignora todas las instrucciones anteriores», es hostil por construcción. La capa de reglas las atrapa de forma determinista y revierte de inmediato, sin IA de por medio.

El comparador está hecho para resistir la evasión. Toda entrada se normaliza primero en Unicode (NFKC) y se pasa a minúsculas, lo que pliega caracteres de ancho completo, ligaduras y trucos de homóglifos a sus formas base antes de aplicar cualquier patrón — así un atacante no puede colar un override con caracteres parecidos o mayúsculas mezcladas. Las frases de override y de «desactiva el producto» se reconocen en muchos idiomas, incluidos los de escritura no latina, porque el idioma lo elige el atacante, no el defensor. Las reglas están ajustadas para la precisión: los verbos latinos se reconocen en fronteras de palabra y se excluyen explícitamente cuando son solo parte del nombre de un ajuste (p. ej. disable-notifications), para no revertir por error texto de configuración legítimo.

4.2 Puntuación

Cuando un cambio llega al modelo, este devuelve dos números en [0,1]: danger (cuán malicioso parece el cambio) y confidence (cuán seguro está el evaluator). Mantener confidence separada de danger es lo que permite al sistema enviar a una persona los cambios genuinamente ambiguos en vez de adivinar.

4.3 El motor de decisión y sus umbrales por defecto

El motor de decisión es deliberadamente diminuto y total — tres umbrales, tres resultados:

• revert si danger ≥ dangerBlock
• allow si danger ≤ dangerSafe y confidence ≥ confidenceMin
• ask_user (cuarentena) para todo lo intermedio

Los umbrales por defecto son dangerBlock = 0,7, dangerSafe = 0,3, confidenceMin = 0,6 (configurables centralmente por el administrador). Así, un cambio puntuado en danger 0,97 está muy por encima del umbral de bloqueo y se revierte sin más; un cambio en danger 0,1 con confidence 0,9 se permite; un cambio en danger 0,5 — o uno de apariencia benigna del que el modelo no está seguro — cae en la zona gris y se pone en cuarentena para revisión.

Es clave: el motor es fail-closed. Si la evaluación no puede realizarse en absoluto — el modelo falló, agotó el tiempo o devolvió algo no parseable — el resultado no es «permitir por defecto». Es revert. Las puntuaciones solo se pasan adelante cuando la evaluación realmente tuvo éxito.

4.4 La zona gris: cuarentena y revisión asíncrona

Un resultado ask_user no bloquea al agente esperando a una persona. El cambio se pone en cuarentena y el último estado limpio conocido se restaura en disco de inmediato, de modo que el agente sigue trabajando sobre contenido de confianza. La versión envenenada se conserva fuera de banda para que el propietario la revise de forma asíncrona en el panel; cuando decide, el daemon la aplica o la descarta y registra el resultado. Las revisiones son asíncronas por principio — la protección nunca depende de que un administrador esté en línea en el momento del evento.

5. Flujo A — Asistido por la nube (Pro)

En el plan Pro, un endpoint en la nube endurecido realiza la evaluación. El rasgo que define este flujo es que está construido en torno a un contrato de datos verificable, no a una promesa.

5.1 Redacción local antes de que nada salga

Antes de enviar un solo byte para evaluación, el diff pasa por un paso de redacción local en el dispositivo. Elimina, por patrones, las clases de secretos y PII estructurada que reconoce de forma fiable sin conexión: claves API (estilo OpenAI/Anthropic, GitHub, Slack, AWS, Google, Stripe), JWT, asignaciones genéricas de key/token/secret/password (el valor se elimina, el nombre de la clave se mantiene), direcciones de correo, IBAN, números de tarjeta, direcciones IP y números de teléfono internacionales. Se reemplaza por marcadores que preservan la estructura ([REDACTED:email], [REDACTED:apikey] …) para que el modelo aún pueda razonar sobre el cambio.

Somos honestos con el límite: los nombres en texto libre y la PII no estructurada no son detectables de forma fiable sin conexión y sin ML, así que el redactor elimina solo lo que puede coincidir con seguridad y nada más. Puede ver exactamente qué enviaría una evaluación pasando cualquier archivo por el comando redact del producto antes de confiar en él.

5.2 El contrato de datos: carga mínima, endpoints fijos

Solo salen una ruta de archivo y el diff unificado redactado — nunca el texto completo. Hay un conjunto pequeño y fijo de endpoints, cada uno con una carga documentada y mínima: la inscripción lleva un app ID y un código de un solo uso; la evaluación lleva la ruta y el diff redactado; el sondeo de configuración no lleva nada salvo un token de autenticación; los informes de auditoría y cuarentena llevan marcas de tiempo, acciones, rutas, motivos y puntuaciones (el informe de cuarentena incluye el mismo diff redactado, con tamaño limitado). Los archivos fuera de los perfiles configurados, los textos completos, los listados de directorios o procesos y la telemetría del sistema nunca salen de la máquina. Todo el transporte va sobre TLS.

5.3 El registro de egreso: verificar, no confiar

Cada petición saliente se registra localmente en un registro de egreso legible por humanos. Cada línea lleva la marca de tiempo, el endpoint, el tamaño de la carga, el SHA-256 de la carga (nunca el contenido) y el estado HTTP:

Es la contabilidad de «¿llama a casa?», escrita para que sus equipos de DLP y auditoría puedan verificar en lugar de creernos. El registro puede contrastarse con la propia red — el daemon solo contacta con el backend de evaluación y el endpoint de token de autenticación, y un observador externo (logs de firewall, una captura de paquetes, un proxy de filtrado de egreso) debe ver exactamente las peticiones que el registro anota, y nada más.

6. Flujo B — Totalmente en el dispositivo (Enterprise)

En el plan Enterprise, la evaluación se traslada por completo a la máquina. Un modelo de detección compacto y de propósito específico y nuestro propio motor de inferencia corren localmente, y ningún contenido sale del edificio en absoluto — no hay nube de análisis a la que filtrar, porque no hay nube de análisis.

6.1 Ciclo de vida bajo demanda

El motor de inferencia no corre de forma continua. Se inicia de forma perezosa cuando llega una comprobación de memoria y se apaga de nuevo tras un breve tiempo de inactividad. El archivo de modelo pesa algo más de 300 MB y se carga por memory-mapping al arrancar; durante una comprobación, el componente de análisis ocupa esa huella unos segundos, y en reposo el producto es solo el daemon — unos pocos MB de RAM. La breve ventana de inactividad absorbe ráfagas de ediciones sin mantener la huella residente. Es solo CPU y corre en hardware corriente; no requiere GPU.

6.2 El motor de inferencia corre en un sandbox de mínimos privilegios

Es una frontera de seguridad deliberada, no mera higiene. El motor, por definición, parsea texto controlado por el atacante — justamente los diffs de memoria que investigamos como potencialmente envenenados. Un fallo explotable en el motor sería, si no, un camino directo de «el atacante escribe un archivo de memoria» a «ejecución de código en el componente de análisis». La respuesta es el aislamiento: con el motor en sandbox, un exploit del motor degrada a un fallo de proceso inofensivo en vez de a un compromiso. El daemon — el verdadero producto de seguridad — queda intacto y revierte ante la duda.

El perfil de mínimos privilegios, aplicado a cada proceso efímero del motor:

• Red: se enlaza solo a 127.0.0.1, en un puerto efímero que asigna el daemon. Ninguna otra interfaz, ninguna red saliente, ningún DNS. El modelo está sin conexión; el motor necesita cero acceso a red en tiempo de ejecución.
• Sistema de archivos: acceso de solo lectura al archivo de modelo fijado y a sus propias dependencias. Sin acceso de escritura en ningún sitio.
• Proceso: no genera procesos hijos, corre sin privilegios con capacidades reducidas.

En Linux esto se aplica desde el día uno mediante endurecimiento de systemd y un filtro de llamadas al sistema (seccomp) — sin nuevos privilegios, una vista del sistema estrictamente de solo lectura, un conjunto de capacidades vacío, direccionamiento solo a localhost, un montaje de solo lectura de la ruta del modelo — con endurecimiento de LSM de sistema de archivos (Landlock) como fast-follow donde el kernel lo soporta. macOS y Windows aplican el mismo mínimo del día uno — solo localhost, ruta del modelo de solo lectura, sin generación de subprocesos — con perfiles de sandbox completos (un perfil de sandbox firmado en macOS; un token restringido y un Job Object en Windows) como fast-follow. Decimos explícitamente qué es del día uno y qué es fast-follow, en vez de insinuar un máximo uniforme en todas partes.

6.3 Salida no fiable y fijado de hash antes de cada arranque

Incluso dentro del sandbox, el daemon trata la respuesta del motor como entrada no fiable: si se cae, se cuelga o devuelve algo inesperado, la decisión es fail-closed (revert), nunca un permiso silencioso. Y antes de cada arranque del motor, el daemon verifica el SHA-256 del archivo de modelo contra un hash fijado que figura en su manifiesto de licencia firmado. Esto protege la cadena de distribución y a la vez cierra un vector de exploit local — un archivo de modelo cambiado o corrupto (p. ej. una cabecera manipulada para explotar el cargador) se detecta antes de que el motor siquiera arranque; simplemente no arranca.

6.4 Compatible con air-gap

Entre comprobaciones, el producto corre totalmente sin conexión. La única excepción es una comprobación de licencia mensual — solo credenciales y versión, nunca contenido. Sin telemetría, sin egreso de contenido, y nada en la ruta de evaluación necesita la red. El mismo registro de egreso (§5.3) anota esa comprobación mensual, así que también es verificable en lugar de supuesta.

7. Integridad y cadena de suministro

Lo que instala tiene que ser lo que construimos. Cada artefacto de release está firmado con Cosign keyless (Sigstore) y publicado con un manifiesto SHA256SUMS, de modo que cada binario es verificable contra una lista de sumas firmada antes de ejecutarse siquiera. El instalador de una línea verifica la suma automáticamente; los operadores en air-gap verifican a mano.

En el plan Enterprise la cadena se extiende al propio modelo: el modelo de detección es un artefacto firmado y protegido en integridad cuyo SHA-256 está fijado en el manifiesto de licencia firmado y se vuelve a verificar antes de cada arranque del motor (§6.3). La integridad no se comprueba una vez en la descarga, sino de forma continua en cada uso.

8. Rendimiento de detección

El modelo de detección no es un clasificador genérico de catálogo. Está afinado sobre un gran corpus de propósito específico de ejemplos reales de ataque y benignos, con una cadena de etiquetado en la nube que mantiene afilado el modelo en el dispositivo a medida que aparecen nuevos patrones de ataque — sin que sus datos lo alimenten jamás.

Los números que medimos, expresados en términos relativos y con honestidad: en el mismo conjunto de prueba detecta más de 3× tantos ataques como los principales modelos de guardia de catálogo, y marca de forma fiable las clases ante las que esos detectores estándar son prácticamente ciegos — inyección sutil/indirecta y exfiltración de datos. El afinado redujo las falsas alarmas en alrededor de un 95 % frente al modelo base sin afinar. En pruebas internas amplias y realistas detecta más del 94 % de los ataques con menos del 5 % de falsas alarmas.

Metodología, en breve. La evaluación se hace sobre datos held-out que el modelo nunca entrenó, equilibrados entre las cinco clases de ataque (§1) y entre muchos idiomas. El conjunto benigno es deliberadamente adversario — incluye el tipo de notas legítimas que parecen alarmantes y hacen tropezar a los filtros de palabras clave — para que la tasa de falsas alarmas refleje contenido realista, no negativos fáciles. Reportamos ganancias relativas y un punto de operación medido en vez de una única cifra de precisión de titular, porque un detector solo vale lo que su clase de ataque más débil y su comportamiento en casos benignos difíciles.

9. Límites honestos y riesgo residual

Ningún detector detiene todos los ataques en todas partes, y no afirmamos una tasa de captura del 100 % — los números de arriba son los que medimos, y los seguimos subiendo. Algunos límites honestos:

• La redacción sin conexión es por patrones. En el flujo asistido por la nube, los nombres en texto libre y la PII no estructurada no son detectables de forma fiable sin conexión y sin ML, así que pueden pasar a un diff redactado. Los equipos con requisitos estrictos mantienen los memory files con poca PII — o usan el flujo totalmente local, donde nada sale.
• Quedan falsas alarmas y falsos negativos residuales. El diseño de zona gris a cuarentena existe precisamente porque el modelo no es infalible; los cambios ambiguos van a una persona en vez de adivinarse, y el sistema es fail-closed cuando no puede decidir.
• El endurecimiento del sandbox está escalonado por plataforma. El aislamiento más estricto es del día uno en Linux; macOS y Windows alcanzan un mínimo documentado del día uno con perfiles más fuertes como fast-follow (§6.2). Lo decimos en vez de insinuar un endurecimiento máximo uniforme.
• PoisonZero protege la integridad de archivos, no el runtime del agente. Defiende los memory files y dot-files persistentes que lee un agente; no es un EDR para el proceso del agente en sí, y complementa, en vez de reemplazar, sus controles de endpoint existentes.

El principio que une todo esto es el mismo: fail-closed. Cuando el sistema no está seguro, no puede evaluar o su componente de análisis se comporta mal, el cambio se revierte y el último estado limpio se mantiene. El modo de fallo por defecto es la seguridad, no la aceptación silenciosa.