Por Sally O’Malley, Principal Software Engineer en Emerging Technologies de Red Hat.
Esta semana, desarrollé una imagen de sistema operativo comunitaria para ejecutar agentes de IA: un prototipo de SO agéntico. Está construido usando fedora-bootc, un proyecto comunitario que permite definir un sistema operativo Linux que arranca directamente en un Containerfile. La creación de este SO agéntico pone de relieve una evolución crítica, ya que, al proporcionar un entorno reforzado basado en imágenes, establece una plantilla comunitaria robusta de cómo puede ser en la práctica un SO agéntico. Muestra cómo podría ser un entorno de ejecución dedicado construido con herramientas de código abierto. Se trata de un ejemplo de la gran capacidad que tiene código abierto para ofrecer la capa de infraestructura fiable necesaria para pasar del comportamiento teórico de los agentes a sistemas listos para producción.
¿Qué es fedora-bootc?
Para ejecutar cualquier aplicación en contenedores, normalmente creas un Dockerfile, construyes una imagen, la subes a un registro, la descargas en otro sitio y la ejecutas. fedora-bootc lleva ese mismo flujo de trabajo tan extendido y lo amplía a sistemas operativos completos.
Como proyecto comunitario de Fedora, fedora-bootc utiliza contenedores de la Open Container Initiative y Docker como formato de transporte y entrega para sistemas operativos base. Una imagen de fedora-bootc incluye el kernel de Linux y puede convertirse en una imagen de disco completa (QEMU Copy On Write versión 2 (QCOW2), Amazon Machine Image (AMI), ISO 9660, Google Cloud Image, etc.). Una vez arrancada, la imagen de contenedor se convierte en el sistema: controla el kernel, el proceso init y el sistema de archivos raíz. La mayor parte del sistema de archivos es de solo lectura. Defines tu sistema operativo en tiempo de compilación y, en tiempo de ejecución, quedas limitado a lo que hayas permitido explícitamente que cambie. A esto lo llamo “sistemas basados en imágenes”, porque aportan la tranquilidad de un entorno reproducible y reforzado.
El SO agéntico: por qué construí esta imagen
Creo que un SO agéntico debería ser un sistema Linux con una arquitectura muy definida, gestionado por imágenes, en el que el entorno de ejecución del agente sea una prioridad de primer nivel y la superficie de ataque del host se minimice por diseño. Quería una forma de ejecutar OpenClaw que estuviera razonablemente aislada en un sandbox y fuera fácil de replicar en una flota. Mi configuración habitual —levantar una máquina virtual e instalar paquetes manualmente— puede provocar desvíos en el sistema. Con este SO agéntico, el servicio OpenClaw, los scripts auxiliares, las cuentas de usuario y las unidades de systemd quedan definidos durante la construcción de la imagen.
Para actualizar el entorno, simplemente subes una nueva imagen a tu registro. Cualquier máquina en ejecución la descarga, compara los digests y reinicia hacia la nueva versión mediante sudo bootc upgrade. Actualizar es tan fácil y reversible como cambiar de versión en Git; si algo no funciona, puedes volver atrás sin complicaciones. Esto permite que tus credenciales sensibles, el estado de OpenClaw y las claves SSH permanezcan intactos incluso mientras el SO principal evoluciona.
Compáralo con los sistemas tradicionales, donde el entorno de ejecución del agente, los paquetes del sistema operativo, los archivos de configuración y las credenciales sensibles están todos mezclados en un único sistema de archivos mutable. Cuando algo falla en un sistema mutable, resulta difícil averiguar qué cambió. En esta arquitectura basada en imágenes, la separación de responsabilidades forma parte de la propia arquitectura.
El poder de la flota
Para flotas de sistemas, este enfoque basado en imágenes evita que el sistema se desajuste con el tiempo. Imagina un laboratorio con una docena de máquinas. Cada una arranca la misma imagen de SO agéntico y todas inician OpenClaw exactamente como se espera. Las versiones y configuraciones se mantienen perfectamente sincronizadas. Cuando llega el momento de actualizar, cada máquina consulta el registro, descarga nuevas capas solo si el digest no coincide y se reinicia.
O pensemos en dispositivos edge. Suelen ser pequeños equipos que ejecutan agentes de IA para tareas específicas, cada uno con su propia interfaz OpenClaw. En este escenario, el sistema operativo anfitrión está reforzado y en su mayor parte es de solo lectura. Con actualizaciones gestionadas por imágenes y transaccionales, el agente tiene exactamente lo que necesita, y nada más. Lo que esta configuración permite, en última instancia, es un agente de IA ejecutándose sobre un SO diseñado para ese fin, gestionado por imágenes y endurecido, con credenciales acotadas y actualizaciones transaccionales.
Cómo funciona usando fedora-bootc
Este SO agéntico proporciona un entorno de ejecución estable diseñado para operar de forma predecible por defecto, y la capa del sistema operativo es de solo lectura y está gestionada por imágenes. Utilicé quay.io/fedora/fedora-bootc:latest como sistema operativo base. El Containerfile instala Podman, cloud-init, SSH y Python, y después crea un usuario dedicado llamado openclaw. Esto es lo que ocurre a continuación:
- Aislamiento sin privilegios de root: el agente se ejecuta como usuario no root. OpenClaw funciona como un contenedor Podman sin privilegios gestionado por Quadlet.
- Gestión del estado: aunque la capa del sistema operativo es de solo lectura, el estado mutable del agente vive en un único directorio (~/.openclaw).
- Acceso acotado: añadí service-gator, una herramienta ligera de pasarela personal que se sitúa entre el agente y los servicios externos (GitHub, JIRA, etc.) para hacer cumplir ámbitos de permisos en lugar de usar tokens de acceso personales en bruto. Aunque esto es ideal para configuraciones individuales, MCP Gateway está pensado para desempeñar este papel a escala y en producción en despliegues de clúster.
- Sensación nativa: un envoltorio CLI en el host te permite ejecutar comandos de openclaw de forma natural, mientras la lógica se ejecuta dentro del contenedor.
Las credenciales sensibles no se incorporan a la imagen
La seguridad es fundamental en un SO agéntico. Ninguna credencial sensible se incrusta en la imagen. En su lugar, debes entrar por SSH como usuario openclaw y crear las credenciales sensibles de Podman después del arranque:
printf ‘%s’ «$OPENAI_API_KEY» \
| podman secret create openai_api_key –
printf ‘%s’ «$OPENROUTER_API_KEY» \
| podman secret create openrouter_api_key –
Después, ejecuta tank-openclaw-secrets, una utilidad auxiliar que integra esas credenciales sensibles en los drop-ins de Quadlet y en la configuración de OpenClaw como referencias a credenciales sensibles. Los SecretRefs de OpenClaw evitan las variables de entorno en texto plano al incorporar esas credenciales sensibles en la configuración. También admiten opciones de archivo y de ejecución, lo que ofrece una vía para integrar proveedores externos como 1Password o Vault CLI. Esto te permite generar máquinas idénticas a partir de una única imagen pública e inyectar credenciales únicas por instancia mediante cloud-init, SSH o el método de aprovisionamiento que prefieras. El servicio se reinicia, carga las claves y ya está en marcha.
¿Cómo podría ser el futuro?
Este patrón demuestra el potencial del alojamiento de agentes basado en imágenes a través de la combinación de fedora-bootc para el ciclo de vida del SO, Podman sin privilegios para el aislamiento, Quadlet para la gestión de servicios y el runtime del agente OpenClaw como carga principal.
El proyecto sirve como ejemplo de innovación comunitaria para explorar el SO agéntico, y también refleja la hoja de ruta empresarial más amplia de Red Hat. A principios de este año, compartimos nuestros planes para una base más segura y lista para producción para la fuerza laboral preparada para agentes, junto con NVIDIA. Los sandboxes especializados para agentes, como OpenShell, incorporan medidas de protección avanzadas, incluidas filtrado del tráfico saliente de red, restricciones del sistema de archivos y limitaciones de procesos.
En un entorno de producción, estas dos capas podrían complementarse muy bien. Una capa de sistema operativo gestionada por imágenes se encarga de la base fiable y repetible, mientras que OpenShell establece las políticas de seguridad granulares para el propio agente. Para mí, imaginar el potencial de un proyecto comunitario como este ayuda a comprender su valor y aplicación reales: servir como la base estable y repetible sobre la que se puede construir la próxima generación de soluciones de IA seguras y autónomas.
¿Quieres participar? Prueba la imagen en quay.io/redhat-et/tank-os:latest. Descárgala, construye una imagen de disco y arráncala. Y no olvides visitar el repositorio del proyecto para consultar la documentación sobre compilación, aprovisionamiento y configuración.
Los proyectos mencionados en este blog representan investigación y desarrollo en fase inicial del equipo de Emerging Technologies de Red Hat. Son proyectos upstream de código abierto y no constituyen productos oficiales de Red Hat. No existe garantía de que estos proyectos se conviertan en productos ni de que se integren en las ofertas existentes de Red Hat.
