Show HN: Clawk – Dale a los agentes de código una VM Linux desechable, no tu portátil

Artículo original ↗ Discusión en Hacker News ↗

Dar a los agentes de código de IA sus propias VMs Linux desechables, en lugar de acceso directo a la máquina de un desarrollador, está surgiendo como una forma preferida de limitar los daños por bugs, prompt injection y ataques a la cadena de suministro. Los comentaristas comparan el enfoque basado en VMs de Clawk con contenedores Docker, sandboxes a nivel de sistema operativo y un ecosistema creciente de herramientas similares, sopesando compromisos entre seguridad, rendimiento, configurabilidad y facilidad de uso en macOS y Linux. Muchos sostienen que los sandboxes simples ya se han comoditizado, y que los problemas más difíciles e importantes son la política de red, la gestión de credenciales, los rollbacks y los entornos remotos escalables.

Por qué VMs en lugar de contenedores o usuarios separados

  • Muchos argumentan que los contenedores comparten el kernel del host y dependen en gran medida de su corrección; las VMs proporcionan un límite de aislamiento más pequeño y claro.
  • Contraargumento: si los contenedores están bien configurados, cualquier escape sigue siendo un bug del kernel; algunos ven los contenedores como “suficientemente buenos”, especialmente con refuerzo adicional (gVisor, Firecracker, Kata, eBPF).
  • Usar un usuario separado sin sudo se propone como la opción más simple y portátil, pero otros señalan que esto sigue compartiendo paquetes del host, demonios y archivos legibles por todos, y es fácil de configurar mal.
  • Algunos prefieren las VMs porque se comportan como “cajas Linux reales” donde Docker, Kubernetes, etc. se ejecutan de forma natural, evitando los trucos de Docker-in-Docker.

Seguridad y modelos de amenaza

  • Las preocupaciones van más allá de “evitar rm -rf /”:
    • Ataques a la cadena de suministro mediante npm/pip/cargo y repositorios no confiables.
    • Prompt injection que hace que los agentes ejecuten escaladas de privilegios o exploten LPEs.
    • Agentes instalando paquetes hostiles o abusando de servicios locales.
  • Algunos usuarios dividen su mundo en un host de confianza (solo paquetes de la distro) y VMs desechables para todo lo demás.
  • Otros creen que las VMs son excesivas si no asumes un agente hostil; prefieren un aislamiento más simple de usuario o contenedor.
  • También se reconocen escapes de VM; la gente insiste en mantener los kernels actualizados.

Controles de red y firewall

  • Varias herramientas se centran en listas de अनुमति estrictas de red, políticas por dominio o conscientes del protocolo, y proxies a nivel de aplicación.
  • Una implementación usa un proxy de red en espacio de usuario (por ejemplo, gvproxy) que termina conexiones de invitado y vuelve a abrir sockets del host, aplicando allí una lista de अनुमति.
  • En Linux, los dispositivos TAP aún pueden requerir root, pero la lógica de filtrado puede permanecer en espacio de usuario.
  • Otros experimentan con eBPF, nftables o proxies MITM para controlar el tráfico saliente y proteger secretos.

Enfoques alternativos de sandboxing

  • Se discutió una amplia gama de opciones:
    • VMs completas (Firecracker, KVM, QEMU, Nix microVMs, incus, quickemu, Vagrant).
    • Contenedores y nspawn (Docker, Podman, systemd-nspawn, LXC).
    • “Casi contenedores” y namespaces (bubblewrap, Landlock, Firejail, herramientas basadas en bwrap).
    • Plataformas remotas de CI/desarrollo y sandboxes en la nube (varias ofertas alojadas, algunas con macOS).
  • Varios proyectos enfatizan: configuración declarativa, sandboxes por proyecto, control de secretos, snapshot/rollback, flujos de diff/apply, integración MCP e inyección de credenciales.

Sandboxes locales frente a la nube

  • Algunos prefieren VMs locales por “local-first”, cumplimiento de políticas de la empresa y menor confianza en terceros.
  • Otros prefieren sandboxes remotos para que su portátil pueda dormir mientras los agentes siguen ejecutándose, y para mantener a los agentes aislados de las máquinas personales.
  • Se debate el coste frente a tener una máquina de desarrollo dedicada (por ejemplo, un Mac mini).

Rendimiento y ergonomía

  • En macOS, se dice que la sobrecarga de E/S de archivos y supervisión de procesos ralentiza las cargas de trabajo de los agentes; ejecutar agentes dentro de VMs Linux puede ser significativamente más rápido.
  • Algunos destacan sandboxes basados en namespaces de arranque instantáneo como más ligeros que las VMs completas o los contenedores.
  • Necesidades comunes de usabilidad: espacios de trabajo multi-repo, historial persistente, alcance de red, reutilización de autenticación más fácil y expulsión limpia de la herramienta.

Escepticismo y discusión meta

  • Muchos señalan que hay “docenas” de proyectos superpuestos; algunos ven esto como reinventar la rueda innecesariamente, otros como experimentación saludable y deseo de tener la propiedad total del código.
  • Las críticas se centran en piezas de nivel superior que faltan: motores de políticas, gestión de configuración, estrategias de rollback, gestión dinámica de credenciales y proxies de servicios.
  • Hay interés en una “plataforma de agentes” integrada donde el sandboxing, las políticas, los secretos y la observabilidad sean de primera clase, en lugar de otro sandbox básico más.