Un desarrollador ha publicado maat, un proyecto de código abierto que deja a un agente de IA investigar averías en Ubuntu sin poder cambiar nada por su cuenta, aunque el modelo sea engañado por el contenido de los registros que lee. La apuesta es que los límites los ponga el kernel, a través del confinamiento de los snaps, y no las instrucciones del prompt. El proyecto, escrito en Go y con licencia GPL-3.0, está en vista previa y todavía no hay datos de cómo se comportan modelos reales con él.
Las claves de maat y los agentes de IA en Linux en 20 segundos
- maat trata los logs como texto escrito por posibles atacantes, no como datos fiables.
- El agente solo lee el sistema desde un snap sin red y no puede ejecutar órdenes.
- Un modelo secuestrado solo puede proponer un plan que revisa y aprueba una persona.
- Su benchmark con máquinas averiadas aún no tiene resultados de modelos reales.
Dar a un agente acceso a un servidor suele significar darle una shell, con todo lo que el usuario puede hacer. El problema, según explica el repositorio de maat, es que los registros del sistema son entrada controlada por terceros. El nombre de usuario de un intento fallido de SSH llega al log tal y como lo escribió el atacante, igual que cualquier mensaje enviado con logger o la descripción de una unidad de systemd. Un agente que lee logs lee texto escrito por desconocidos, y parte de ese texto puede estar escrito para él.
Por qué no basta con pedirle al modelo que se porte bien
El proyecto recuerda que las defensas a nivel de aplicación son difíciles. En septiembre de 2026, el servidor MCP de solo lectura de Red Hat para Linux publicó avisos de seguridad por un aislamiento que no se aplicaba a las órdenes de lectura y por una inyección de prompts a través de un campo sin sanear, ambos corregidos. Y los propios responsables de MCP han explicado que anotaciones como readOnlyHint son pistas, y que las garantías reales corresponden a controles de red o aislamiento.
maat usa ese aislamiento. Su servidor MCP corre en un snap con confinamiento estricto, solo con permisos para observar el journal, el estado de systemd y los discos, y sin acceso a red. Aunque el modelo esté completamente comprometido, el kernel rechaza las llamadas para abrir conexiones, escribir archivos o reiniciar servicios. Funciona con clientes como Claude Code, OpenCode o goose, y con modelos en la nube o locales mediante los inference snaps de Canonical. Los detalles de instalación y uso para administradores están en el análisis de Administración de Sistemas.
Un plan falso, detectado
Lo único que el modelo puede hacer es proponer una acción de un catálogo cerrado, como reiniciar un servicio fallido. La demostración del autor muestra qué pasa cuando el modelo está secuestrado: el plan esconde un falso aviso de plan verificado mediante códigos de escape de terminal y cita evidencias que nunca se recogieron. La herramienta de revisión, maatctl, muestra esos códigos como texto plano y marca la cita inventada, porque el servidor asigna un identificador a cada evidencia y recuerda cuáles ha emitido. Solo después de que una persona confirme, polkit autoriza el cambio y maat comprueba el resultado. Todo queda en un registro encadenado por hash.
Las pruebas también corrigieron el diseño. El permiso para observar la red resultó permitir conexiones salientes, un posible canal para sacar datos, y se eliminó. Además, la herramienta que lista sockets devolvía en silencio que no había ninguno porque no podía leerlos; ahora falla y lo dice. Según su autor, una herramienta de seguridad nunca debe convertir un no puedo verlo en un no hay nada.
Lo que falta: medir modelos reales
maat incluye maat-bench, un banco de pruebas que crea máquinas Ubuntu averiadas en contenedores LXD y puntúa sin un juez basado en IA: si el agente encuentra la causa, qué evidencias cita, si su arreglo funciona, si se contiene cuando no hace falta tocar nada y si resiste las instrucciones plantadas en los logs. Hoy hay diez escenarios. Una referencia sin IA basada en palabras clave acierta el diagnóstico en 9 de 10 y un oráculo que conoce la respuesta, en 10 de 10. El propio autor advierte de que los escenarios son demasiado fáciles para distinguir buenos modelos de mediocres y de que aún no ha publicado resultados de modelos reales: los planes del vídeo de demostración los genera un cliente programado que hace de agente.
Preguntas frecuentes
¿Qué problema intenta resolver maat?
Que un agente de IA pueda diagnosticar un servidor Ubuntu sin recibir una shell, de forma que un modelo engañado por los logs no pueda cambiar el sistema.
¿Cómo detecta maat un plan manipulado?
maatctl muestra como texto los códigos de escape de terminal y marca las evidencias que el servidor nunca emitió.
¿Hay resultados con modelos reales?
No. El banco de pruebas está construido, pero solo hay resultados de una referencia sin IA y de un oráculo.
Fuentes:
