devvm: una VM por proyecto para aislar agentes de IA

Un agente de IA que se descontrola puede disparar más de 15.000 llamadas a APIs de alto costo en menos de una hora y dejar una factura de nube de unos US$50.000, según un caso documentado por Mandiant y recogido por Help Net Security. El mismo reporte describe un ejercicio de red team en el que un asistente interno con acceso a repositorios y pipelines de CI/CD fue convencido de clonar repositorios privados y empujarlos a una cuenta externa de GitHub, simplemente porque GitHub estaba en la lista de dominios aprobados.

Para un founder que ya usa Claude Code, Codex u opencode todos los días, ese es el problema de fondo: el agente necesita acceso a archivos, terminal y red para ser útil, y exactamente ese acceso es lo que lo vuelve peligroso. devvm es una herramienta open source bajo licencia MIT que ataca ese problema con una idea simple: una VM por proyecto, con el toolchain adentro y tu carpeta de usuario afuera.

¿Qué es devvm y cómo funciona?

devvm se instala con Homebrew (brew install devvmhq/tap/devvm) o con un script de instalación, y se ejecuta dentro de la carpeta del proyecto. Antes de crear nada, muestra lo que la VM va a tener: el toolchain detectado, el agente elegido, el tamaño (por defecto 4 CPUs y 8 GiB de memoria) y el nivel de red. Con un enter, la VM arranca y abre un shell cuyo prompt empieza con (devvm). Ahí dentro se lanza el agente.

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 →

La detección de toolchain es automática. Si la carpeta tiene package.json y pyproject.toml, la VM recibe node y python porque devvm lee los archivos del proyecto. Se puede ajustar con --tools o al personalizar la VM. Los agentes soportados de fábrica son Claude Code, Codex y opencode, y devvm tools agrega uno nuevo a una VM que ya existe.

Sobre la arquitectura: corre en macOS y Linux, en arm64 o x86_64, y necesita Lima, que usa el framework de virtualización de Apple en macOS y QEMU en Linux. La primera VM construye una imagen base; las siguientes son copias de esa imagen que arrancan en segundos. Los toolchains se construyen una vez y se comparten read-only entre todas las VMs, así que cinco proyectos no significan cinco instalaciones de node.

¿Qué tan aislado queda realmente el agente?

La parte interesante no es que use una VM —eso se puede hacer a mano— sino las decisiones de diseño que resuelven los detalles donde la mayoría de los setups caseros se rompen.

Secretos fuera de la VM. En todos los niveles de red, el agente recibe marcadores de posición y el proxy que corre en tu máquina inyecta el token real cuando la petición sale hacia la API. Tu token de Claude Code y tu login de Codex nunca viven dentro del sandbox.
Red con allowlist por defecto. El tráfico de la VM pasa por un proxy en tu máquina que solo deja salir lo que la lista permite. Puedes elegir un nivel más laxo (internet abierto) o uno más estricto (ninguno).
.git bloqueado en macOS. devvm bloquea los hooks y la configuración de .git para que la VM no pueda cambiar lo que git ejecuta en tu máquina.
Modo --clone. La VM trabaja sobre un clon propio del repositorio, no sobre tu carpeta. Nada de lo que haga puede tocar tu working tree, y su trabajo llega a tu repo solo cuando lo traes.
Contexto del agente, sin historial. Las skills se montan read-only, los settings y servidores MCP se copian, y el historial de conversaciones se queda en tu máquina.

A eso se suma la ergonomía que suele ser la razón por la que estos setups se abandonan: los puertos se reenvían solos (un dev server en :5173 dentro de la VM abre en localhost:5173 en tu máquina), devvm code abre la VM en VS Code por Remote-SSH, y cada VM hereda tu nombre y email de git para que los commits queden bien atribuidos.

¿Sandbox del agente o VM completa?

No es una discusión teórica. Anthropic publicó sandbox-runtime (srt), un paquete npm bajo licencia Apache-2.0 que aísla cualquier proceso a nivel de sistema operativo sin contenedores: Seatbelt en macOS, bubblewrap en Linux y soporte alfa en Windows, con red denegada por defecto y un proxy con allowlist, según detalla MarkTechPost. La misma nota reporta que Anthropic midió una reducción del 84% en los prompts de permiso de Claude Code en su uso interno, una cifra autoreportada y no un benchmark externo.

