maat es una herramienta de código abierto que permite a un agente de IA diagnosticar un servidor Ubuntu sin darle una shell: sus herramientas solo leen el sistema, corren dentro de un snap con confinamiento estricto y cualquier cambio necesita la aprobación de una persona a través de polkit. Su autor la ha presentado como una vista previa para desarrolladores, escrita en Go y con licencia GPL-3.0, y la idea de fondo es que los límites los imponga el kernel y no el buen comportamiento del modelo.
Las claves de maat para Ubuntu en 20 segundos
- El agente lee el journal, los servicios y los procesos, pero no puede escribir ni usar la red.
- Las correcciones se proponen como planes tipados que una persona revisa y aprueba.
- polkit autoriza cada cambio, igual que con systemctl, y maat comprueba el resultado.
- Todo queda en un registro encadenado por hash con puntos de control en el journal.
La forma habitual de dar a un agente acceso a una máquina Linux es una shell, y con ella el agente puede hacer todo lo que puede hacer el usuario. maat parte del caso contrario. Es un servidor MCP (Model Context Protocol), el protocolo con el que clientes como Claude Code, OpenCode o goose conectan los modelos con herramientas externas, pensado para resolver incidencias en Ubuntu con el menor privilegio posible.
Cómo limita maat al agente
El servidor, maat mcp, se ejecuta dentro de un snap con confinamiento estricto (AppArmor y seccomp), se niega a correr como root y solo conecta interfaces de observación: log-observe, system-observe y mount-observe. No tiene la interfaz de red. Según las pruebas publicadas en el repositorio, en una máquina virtual con Ubuntu 24.04 en arm64 el autotest pasa sus seis comprobaciones: lee el journal y lista 502 unidades de systemd, pero la creación de cualquier socket de internet falla con EACCES, la escritura en el directorio personal se rechaza y AppArmor bloquea RestartUnit.
Antes de que nada llegue al modelo, maat elimina secretos de los registros, agrupa las líneas repetidas en plantillas con el algoritmo Drain, las ordena y las recorta para que quepan en el contexto de un modelo pequeño. Cada unidad, línea de log, sistema de archivos o proceso lleva un identificador de evidencia, y el servidor recuerda qué ha emitido. Estas son algunas de sus herramientas:
system_overview,list_unitsyunit_status: estado del sistema, unidades y unidades fallidas.recent_failures: todas las unidades fallidas con su estado y un extracto del log sin secretos.journal_summary,kernel_messagesyapparmor_denials: resúmenes del journal, del kernel y de los bloqueos de AppArmor.disk_usageytop_processes: espacio, inodos y procesos que más consumen.propose_action: la única que escribe, y solo guarda un plan en el directorio de datos de maat.
Del plan al cambio: maatctl, polkit y auditoría
El modelo no ejecuta órdenes. Solo puede proponer una acción de un catálogo cerrado: reiniciar un servicio fallido (service.restart), limpiar su estado de fallo (service.reset-failed) o revertir un snap (snap.revert). maat añade las precondiciones, la comprobación de éxito y el paso para deshacer, y solo acepta unidades .service, porque reiniciar un target como reboot.target reiniciaría la máquina.
Para aplicar el plan, el administrador usa maatctl, un programa aparte que nunca corre como root. Comprueba el plan desde cero, verifica que no se ha modificado desde que se propuso, muestra los caracteres de control de terminal como texto y señala las evidencias que el servidor nunca emitió. Tras la confirmación, llama a las API de systemd o snapd que ya exigen autenticación de polkit, la misma que protege systemctl restart, y verifica el resultado. Cada paso queda en un registro encadenado por hash con puntos de control en el journal de systemd, que maat trail verify comprueba.
sudo snap install maat --edge
for iface in log-observe system-observe mount-observe; do
sudo snap connect "maat:$iface"
done
maat selftest
maat diagnoseLenguaje del código: JavaScript (javascript)maat diagnose genera el mismo análisis como informe sin intervención de IA. Para conectarlo a un cliente basta con claude mcp add maat -- maat mcp u opencode mcp add maat -- maat mcp, y para mantener todo en local se puede usar un modelo de los inference snaps de Canonical.
Lo que el autor descubrió al probarlo
Probar el confinamiento en una máquina real cambió el diseño dos veces, según cuenta su autor. La interfaz network-observe resultó permitir conexiones TCP salientes, lo que daría a un modelo secuestrado una vía para sacar datos, así que la eliminó. Y system-observe no cubre /proc/net, por lo que la herramienta de sockets devolvía en silencio que no había ninguno; ahora falla y explica el motivo. Por eso listening_sockets no está disponible dentro del snap y network_state solo muestra nombres de interfaces y contadores.
El propio repositorio enumera los límites: la redacción de secretos se basa en patrones y puede fallar, con un modelo en la nube los datos resumidos salen de la máquina, maat no puede quitar la shell que el cliente MCP dé al modelo, el registro detecta manipulaciones pero no las impide frente a root y solo se ha probado en Ubuntu 24.04 en arm64. Su autor la presenta como una propuesta independiente alineada con lo que Canonical ha dicho que quiere para los agentes en Ubuntu: análisis de solo lectura, permisos acotados y trazabilidad completa.
Preguntas frecuentes
¿Qué es maat?
Un servidor MCP de código abierto, escrito en Go y con licencia GPL-3.0, que permite a un agente de IA diagnosticar Ubuntu con herramientas de solo lectura confinadas en un snap.
¿Puede el agente cambiar el sistema?
No por sí solo. Solo propone planes de un catálogo cerrado, que una persona aplica con maatctl tras la autenticación de polkit.
¿En qué versiones de Ubuntu funciona?
En Ubuntu 24.04 o posterior, aunque solo se ha probado en 24.04 en arm64. Se instala desde el canal edge de la Snap Store.
¿Está listo para producción?
No. Es una vista previa para desarrolladores y todavía no hay resultados de cómo se comportan modelos reales con la herramienta.
Fuentes:
