Por Qué Deberías Aislar Tus Agentes de Código IA en MicroVMs (Y Cómo Hacerlo)

Hablemos sin rodeos: los agentes de IA para programación han revolucionado el desarrollo. Herramientas como Claude Code y Codex pueden crear funcionalidades, corregir errores y refactorizar código a una velocidad que hace unos años parecía ciencia ficción. Pero hay algo que nobody talks about lo suficiente — estos agentes también son excelentes accediendo a cosas que probablemente no quieres que toquen.

¿Que exploren tu clúster de Kubernetes? Pueden hacerlo. ¿Que se conecten por SSH a tus servidores de producción? Por supuesto. ¿Que ejecuten comandos con privilegios elevados? Técnicamente, si se los permites.

Aquí es donde la goma toca el asfalto. Quieres toda la potencia de un asistente de IA, pero también necesitas dormir tranquilo sabiendo que tu entorno de producción está seguro. ¿La solución? Sandboxing — y específicamente, usar microVMs para darle a estos agentes su propio universo aislado donde trabajar.

La Realidad Sobre Seguridad

Aquí está la verdad incómoda: ejecutar agentes de IA en modo desatendido es básicamente ejecutar código no confiable en tu máquina. Las empresas que construyen estas herramientas no están intentando robar tus credenciales — ese no es su modelo de negocio. Pero internet es creativo, y los vectores de ataque como el Slopsquatting y los ataques de prompt injection se están volviendo cada vez más sofisticados.

Los agentes tienen mitigaciones integradas, claro. Pero las mitigaciones no son perfectas, y aparecen nuevas vulnerabilidades regularmente. Solo mira las vulnerabilidades recientes de escape de sandbox — nos recuerdan que herramientas de aislamiento ligeras como bwrap, aunque útiles, no son fortalezas impenetrables.

Los contenedores ofrecen otra capa de protección, pero aquí está la parte incómoda: los contenedores comparten el kernel del host. Vulnerabilidades recientes en el kernel han demostrado potencial de escalada de privilegios, lo que significa que un atacante determinado podría potencialmente romper el aislamiento del contenedor. Para un límite de seguridad, eso no es ideal.

Aquí es donde las microVMs se están convirtiendo en una opción atractiva. A diferencia de los contenedores, cada microVM ejecuta su propio kernel. Incluso si un atacante encuentra una vulnerabilidad del kernel, está confinado al entorno de esa microVM específica. Es seguridad por aislamiento — y es sorprendentemente práctica.

¿Qué Son Exactamente las MicroVMs?

Si estás familiarizado con las máquinas virtuales tradicionales, ya conoces el concepto: aislamiento completo con tu propio kernel, tus propios recursos de sistema, tu propio todo. La desventaja siempre ha sido que las VMs son pesadas — tardan minutos en iniciar, consumen RAM significativa, y generalmente se sienten como excesivas para ejecutar un agente de código.

Las microVMs le dan la vuelta a esto. Mantienen los beneficios de seguridad de las VMs tradicionales (kernel separado, fuerte aislamiento) mientras inician en cientos de milisegundos en lugar de minutos. Obtienes el límite de seguridad de una VM con una huella más cercana a la de un contenedor.

En Fedora Linux, hay un enfoque elegante usando el runtime krun para Podman. Esto significa que puedes usar el mismo flujo de trabajo familiar de Podman que ya usas para contenedores, pero con aislamiento de microVM debajo. No hay nuevas herramientas que aprender, no hay configuración compleja — solo cambiar el runtime.

Primeros Pasos: Instalación

Instalar el runtime krun en Fedora es directo:

dnf install crun-krun

Una vez instalado, ejecutar una microVM es casi idéntico a ejecutar un contenedor regular:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Eso es todo. Ahora tienes una microVM completamente aislada ejecutando Fedora. El flujo de trabajo que ya conoces, pero con límites de seguridad más fuertes.

Algunas Consideraciones Importantes

Las microVMs no son contenedores regulares, así que aplican algunas consideraciones prácticas:

Asigna suficientes recursos. Los valores por defecto pueden ser demasiado conservadores para un agente de código que necesita compilar código, ejecutar tests y gestionar archivos del proyecto. Usa anotaciones de krun para asegurar asignación adecuada de CPU y RAM — de lo contrario podrías ver eliminaciones por OOM en el peor momento posible.

Verifica tu versión de libkrun. Las versiones anteriores a la 1.8 tienen un bug que impide el ingreso correcto de teclado. Si te encuentras incapaz de presionar Enter en tu agente de código, probablemente sea por esto. Actualiza para evitar frustraciones.

El manejo de usuarios es diferente. La microVM siempre inicia como root sin importar qué directiva USER pongas en tu Dockerfile. Necesitarás cambiar de usuario manualmente después del inicio o construir ese cambio en tu script de entrada.

Una Configuración Práctica para Claude Code

Veamos un ejemplo del mundo real: sandboxing de Claude Code para un proyecto Python usando uv para gestión de paquetes. Usaremos Podman Compose para la orquestación.

Primero, instala Podman Compose:

dnf install podman-compose

La configuración consiste en tres archivos: un Dockerfile, un docker-compose.yaml, y un script de entrada.

El Dockerfile

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Crear grupo y usuario que coincida con el UID/GID del host
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Herramientas que cambian poco
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# RPMs que cambian frecuentemente
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

Nota algunos puntos clave: creamos un usuario sin privilegios, instalamos las herramientas que necesitamos (uv y Claude Code), y estructuramos el Dockerfile para que las dependencias que cambian frecuentemente estén al final. Esto optimiza el caché de build — no necesitarás reinstall uv cada vez que agregues un nuevo paquete.

El Archivo Compose

El docker-compose.yaml maneja montar tu directorio de proyecto, establecer etiquetas SELinux y configurar la asignación de recursos. Aquí es donde las microVMs difieren ligeramente de los contenedores regulares — necesitarás manejar la traducción de UID/GID y las solicitudes explícitas de recursos de hardware.

El Script de Entrada

El entrypoint maneja el cambio de usuario que mencionamos antes. Como las microVMs siempre inician como root, este script necesita cambiar a tu usuario sin privilegios antes de entregar el control al shell o al agente de código.

¿Merece la Pena el Setup Adicional?

Absolutamente. Aquí está la propuesta de valor: puedes usar potentes agentes de código IA sin darles acceso sin restricciones a tu workstation, tus credenciales de clúster o tu entorno de producción. El aislamiento es real — kernel separado, namespace separado, todo separado.

La sobrecarga de configuración es mínima comparada con los beneficios de seguridad. Y una vez que tienes la infraestructura en su lugar, crear entornos de agentes aislados se vuelve rutinario.

Para desarrolladores y equipos que manejan codebases sensibles, despliegan a clústeres de producción, o trabajan en industrias reguladas, esto no es opcional — es esencial. Los agentes de código IA son herramientas, y como cualquier herramienta poderosa, necesitan medidas de seguridad apropiadas.

Para Cerrar

Las microVMs en Fedora Linux representan un término medio práctico entre la seguridad de la virtualización completa y la conveniencia de los contenedores. Inician rápido, aíslan efectivamente y se integran sin problemas con los flujos de trabajo existentes de Podman.

Si estás usando agentes de código IA en tu flujo de trabajo de desarrollo, especialmente en modo desatendido, considera darle su propio sandbox de microVM. Tu yo del futuro — y tu equipo de seguridad — te lo agradecerán.

Las herramientas están disponibles. La documentación es sólida. ¿Y la tranquilidad? Esa no tiene precio.