Ginux: el kernel en userspace que aísla agentes de IA

Ginux deja de ser un kernel propio y pasa a correr sobre Linux

Ginux, el proyecto del fundador de CentOS y Rocky Linux, Gregory Kurtzer, cambió de dirección: ya no es un kernel independiente que arranca por UEFI, sino un kernel de userspace que corre como un proceso común de Linux. La decisión cierra una etapa de investigación que, según TechSpot, llevó a Kurtzer a construir un kernel funcional en 11 días con un agente de IA escribiendo casi todo el código.

Para un founder que hoy pone agentes de IA a ejecutar comandos en producción, el giro importa por una razón concreta: Ginux deja de competir con Linux y se posiciona como una capa que decide, syscall por syscall, qué puede hacer realmente el software que corre adentro.

Qué cambió exactamente en el proyecto

El repositorio lo dice sin ambigüedad: la fase de kernel independiente «está completa». El código final quedó preservado en la rama bootable-kernel y el tag bootable-kernel-final, y el desarrollo activo continúa como kernel de userspace. El nombre, por cierto, sigue siendo un chiste de la misma familia que Linux: combina Linux, GPT y Greg, y la «G» oficialmente significa GPT.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El experimento original probó algo que hace dos años sonaba exagerado: que un agente de IA, dirigido por un humano experimentado a través de arquitectura, gates y tests ejecutables, podía construir un kernel capaz de correr un userspace Linux real. Según TechSpot, ese trabajo se hizo en una sola tarea larga de OpenAI Codex con GPT-5.6 Sol, y produjo alrededor de 139.000 líneas de código y tests en más de 1.000 commits.

Pero el propio Kurtzer sacó la conclusión incómoda: Linux no es solo código fuente. Es una interfaz estable, un proceso de desarrollo, una comunidad global y décadas de compatibilidad. Reimplementar mecanismos de kernel no reproduce ese ecosistema. TechSpot reporta que, de los 375 syscalls de la interfaz x86-64 de Linux 6.12, Ginux implementaba por completo apenas 82, otros 245 funcionaban parcialmente y 48 estaban bloqueados a propósito.

Ahí está el insight del pivote: en lugar de perseguir compatibilidad total, Ginux convierte esa brecha en su propuesta de valor.

Cómo funciona el contrato de syscalls

La arquitectura actual es más simple de lo que suena. El kernel de Linux del host sigue siendo el PID 1 real. Ginux corre como un proceso de confianza dentro de ese host y crea instancias: cada una tiene procesos virtuales, descriptores virtuales, dispositivos asignados y un userspace Rocky Linux 10 administrado por su propio systemd virtual.

Antes de que un syscall gestionado tenga efecto en el host, el despachador de Ginux resuelve el contrato de la instancia y elige uno de tres caminos:

Emular: responder por completo desde el estado que Ginux controla.
Mediar: validar y traducir la petición, y ejecutar después una operación acotada en el host.
Negar: devolver un error compatible con Linux o terminar la tarea.

La idea de fondo es una inversión deliberada de la regla más sagrada de Linux. Como resume Linus Torvalds, «no rompemos el espacio de usuario». Ginux hace exactamente lo contrario: rompe esa garantía de forma selectiva y explícita, para que cada instancia reciba solo las capacidades que su carga de trabajo aprobada necesita.

Qué significa esto para tu startup

Si hoy corres agentes de IA con acceso a shell, archivos y red, ya sabes que el sandbox es el punto débil. La investigación de contención de agentes es, probablemente, la parte más relevante de Ginux para un equipo chico.

El escenario que plantea el proyecto: en vez de darle a un agente el ABI completo de Linux, el operador mete su árbol de procesos en una instancia cuyo contrato expone solo lo necesario. Un contrato puede permitir leer la hora, inspeccionar sus propios procesos y modificar un workspace asignado, y negar cambios de reloj, acceso al filesystem del host, listeners de red no aprobados y dispositivos no relacionados. Todo queda auditable.

Dos acciones concretas que puedes tomar esta semana, sin adoptar Ginux:

Inventaría lo que tus agentes pueden tocar hoy. Lista los syscalls, rutas, puertos y credenciales a los que tienen acceso real. La mayoría de los equipos descubre que el agente puede mucho más de lo que su tarea exige.
Separa el almacenamiento por ejecución. Si dos agentes pueden escribir en el mismo lugar, asume que pueden comunicarse entre ellos. Es una de las lecciones más repetidas de los incidentes de contención de agentes de 2026.

Y una advertencia que el propio repositorio repite: Ginux es software de investigación, no tiene certificación de seguridad independiente y no está listo para cargas de producción.

Ginux frente a gVisor, seccomp y las microVMs

El proyecto se ubica con honestidad en un espacio ya explorado. Su tabla comparativa lo pone frente a seccomp (filtra syscalls del host), User-Mode Linux (corre Linux como proceso), gVisor (implementa un kernel de aplicación en userspace), Gramine (library OS) y Proxos (enruta llamadas entre sistemas operativos).

La diferencia que Ginux reclama es tratar el contrato declarado, el estado virtual, los dispositivos, los recursos y el ciclo de vida como una sola frontera revisable. No promete el ABI completo de Linux: sus afirmaciones de compatibilidad aplican solo a contratos, cargas y evidencia ejecutable con nombre propio.

El mercado se está moviendo en la misma dirección. Una encuesta de la CNCF y Broadcom sobre 492 profesionales, publicada por Virtualization Review el 9 de noviembre de 2026, encontró que el 62% ya usa al menos un enfoque de aislamiento de IA basado en VMs. El uso actual de sandboxing con microVMs era del 20%, con un 30% planeando adoptarlo el año siguiente.

Los proveedores también están respondiendo. Baseten lanzó Sandboxes el 5 de noviembre de 2026, con una microVM dedicada por entorno y un límite por defecto de 10 sandboxes concurrentes por organización, según Unite.AI. Docker presentó Cloud Sandboxes el 24 de septiembre de 2026, con aislamiento de microVM y escalado de 1 a 16 vCPU, según el comunicado recogido por Yahoo Finance.

Los límites que conviene tener claros

Ginux no es un producto. El repositorio lo dice: no tiene certificación de seguridad independiente, no ofrece compatibilidad completa con Linux y no está listo para producción. Su entorno de referencia es macOS arm64 con QEMU TCG, y según TechSpot no hay soporte para hardware físico, GPUs ni discos NVMe.

El adversario que modela es un proceso dentro de la instancia. El kernel del host, el hardware, el ejecutable de Ginux y el operador siguen siendo de confianza. El backend nativo todavía depende del host para cargar ELF, espacios de direcciones, page faults, señales, scheduling y ptrace.

Hay un dato que habla del método de desarrollo: el proyecto se construye con Human-Directed Agentic Engineering (HDAE), donde el humano define intención, arquitectura y criterios de aceptación, y el agente ejecuta implementación, diagnóstico y tests. Cada gate aprobado registra alcance, no-objetivos, criterios, evidencia y punto de parada.

Conclusión

El giro de Ginux es menos una rendición que una corrección de tesis. Kurtzer construyó un kernel con IA en 11 días y descubrió que el valor no estaba en el kernel, sino en la frontera que ese ejercicio dejó al descubierto: un contrato explícito, versionado y auditable entre lo que un agente quiere hacer y lo que el host le permite.

Para un founder, la lección es trasladable aunque nunca toque Ginux. La pregunta ya no es si tus agentes están aislados, sino si puedes enumerar exactamente qué autoridad tienen. Si la respuesta es «más o menos», ese es el trabajo pendiente.