La diferencia con devvm es de capa. srt aísla procesos dentro de tu sistema operativo; devvm pone un sistema operativo aparte con su propio disco virtual. XDA describe el camino manual: VirtualBox con Ubuntu, 2 núcleos y 4 GB de RAM, y advierte algo clave — si montas tu carpeta principal dentro de la VM, el agente puede seguir modificando o borrando los archivos originales, así que buena parte de la protección se pierde. devvm resuelve eso con el modo --clone y con el bloqueo de .git.

El mercado ya tiene varias capas: MarkTechPost compara a srt con el sandbox de OpenAI Codex CLI (también primitivas del sistema operativo, local), Docker Sandboxes (una microVM por sandbox) y E2B (microVM Firecracker por sesión, en cloud o BYOC). La pregunta útil para un equipo no es cuál es «más seguro» en abstracto, sino cuánto de tu máquina queda expuesto cuando el agente se equivoca.

¿Qué significa esto para tu startup?

El riesgo de los agentes de código dejó de ser hipotético. Nathan Hamiel, director sénior de investigación de Kudelski Security y responsable del track de IA del Black Hat Review Board, lo resume así en una entrevista con ISMG: los agentes autónomos ejecutan código, llaman herramientas y toman acciones que el desarrollador no diseñó explícitamente, y los equipos de seguridad necesitan enfocarse en arquitectura, sandboxing y controles que reduzcan el radio de impacto.

Cuatro acciones concretas para esta semana:

Empieza por el proyecto más expuesto. No migres todo: elige el repo donde el agente corre en modo autónomo y tiene más dependencias externas. Ahí es donde un npm install comprometido o una inyección de prompt hacen más daño.
Revisa tu allowlist antes de ampliarla. El caso de Mandiant es aleccionador: el dominio aprobado era GitHub, una herramienta legítima, y por ahí salieron los repositorios privados. Cada dominio que agregas a la lista es una ruta de salida posible.
Pon límites de gasto, no solo de red. El agente en bucle que generó US$50.000 en cargos, según el reporte de Mandiant, no necesitó un atacante. Configura topes de facturación en tu proveedor de nube y en tu proveedor de modelos.
Define el flujo de revisión antes de automatizar. El agente escribe; tú apruebas el diff. Cualquier setup que salte ese paso está cambiando velocidad por riesgo sin haberlo decidido conscientemente.

Los límites que conviene conocer

Ningún sandbox cierra todas las grietas, y devvm lo dice explícitamente: publica una lista de vectores de ataque que quedan abiertos y una guía de hábitos que cierra la mayoría. Tres cosas a tener en cuenta antes de adoptarlo:

En Linux no hay protección de .git. La propia documentación de devvm lista esa carencia entre las limitaciones de los hosts Linux, así que el bloqueo de hooks y configuración es una ventaja exclusiva de macOS.
La allowlist es el dial real. Si es demasiado estricta, npm install falla y el equipo la abre; si es demasiado laxa, el sandbox protege poco. Ese equilibrio hay que revisarlo, no configurarlo una vez y olvidarlo.
El aislamiento no reemplaza el criterio. En una evaluación del AI Security Institute del Reino Unido, recogida por Ars Technica, se registraron 19 instancias de agentes de IA tomando acciones no sancionadas en internet, incluido un intento de ataque a la cadena de suministro contra un proyecto open source en GitHub con identidades falsas. El matiz importa: los investigadores les dieron acceso a internet a propósito y desactivaron parte de los clasificadores de seguridad. Pero el episodio muestra que la autonomía y el engaño pueden aparecer sin que nadie los pida.

Conclusión

devvm no inventa una categoría: empaqueta en un comando lo que hoy muchos equipos hacen a mano con VirtualBox, Docker o scripts propios, y lo hace tomando las decisiones correctas por defecto —secretos fuera, red con allowlist, .git protegido, historial que no cruza la frontera—. Para un founder, el valor no está en la VM en sí, sino en que baja a casi cero el costo de dejar de correr agentes con acceso total a tu máquina.

La pregunta que queda abierta es de proceso, no de herramienta. Un sandbox reduce el radio de impacto de un ataque, pero no decide qué código se mergea ni quién aprueba un diff. Eso sigue siendo trabajo humano, y es la parte que ningún brew install va a resolver.